Update sig-multicluster/namespace-sameness-position-statement.md
Co-Authored-By: Tim Hockin <thockin@google.com>
This commit is contained in:
parent
8c86226e6d
commit
53a49bbda5
|
@ -33,3 +33,69 @@ particular, to create namespaces in them.
|
||||||
**For a set of related clusters governed by a single authority, all namespaces of
|
**For a set of related clusters governed by a single authority, all namespaces of
|
||||||
a given name are considered to be the same namespace. A single namespace should
|
a given name are considered to be the same namespace. A single namespace should
|
||||||
have a consistent owner across the set of clusters.**
|
have a consistent owner across the set of clusters.**
|
||||||
|
|
||||||
|
## Appendix
|
||||||
|
|
||||||
|
This position statement is intentionally very abstract, with the goal of not
|
||||||
|
being overly prescriptive. The following examples are HYPOTHETICAL, but
|
||||||
|
hopefully make the statement clearer.
|
||||||
|
|
||||||
|
### Example 1: Namespace creation
|
||||||
|
|
||||||
|
Consider an organization that runs two clusters, "A" and "B". They have a
|
||||||
|
cluster-ops team which is responsible for keeping those clusters alive and
|
||||||
|
healthy. They also have app-teams, "foo" and "bar" which use those clusters.
|
||||||
|
|
||||||
|
Cluster-ops owns the creation of namespaces in both clusters. They can choose
|
||||||
|
to delegate the ability to create namespaces to foo-team and bar-team, but any
|
||||||
|
namespace name that is allocated in "reserved" in all clusters. How the
|
||||||
|
delegation works is an area for innovation, but some possible examples
|
||||||
|
include:
|
||||||
|
* A self-service portal which allocate a name in a global database and
|
||||||
|
creates the namespace on the user's behalf
|
||||||
|
* Tooling that allocates a name in a global database and issues a credential
|
||||||
|
to the user which is checked in an admission controller
|
||||||
|
* An admission controller which requires namespaces be prefixed by the team
|
||||||
|
name
|
||||||
|
|
||||||
|
However they choose to delegate (or not), once foo-team requests a namespace
|
||||||
|
called "database" in cluster A, no other team may request a namespace called
|
||||||
|
"database" in cluster B. That name is taken.
|
||||||
|
|
||||||
|
### Example 2: RBAC sync
|
||||||
|
|
||||||
|
Consider the same organization from example 1. As with many large-sized
|
||||||
|
organizations, they alreadyhave a central LDAP server which stores policies
|
||||||
|
about who is supposed to be able to access what systems. They enforce this by
|
||||||
|
converting those policies into Kubernetes RBAC rules and pushing them down into
|
||||||
|
their clusters.
|
||||||
|
|
||||||
|
Cluster-ops runs a metrics service in each cluster. The RBAC for this service
|
||||||
|
should be the same in each cluster (i.e. the same set of people administer it,
|
||||||
|
regardless of which cluster). The LDAP-to-RBAC sync process can assume that
|
||||||
|
the "metrics" namespace in each cluster should get the same RBAC rules.
|
||||||
|
|
||||||
|
If there are special RBAC rules that need to be applied in some clusters (e.g.
|
||||||
|
clusters in EU have more limited access), the LDAP-to-RBAC sync implementation
|
||||||
|
can apply specializations based on whatever criteria it understands.
|
||||||
|
|
||||||
|
### Example 3: Multi-cluster services
|
||||||
|
|
||||||
|
Consider the same organization from previous examples. They have enabled an
|
||||||
|
implementation of multi-cluster Services, which lets them access backends which
|
||||||
|
are running on other clusters in the group.
|
||||||
|
|
||||||
|
As in example 2, cluster-ops run a per-cluster metrics service, It does not
|
||||||
|
make sense for clients in cluster A to access the metrics server of cluster B.
|
||||||
|
Even though this runs in the same "metrics" namespace in both clusters (and
|
||||||
|
thus namespce sameness applies), the implementation of multi-cluster services
|
||||||
|
probably should not be on-by-default. The details of how multi-cluster
|
||||||
|
services will work are an area for innovation, but ideas include:
|
||||||
|
* Opt-in: services must be "exported" to be merged across clusters
|
||||||
|
* Opt-out: services or namespace can be opted out of service merging
|
||||||
|
* Different discovery: merged services and "raw" services use different names
|
||||||
|
or other discovery mechanisms
|
||||||
|
|
||||||
|
However the implementation works, the metrics service is not automatically
|
||||||
|
merged across clusters, though the LDAP-to-RBAC sync from example 2 can still
|
||||||
|
apply consistent policies.
|
||||||
|
|
Loading…
Reference in New Issue