102 lines
5.0 KiB
Markdown
102 lines
5.0 KiB
Markdown
# Namespace Sameness - SIG Multicluster Position Statement
|
||
|
||
Author: Jeremy Olmsted-Thompson (**[@jeremyot](https://github.com/jeremyot)**), Google
|
||
Last Edit: 2020/04/20
|
||
Status: RELEASED
|
||
|
||
## Goal
|
||
To establish a normative statement for multi-cluster namespace semantics and
|
||
governance as a building block for further development which will require
|
||
specifying behaviors across clusters.
|
||
|
||
## Context
|
||
Users are reaching for multi-cluster deployments for a
|
||
[variety of reasons](http://bit.ly/k8s-multicluster-conversation-starter-doc).
|
||
However, Kubernetes treats the cluster boundary as the edge of the universe.
|
||
There are currently no standard practices for how to extend the Kubernetes
|
||
resource model across multiple clusters. Without common patterns we can’t build
|
||
portable tooling to facilitate multi-cluster capabilities and know that behavior
|
||
will be consistent for each user.
|
||
|
||
## Scope
|
||
A single organization may need multiple, disjoint sets of clusters. They may,
|
||
for example, represent different phases of the development lifecycle (dev,
|
||
staging, prod) or support unrelated projects. Each organization governs their
|
||
own clusters in isolation, so the scope of a namespace can only reasonably be
|
||
declared within the organizational boundary. The scope of namespace identity is
|
||
defined as the union of clusters, governed by a single authority, that are
|
||
expected to work together. An authority is a company, organization, team,
|
||
individual, or other entity which is entrusted to manage these clusters and, in
|
||
particular, to create namespaces in them.
|
||
|
||
## Position
|
||
**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
|
||
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 already have 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.
|