Note:Federation V1
, the current Kubernetes federation API which reuses the Kubernetes API resources ‘as is’, is currently considered alpha for many of its features. There is no clear path to evolve the API to GA; however, there is aFederation V2
effort in progress to implement a dedicated federation API apart from the Kubernetes API. The details are available at sig-multicluster community page.
This guide explains how to use Namespaces in Federation control plane.
Namespaces in federation control plane (referred to as “federated Namespaces” in this guide) are very similar to the traditional Kubernetes Namespaces providing the same functionality. Creating them in the federation control plane ensures that they are synchronized across all the clusters in federation.
This guide assumes that you have a running Kubernetes Cluster Federation installation. If not, then head over to the federation admin guide to learn how to bring up a cluster federation (or have your cluster administrator do this for you). Other tutorials, such as Kelsey Hightower’s Federated Kubernetes Tutorial, might also help you create a Federated Kubernetes cluster.
You are also expected to have a basic working knowledge of Kubernetes in general and Namespaces in particular.
The API for Federated Namespaces is 100% compatible with the API for traditional Kubernetes Namespaces. You can create a Namespace by sending a request to the federation apiserver.
You can do that using kubectl by running:
kubectl --context=federation-cluster create -f myns.yaml
The --context=federation-cluster
flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a federated Namespace is created, the federation control plane will create a matching Namespace in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example:
kubectl --context=gce-asia-east1a get namespaces myns
The above assumes that you have a context named ‘gce-asia-east1a’ configured in your client for your cluster in that zone. The name and spec of the underlying Namespace will match those of the Federated Namespace that you created above.
You can update a federated Namespace as you would update a Kubernetes Namespace, just send the request to federation apiserver instead of sending it to a specific Kubernetes cluster. Federation control plan will ensure that whenever the federated Namespace is updated, it updates the corresponding Namespaces in all underlying clusters to match it.
You can delete a federated Namespace as you would delete a Kubernetes Namespace, just send the request to federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
kubectl --context=federation-cluster delete ns myns
As in Kubernetes, deleting a federated Namespace will delete all resources in that Namespace from the federation control plane.
Note: At this point, deleting a federated Namespace will not delete the corresponding Namespace, or resources in those Namespaces, from underlying clusters. Users must delete them manually. We intend to fix this in the future.
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.