kubernetes-sigs/cluster-api

Provide more prescriptive guidance on multi-tenancy

Open

#7,636 opened on Nov 28, 2022

View on GitHub
 (6 comments) (0 reactions) (0 assignees)Go (1,532 forks)auto 404
help wantedkind/documentationpriority/backlogtriage/accepted

Repository metrics

Stars
 (4,267 stars)
PR merge metrics
 (PR metrics pending)

Description

From the PR that we previously had for this topics:

As a follow up to the Cluster API meeting of 2021/04/21, this PR intends to give more prescriptive guidance around the multi-tenancy contract. In particular, this documents how cluster scoped resources should work at the present time, and also in a future release of Cluster API that drops support for older Kubernetes versions. https://github.com/kubernetes-sigs/cluster-api/pull/4514

There doesn't seem to be a proposal in core Cluster API and the book only has this short documentation: https://cluster-api.sigs.k8s.io/developer/architecture/controllers/multi-tenancy.html

Multi tenancy Multi tenancy in Cluster API defines the capability of an infrastructure provider to manage different credentials, each one of them corresponding to an infrastructure tenant.

Contract In order to support multi tenancy, the following rule applies:

  • Infrastructure providers MUST be able to manage different sets of credentials (if any)
  • Providers SHOULD deploy and run any kind of webhook (validation, admission, conversion) following Cluster API codebase best practices for the same release.
  • Providers MUST create and publish a {type}-component.yaml accordingly.

#4514 was a lot more concrete than our current documentation. I'm not sure what the current state on multi-tenancy implementations across providers is and what the starting point for a new PR would be.

/kind documentation [One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

Contributor guide