Config Sync allows cluster operators to manage single clusters, multi-tenant clusters, and multi-cluster Kubernetes deployments using files, called configs, stored in a Git repository.
Some configs are Kubernetes object manifests. Other configs are not object manifests, but instead provide information needed by Config Sync itself. You can write configs in YAML or JSON. Config Sync watches for updates to these files and applies changes to all relevant clusters automatically.
_— Google — _Config Sync Overview
Please note: Prior to learning about Config Sync, my go-to approach to managing Kubernetes resources across one or more clusters was Terraform configurations stored in a GIT repository evaluated by a CI/CD pipeline.
Please note: The final set of Config Sync configuration files developed through this article are available for download.
How is Config Sync licensed?
It is not entirely clear. What is clear from the documentation is that Config Sync is both made available as a stand-alone tool (there is no mention of pricing or licensing that I could find) and as part of Google’s commercial Anthos product. As a matter of fact, Google maintains two sets of virtually identical documentation for Config Sync:
It is also clear that Google has not open-sourced Config Sync; the software downloads are from Google.
Does Config Sync require Google Kubernetes Engine (GKE)?
While the installation instructions mention that the clusters must run GKE version 1.14x or later, anecdotally it does appear to run on other clusters. This article was written with Amazon Elastic Kubernetes Service (EKS) 1.17x.
Prerequisites
If you wish to follow along, you will need:
- A workstation: In this article I used Linux; same operations should work on macOS (not sure about Windows)
- A Kubernetes cluster: GKE version 1.14x or later. Anecdotally, it also appears to work with Amazon EKS 1.17x or later
- A_ kubectl_ command line interface (CLI) tool authenticated/authorized to the Kubernetes cluster with the cluster-admin ClusterRole
- A Google Cloud Platform (GCP) project; only needed to download the Config Sync software
- The gcloud CLI tool authenticated / authorized to the GCP project; only needed to download the Config Sync software
- An empty GIT repository, e.g., a GitHub repository. It can be private; in this article it was left public for simplicity
Install Config Sync
The first step is to use one of the gcloud CLI tools, gsutil, to download a Kubernetes configuration:
$ gsutil cp gs://config-management-release/released/latest/config-sync-operator.yaml config-sync-operator.yaml
While optional, we also install a Config Sync CLI tool; nomos:
$ gcloud components install nomos
We then apply the downloaded Kubernetes configuration to the cluster:
$ kubectl apply -f config-sync-operator.yaml
Under the hood, this configuration installs the following:
- CustomResourceDefinition: configmanagements.configmanagement.gke.io
- ClusterRoleBinding: config-management-operator
- ClusterRole: config-management-operator
- ServiceAccount: kube-system:config-management-operator
- Deployment: kube-system:config-management-operator
- Namespace: config-management-system
Configure Config Sync
We clone the empty GIT repository to our workstation and create a ConfigManagement custom resource configuration; hello-config-sync-configmanagement.yaml in its folder:
Things to observe:
- The name’s value is arbitrary; can be left as config-management as in the official Config Sync documentation
- The clusterName value is an arbitrary name that is used to uniquely identify a particular cluster. If one has multiple clusters, one would create multiple custom resource configuration files; one per cluster. Each file would be identical except for the clusterName value. In my example, I named my single cluster hello-config-sync
- The syncRepo value refers to the GIT repository URL
- The secretType value refers to a secret that is required to access the GIT repository; my repository is public so I use none
- The policyDir value refers to a folder in the GIT repository that holds the Config Sync configuration files used to manage the clusters; in our case _policy _(we will create below)
- The ConfigManagement custom resource configuration files themselves are not to be stored in the _policyDir. _Also, these files did not need to be stored in the GIT repository at all; only did so for documentation purposes.
#kubernetes #management
