Shulou(Shulou.com)05/31 Report--

Anthos Config Management product design analysis, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

0. What is Anthos Config Mangement? Hello World Demo

You can take a look at Arctiq's modification of node quantity, Demo: https://www.arctiq.ca/our-blog/2019/4/9/gke-on-prem-and-anthos-config-management/.

To put it simply, when you modify a yaml configuration file managed by a git, which describes the number of node of a cluster in a GKE private cluster, then Anthos Config Management will automatically issue commands for you and change the number of nodes to the one you want.

What is Anthos?

It is a hybrid cloud platform released by google.

The command and control core of GKE:Anthos. Users manage the infrastructure scattered in the Google cloud and other cloud platforms at the private data center level through the control plane of GKE.

GKE On-Prem:Google has launched a software platform based on Kubernetes that is consistent with GKE. Users can deploy the product on any compatible hardware, and Google will manage it. From upgrading the Kubernetes version to applying the latest patches, Google sees it as a logical extension of GKE. In particular, it should be noted that GKE On-Prem runs on the virtualization basis of VMWare vSphere 6.5, and support for other virtualization technologies such as Hyper-V and KVM is still under development.

Istio: this technology makes cross-platform federated network management possible. Anthos needs to build service grids for components of multiple applications deployed in different data centers, GCP, and other clouds, and Istio is naturally the first choice. It integrates seamlessly with SDN such as VMWare NSX, Cisco ACI, and Google's own Andromeda. Customers who have invested in network facilities, such as F5, can integrate Istio with load balancing and firewalls.

Velostrata:Google acquired this cloud migration technology in 2018 to enhance the competitiveness of Kubernetes. The main function of Velostrata is to copy physical / virtual machines in GCE instances and convert existing virtual machines into Kubernetes applications (Pod). This is the industry's first physical machine to Kubernetes migration tool, provided by Google. This technology appears as Anthos Migrate, which is currently in the Beta phase.

Anthos configuration management: Kubernetes is an extensible policy-driven platform. Anthos customers have to deal with multiple Kubernetes running in different environments, so Google tries to take advantage of Anthos to simplify configuration management. Anthos configuration management can manage and apply configurations to one or more clusters from publishing artifacts, configuration projects, network policies, ciphertext, and passwords.

Stackdriver:Stackdriver provides observable support for Anthos infrastructure and applications. Customers can use this component to track the status of applications running on the Anthos cluster and the health of applications deployed on various managed clusters. This component is responsible for centralized support for monitoring, logging, tracking, and observation.

GCP Cloud Interconnect: high-speed interconnection between enterprise data centers and cloud infrastructure is a necessary condition for hybrid cloud platforms. Cloud Interconnect can deliver high-speed networks up to 100Gbps between the data center and the cloud. Customers can also extend their data centers to GCP using the networks of telecom vendors such as Equinix, NTT Communications, Softbanck, etc.

GCP Marketplace:Google is a list of software (from ISV and open source) that can run on Kubernetes. Users can deploy software such as Cassandra database or GitLab in Anthos with one click. Eventually, Google may also provide a private Catalog service for internal IT.

As you can see, of these eight components, only about 4 and 5 have been launched recently, and the others have long been put into production and used by many enterprises. what is the relationship between these components? Let's put these components on a picture and look like this (forgive me for ignoring poor StackDriver and Marktplace, but I assume the reader is familiar with these two things)

In other words, Anthos Config Management is a bottle of glue that automates the configuration of applications in the hybrid cloud.

Wait a minute, what is configuration automation?

The term is too broad, so here are a few common K8s user scenarios

Have you ever come across a typical Web application that has a configuration file in the test environment (we assume it is a yaml of K8s deployment), a profile in a quasi-production environment, a profile in the public cloud, and a profile in the private cloud? Each time you copy and paste and modify some parameters, and expect these environments to be mixed to provide reasonable services to end users, but manual modifications often lead to errors

Have you ever encountered that the configuration files are stored in multiple K8s clusters, and each time you have to modify them one by one with kubectl, but you can't see the historical versions of these configurations? You can roll back the docker image of the application, but you cannot roll back the configuration. If you are a veteran K8s player, you certainly know that there are all the historical versions of yaml in a corner of etcd. You can still find history through some dark magic command line operation, but it is certainly not as straightforward as git.

Yes, Anthos Config Management is used to solve these problems, and it is done according to the concept of Infrasturce as code.

Go on to ask another question, why is configuration so important?

