Anthos in a nutshell

How to manage and orchestrate multi-clusters across many cloud providers.

Anthos as an orchestrator for different technologies

Anthos is a Kubernetes (K8S) distributed agent in charge of applying multi-cluster-wide configurations across different platforms.

Anthos relies on version control software to store and distribute cluster configurations and deployments.

The semantics for governance and auditing process of K8S depend on the organization’s requirements.

In this article, we will review a Basic Reference Architecture to deploy Anthos. We will also expose the required preparations to onboard K8S Clusters to be managed by Anthos.

Reference Architecture

Follows a basic reference architecture on connecting many K8S Clusters across different providers. This allows us to have a single glass pane for its management and configuration.

Anthos architecture reference

Each required K8S Cluster requires a component embedded within the cluster's realm. Said component performs callback functions to the main Google Cloud Platform (GCP) project. This particular project is also known as the host project. Its main goal is to manage and configure fleets of K8S.

The Anthos Config repository can be hosted in any source repository that respects the git interface of commands. That is, as long Google Kubernetes Engine (GKE) has read access to it.

Preparation of K8S Cluster

To prepare each K8S Cluster to be managed by Anthos, four steps are needed:

• For each cluster: install Anthos configuration management in the cluster:

kubectl apply -f config-management-operator.yaml

Access to the Anthos Config Management tools can be found here.

• Create YAML deployment files (one for each cluster) with the following key elements to consider:

…
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
 name: config-management
 namespace: config-management-system
spec:
 clusterName: cluster_name
 git:
 syncRepo: url_to_git_path
 syncBranch: git_branch
 secretType: ssh
 policyDir: “custom_directory”
…

cluster_name must be unique for each cluster. As a consequence you will end up with as many config_management_cluster_name.yaml files as clusters you have to manage.

• Apply the previous configuration for each cluster:

kubectl apply -f config_management_cluster_name.yaml

• For each cluster: configure git access credentials within K8S

#kubectl create secret generic git-creds — namespace=config-management-system — from-file=ssh=PATH_TO_PRIVATE_KEY

That is the configuration needed to synchronize all clusters against a centralized repository.

Now, it's only reasonable to ask how we know the status of synchronization, and the answer to that comes in the form of a binary named nomos.

The binary package nomosis also downloadable from the Anthos download page. It is written in Go, and it is available for various platforms. The basic usage is as follows:

#nomos -h
Set up and manage a Anthos Configuration Management directory (version v1.1.1-rc.4)Usage:
  nomos [command]Available Commands:
  help        Help about any command
  hydrate     
  init        Initialize a Anthos Configuration Management directory
  status      Prints the status of all clusters with Configuration Management installed.
  version     Prints the version of ACM for each cluster as well this CLI
  vet         Validate a Anthos Configuration Management directoryFlags:
  -h, --help   help for nomosUse "nomos [command] --help" for more information about a command.

That means when you run nomos status, it will output the status for each managed cluster.

#nomos status
Connecting to clusters...
Current   Context    Status       Last Synced Token   Sync Branch
-------   -------    ------       -----------------   -----------
*         cluster_1  SYNCED       1b664887            master   
          cluster_2  SYNCED       1b664887            master

In this case, kubectl is connected to cluster_1. Such cluster is fully synchronized against the repository with commit id 1b664887. Also, synchronization happens with the main branch from the repository. Any commit to such a branch will trigger an update on each cluster.

Last is the folder structure needed to host all cluster configurations.

We can use the nomos init command to set up a basic cluster structure. Once executed, it will create a tree like this:

cluster_1
├── README.md
├── cluster
├── clusterregistry
├── namespaces
└── system
    ├── README.md
    └── repo.yaml

To get a complete reference on repository structure and semantics, you can check the Anthos reference guide.

To verify an existing repository, you can use the nomos vet command.

nomos vet --path=./cluster_1

Finally, you can start with an empty configuration repository or use an existing demo repo. In the demo-repo, there is a foo-corp cluster configuration for you to check and execute the most basic deployments.

Conclusion

In summary, we saw how to configure Anthos on each cluster (GKE or otherwise). We have also seen how to check the cluster status and initialize a repository to host cluster configurations.