In the third part of this series, we will use GitOps-style deployment to push workloads across all registered clusters through Anthos Config Management (ACM).

GitOps encourages maintaining configuration-as-code and environment-as-code in a central source code repository. This gives us a chance to version control configuration and environments along with source code.

Since Kubernetes uses YAML or JSON files for specifications, it becomes easy to combine these artifacts with code.

Google built a tool called Config Sync which acts as the bridge between an external source code repository and the Kubernetes API server. Anthos Config Management is based on Config Sync to extend it to multicluster scenarios.

In this tutorial, we will use a GitHub repository that acts as a single source of truth for deployments and configuration. A component of ACM is installed into each of the registered Anthos clusters to monitor the external repository for any changes and synchronizing them with the cluster.

ACM ensures that all the clusters have the same state as defined by the specifications in the repository.

ACM supports a structured or unstructured repository for configuration. A structured repo will have a hierarchy for namespaces and cluster-wide resources. An unstructured repo can be used to maintain ad hoc configuration from one or more YAML file consisting of multiple Kubernetes objects. Unstructured repositories are helpful when you want to expand Helm charts and apply it via ACM.

Let’s get started with the steps to implement GitOps with ACM.

#cloud native #cloud services #kubernetes #feature #cloud