One of the common challenges faced by enterprises is how to ensure deployment configurations are always consistent with the required desired state across environments (hybrid and multicloud) and can be audited and monitored whenever required. That’s where Anthos Config Management comes into play which allows to define configurations, policies and custom rules in a centralized place, which is applied and enforced to all the required GKE clusters to provide the required desired state.
Following shows the architecture for Anthos Config Management.
A central Git repository acts as a single source of truth for all deployment configurations. The config repository in the above diagram holds all the configurations. The repository can be deployed at a location where it can be accessed from all your environments. For a hybrid environment, the repository would be typically hosted on-prem to leverage existing access control and any audit requirements.
Anthos Config Management provides a set of components that ensures any changes from the Git repository is applied to all the clusters and validated from time to time. These components needs to be installed on the all the required GKE clusters. The key components includes
- Config Sync – The Config Sync component synchronizes the config repository and applies them on the respective GKE clusters. Any difference between the actual state of the GKE cluster and stored configuration is actively monitored and reconciled. We will go through a sample config repository in the next section.
- Policy Controller – Policy Controller component interprets request to the GKE cluster before they are activated to verify your defined cluster policies related to security or any custom business rules and ensure they are compliant. The Policy Controller component blocks any changes to the clusters that doesn’t comply to the defined policies.
- Config Connector – Config connector is an add-on component to configure supported Google Cloud services like BigQuery, Compute Engine using Kubernetes APIs. Application using the services can configure these services by creating the required config connector configurations.
- Binary Authorization – Binary Authorization component is an optional component that can be installed to ensure only trusted container images are deployed in the GKE cluster. Lot of enterprises allows only verified images to be installed which pass their information security requirements and image scans policy and by applying the Binary Authorization configuration, the required images can be signed and verified during deployment.
As shown in the above architecture diagram, the ACM Operator is installed on all GKE Clusters. The operator uses the Config Sync configuration to pull the configuration from the Git repository and convert the configurations into objects that can be applied on the GKE Cluster. The operator periodically checks if the status of the cluster matches the configuration and reconciles them. For instance, if you accidentally delete a namespace from the cluster that exist in the configuration, you will see the namespace automatically being created on the cluster.
We would go over the steps of setting up the ACM component in detail during the course of this book.