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 a
Federation V2effort 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 secrets in Federation control plane.
Secrets in federation control plane (referred to as “federated secrets” in this guide) are very similar to the traditional Kubernetes Secrets 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, for example this one by Kelsey Hightower, are also available to help you.
The API for Federated Secret is 100% compatible with the API for traditional Kubernetes Secret. You can create a secret by sending a request to the federation apiserver.
You can do that using kubectl by running:
kubectl --context=federation-cluster create -f mysecret.yaml
--context=federation-cluster flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
Once a federated secret is created, the federation control plane will create a matching secret in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example:
kubectl --context=gce-asia-east1a get secret mysecret
The above assumes that you have a context named ‘gce-asia-east1a’ configured in your client for your cluster in that zone.
These secrets in underlying clusters will match the federated secret.
You can update a federated secret as you would update a Kubernetes secret; however, for a federated secret, you must send the request to the federation apiserver instead of sending it to a specific Kubernetes cluster. The Federation control plan ensures that whenever the federated secret is updated, it updates the corresponding secrets in all underlying clusters to match it.
You can delete a federated secret as you would delete a Kubernetes secret; however, for a federated secret, you must send the request to the 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 secret mysecret
Note: At this point, deleting a federated secret will not delete the corresponding secrets from underlying clusters. You must delete the underlying secrets manually. We intend to fix this in the future.