As we all know, in the traditional Unix/Linux environment, there are many configuration files under / etc, and most tough operation and maintenance engineers modify these files every day, and make these configurations take effect by restarting the process or signaling the process, and modify hundreds of machines; in the past few years, batch tools such as ansible or salt have saved the workload of logging on hundreds of machines In addition to solving the batch problem of the cluster, K8s also introduces a new concept, that is, declarative configuration, operation and maintenance engineers do not need to restart processes, these "processes" will automatically reach the desired state according to your configuration (of course, since this is in a cluster, it will take a certain amount of time), that is to say,

Declarative configuration = final state oriented

So, the configuration you write is completely different from the traditional configuration file, the static text configuration, and eventually these configurations will become a state of the production system, and if you use a reasonable tool chain, this series of work is automated.

So are these "configuration files" still configured? The work flow of the operation and maintenance engineer becomes

Git pull

Read, think, modify

Git push / / all things done automaticlly

Yes, you will find that the operation and maintenance engineer's work flow is the same as the development engineer!

These configurations, no matter what language they are written, essentially become source code, but are robust not by compiling the tool chain but through the operation and maintenance tool chain. in this way, the repetitive work of traditional operation and maintenance is taken out of the hands of most people and handed over to a small number of operation and maintenance tool chain experts for maintenance.

1. Interior design

At this point, Google didn't release the source code for this thing, but there is a picture.

Yes, this picture is very clear on the components, Anthos Config Mangement, in the running form is a K8s operator, deployed in multiple clusters, and should be able to read the configuration from the same remote git repo. From this demo library, we can see that this operator reads the configuration of the git library.

ApiVersion: addons.sigs.k8s.io/v1alpha1kind: ConfigManagementmetadata: name: config-managementspec: git: syncRepo: git@github.com:GoogleCloudPlatform/csp-config-management.git syncBranch: "0.1.0" syncWait: 5 secretType: ssh policyDir: foo-corp

Here several parameters clearly indicate that Anthos Config Mangement will read the 0.1.0 branch of git repo every 5 seconds and follow the configuration on this branch. So, what can these operations do and how can they be done? The official documentation is so pathetic that it just wants to dismiss us in a few words, but from Demo we can try to find the corresponding relationship between these features and configuration. Readers can git clone the demo library and compare it.

The official functional description is:

Authenticity, control, and management derived from a single code base

Allows the use of code review, validation, and rollback workflows.

Avoid shading operations, which are out of sync between Kubernetes clusters due to manual changes.

Allows automated testing and deployment using the CI / CD pipeline.

One-step deployment across all clusters

Anthos Config Management converts a single Git submission into multiple kubectl commands across all clusters.

Simply restore the changes in Git and roll back. Then, large-scale automatic deployment recovery.

Rich inheritance model to simplify modification

Using namespaces, you can create configurations for all clusters, some clusters, some namespaces and even custom resources.

Using namespace inheritance, you can create a hierarchical namespace model that allows configuration inheritance across repo folder structures.

This is the tree directory structure of demo

. ├── cluster │ ├── namespace-reader-clusterrole.yaml │ ├── namespace-reader-clusterrolebinding.yaml │ ├── pod-creator-clusterrole.yaml │ └── pod-security-policy.yaml ├── namespaces │ ├── audit │ │ └── namespace.yaml │ ├── online │ │ shipping-app-backend pod-creator-rolebinding.yaml │ ├── quota.yaml │ │ ├── shipping-dev │ ├── job-creator-role.yaml │ ├── job-creator-rolebinding.yaml │ ├── namespace.yaml │ │ quota.yaml shipping-prod │ │ └── namespace.yaml │ │ └── shipping-staging │ │ └── namespace.yaml │ ├── sre-rolebinding.yaml │ ├── sre-supported-selector.yaml │ └── viewers-rolebinding.yaml └── system ├── config-management.yaml └── resourcequota-hierarchy.yaml

I believe that anthos's workflow should be to read some of the security configurations in cluster and create the namespaces described in the namespace directory here on all clusters.

We also see the clusterregistry directory in some demo videos, which should be used to modify some attributes of the cluster to achieve the purpose of dynamically modifying the number of nodes.

However, there is no trace of how to make multiple namespace flows in multiple clusters. From the nested directories of namespace, the application WorkLoad will go through the levels of these directories, and then dynamically modify some of its own configurations. These details have yet to be studied.

two。 Core insight of the conclusion

Anthos thought of these two points in a multi-K8s cluster scenario.

Since K8s changes the state of everything into a static yaml text description, it is inefficient for these configurations to be stored in etcd and modified with kubectl, and can be saved in git.

There is redundancy between these configurations, and the configuration of single application and multi-cluster can be done automatically by templating.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.