New to Kubed? Please start here.
You can synchronize a ConfigMap or a Secret into different clusters using Kubed. For this you need to provide a
kubeconfig file consisting cluster contexts and specify context names in comma separated format using
kubed.appscode.com/sync-contexts annotation. Kubed will create a copy of that ConfigMap/Secret in all clusters specified by the annotation. For each cluster, it will sync into source namespace by default, but if namespace specified in the context (in the
kubeconfig file), it will sync into that namespace. Note that, Kubed will not create any namespace, it has to be created beforehand.
If the data in the source ConfigMap/Secret is updated, all the copies will be updated. Either delete the source ConfigMap/Secret or remove the annotation from the source ConfigMap/Secret to remove the copies.
If the list of contexts specified by the annotation is updated, Kubed will synchronize the ConfigMap/Secret accordingly, ie. it will create ConfigMap/Secret in the clusters listed in new annotation (if not already exists) and delete ConfigMap/Secret from the clusters that were synced before but not listed in new annotation.
Note that, Kubed will error out if multiple contexts listed in annotation point same cluster. Also Kubed assumes that none of cluster contexts in
kubeconfig file points the source cluster.
At first, you need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using kind.
To enable config syncer for different clusters, you need a
kubeconfig file consisting cluster contexts where you want to sync your ConfigMap/Secret.
$ cat ./docs/examples/cluster-syncer/demo-kubeconfig.yaml apiVersion: v1 kind: Config clusters: - name: cluster-1 cluster: certificate-authority-data: ... server: https://126.96.36.199 - name: cluster-2 cluster: certificate-authority-data: ... server: https://188.8.131.52 users: - name: user-1 user: client-certificate: ... client-key: ... - name: user-2 user: client-certificate: ... client-key: ... contexts: - name: context-1 context: cluster: cluster-1 user: user-1 - name: context-2 context: cluster: cluster-2 user: user-2 namespace: demo-cluster-2
Now, deploy Kubed operator in your cluster following the steps here. Below you can see the command to install Kubed using Helm 3.
$ helm install kubed appscode/kubed \ --version v0.12.0 \ --namespace kube-system \ --set config.clusterName=kind \ --set config.kubeconfigContent="$(cat ./docs/examples/cluster-syncer/demo-kubeconfig.yaml)"
Once the operator pod is running, go to the next section.
At first, create a ConfigMap called
omni in the
demo namespace. This will be our source ConfigMap.
$ kubectl create namespace demo namespace "demo" created $ kubectl apply -f ./docs/examples/config-syncer/demo.yaml configmap "omni" created
Now, apply the
kubed.appscode.com/sync-contexts: "context-1,context-2" annotation to ConfigMap
$ kubectl annotate configmap omni kubed.appscode.com/sync="context-1,context-2" -n demo configmap "omni" annotated
It will create configmap “omni” in
cluster-1 it will sync into source namespace
demo since no namespace specified in
context-1 and for
cluster-2 it will sync into
demo-cluster-2 namespace since namespace specified in
context-2. Here we assume that those namespaces already exits in the respective clusters.
Other concepts like updating source configmap, removing annotation, origin annotation, origin labels, etc. are similar to the tutorial described here.