cross-cluster-synchronizer-operator

Intro

The cross-cluster-sync-operator is designed to be able to sync resources across clusters. I designed this as a way to better administer resources between clusters.

Currently, it supports specifying specific ConfigMaps and Secrets to apply from one source cluster to target clusters.

Planned Features/Roadmap

Close goals

1. Support for other simple resources like SA, RBAC, PVC, etc.
2. Monitoring ConfigMaps after a SyncConfig resource is deployed.
3. Namespace monitoring of specific resources.
4. support for specifying specific namespaces for resources (specific ConfigMaps or secrets).
5. Containerization with Helm deployment as well as kubeconfig secret handling.

Far goals

1. Optional Bi-directional syncing (having CCS Operators on each cluster).
2. Handling more complex resources.
3. Auditing and Logging.
4. Better performance and error handling.

Obviously these are not the only goals, but some good ones to start.

Configuration

Currently, the operator is managed by a CRD: SyncConfig

Example SyncConfig

apiVersion: myoperator.example.com/v1
kind: SyncConfig
metadata:
  name: test-sync-configmap
spec:
  sourceCluster: "cluster1"
  targetClusters:
    - "cluster2"
  resources:
    - kind: "ConfigMap"
      namespace: "test2"
    - kind: "ConfigMap"
      name: "test-configmap2"
      namespace: "test"
  namespaceHandling: "create"

Function:

- kind: "ConfigMap"
  namespace: "test2"

• This will sync all ConfigMap resources in the test2 namespace from the sourceCluster to all the clusters in the targetClusters list.

- kind: "ConfigMap"
  name: "test-configmap2"
  namespace: "test"

• This will sync the test-configmap2 resource (specified in the kind key/value) in the test namespace from the sourceCluster to all the clusters in the targetClusters list.

• namespaceHandling deals with how absent namespaces are handled in the target clusters. The two valid options are create and fail. These are pretty self explanitory.

Just keep in mind that currently the resources are only synced when the SyncConfig CR is applied to the cluster.

Required Resource Key-value pairs

• kind is required.
• name is optional as it is used to specify a specific resource in a namespace. If you are syncing the entire namespace, then ensure invidivual resource syncs are removed.
• namespace is required if name is specified.

If kind is specified and name and namespace are absent, then theoretically it should sync all resources of the kind (has not been tested).

Cluster Authentication

For authentication to each cluster, you will need a kubeconfig for all target clusters. A secret will be required for each cluster you have. Use kubectl create secret generic <cluster_name> --from-file=kubeconfig=<path/to/kubeconfig> -n <ccs_namespace>. Ensure that no authentication is required for the kubeconfigs to work (such as GCP gcloud auth).

Install

Run these commands to download and start the operator:

git clone https://github.com/Aboot-face/cross-cluster-synchronizer-operator.git CCS-Operator; cd CCS-Operator
kubectl create namespace ccs-operator
kubectl apply -f app/syncconfig.yaml
kubectl apply -f deployment/rbac.yml -n ccs-operator
kubectl apply -f deplyoment/deployment.yml -n ccs-operator
# For GCP: You must generate a kubeconfig that uses a serviceaccount on the target clusters.
# https://goteleport.com/blog/kubectl-gke/

Or by Helm:

git clone https://github.com/Aboot-face/cross-cluster-synchronizer-operator.git CCS-Operator; cd CCS-Operator
helm install ccs-operator ccs/ -n ccs-operator --create-namespace
# somewhat experimental as I haven't added everything yet.

Next is to configure the kubeconfigs for your target clusters.

Current Testing

Currently being tested on two GCP clusters spun up using Terraform.

Terraform files available in terraform/ if you want to stand up two GCP clusters for testing.