(reprint) Introduction of Kubernetes architecture and components of open source container cluster Management system

Recently in the Docker and her management tools, the selection of kuberetes, by her terminology and concepts to get dizzy ... Read an article is not bad, put it here to share.

Address: http://www.linuxidc.com/Linux/2015-12/125757.htm

The citations are as follows:

As an important member of the Docker ecosystem, Kubernetes is an open source version of Google's many years of large-scale container management technology and is the best practice for line-of-production experience. As Urs Hölzle says, whether it's a public cloud or a private cloud or even a hybrid cloud, kubernetes will act as a container management framework for any application, any environment, everywhere. Because of this, it is now favored by major giants and start-ups, such as Microsoft, VMWare, Red Hat, CoreOS, Mesos, and so on, have joined the kubernetes contribution code. With the continuous improvement and development of kubernetes community and major manufacturers, Kuberentes will become the leader in the field of container management.

Next we explore what kubernetes is, what we can do and how we do it.

1. What is Kubernetes

Kubernetes is Google open-source container cluster management system, using Golang development, which provides application deployment, maintenance, extension mechanism and other functions, using kubernetes can easily manage the cross-machine operation of containerized applications, the main functions are as follows:

1. Use Docker for application wrapping (package), instantiation (instantiate), and run.
2. Run and manage containers across machines in a clustered way.
3. Resolve communication issues between Docker's cross-machine containers.
4. Kubernetes's self-healing mechanism makes container clusters always run in the user's desired state.

The current kubernetes supports GCE, Vshpere, CoreOS, OpenShift, Azure and other platforms, and can also be run directly on physical machines.

This official gives the complete architecture diagram: (can be enlarged to see)

2. Kubernetes's main concept 2.1 Pods

In Kubernetes systems, the smallest particle of dispatch is not a simple container, but an abstraction into a pod,pod is the smallest deployment unit that can be created, destroyed, dispatched, and managed. The associated one or more containers (Container) Form a pod, usually in pod containers running the same application. Pods contain containers that run on the same minion (Host), as a single snap-in that shares the same volumes and network NAMESPACE/IP and port space.

2.2 Services

Services is also the basic operating unit of Kubernetes, is the abstraction of real application services, each service has a lot of corresponding containers to support, through the proxy port and service selector to determine the service request passed to the backend service container, External performance is a single access address, the outside does not need to understand how the backend is running, which brings great benefits to the extended or maintenance backend.

This is particularly clear on GitHub's official website document SERVICES.MD.

2.3 Replication Controllers

Replication Controller, which is understood as a more complex form of pods, ensures that at any time a specified number of pod copies (replicas) in the Kubernetes cluster are running, if less than a specified number of pod copies (replicas), The Replication controller initiates a new container, which in turn kills the excess to ensure that the quantity is constant. Replication Controller uses a pre-defined pod template to create the pods, and once created, the pod template is not associated with the pods created, and you can modify the pod template without any effect on the created pods. You can also update the pods created by replication controller directly. For pods,replication controllers created with the pod template to associate with the label selector, the corresponding pods can be deleted by modifying the Pods label. Replication Controller has the following main use:

Rescheduling
As mentioned above, the Replication controller ensures that the specified pod copy (replicas) in the Kubernetes cluster is running, even when the node is faulted.

Scaling
The pods of the run is scaled horizontally by modifying the number of copies of the replication controller (replicas).

Rolling updates
The design principle of the Replication controller allows the pods to be replaced one by one to roll up the update (rolling updates) service.

Multiple release tracks
If you need to run multiple release services in your system, Replication controller uses labels to differentiate multiple release tracks.

The above three concepts are user-operable rest objects. Kubernetes is handled as an interface that is open in the form of Restfull APIs.

2.4 Labels

Service and Replicationcontroller are just abstractions built on the pods, and ultimately for pods, how do they relate to pods? This introduces the concept of label: The label is well understood to add a set of Key/value tags that can be used for search or association, and service and Replicationcontroller are associated with the pod via a label. In order to forward requests for access to the service to multiple containers that provide services to the backend, it is by identifying the container's labels to select the correct container; Replication controller also uses labels to manage a set of containers created through pod templates. This replication controller makes it easier and easier to manage multiple containers.

As shown, there are three pods with the label "App=backend", and when creating service and Replicationcontroller you can specify the same label: "App=backend", and then through the label selector mechanism, They are associated with these three pods. For example, when another frontend pod accesses the service, it is automatically forwarded to one of the backend pods.

3. Kubernetes Components

Kubenetes overall framework such as, mainly includes kubecfg, Master API Server, Kubelet, Minion (Host) and proxy.

3.1 Master

Master defines the main statements for the Kubernetes cluster MASTER/API server, including pod Registry, Controller Registry, Service Registry, Endpoint Registry, Minion Registry, Binding Registry, Reststorage, and client, is the client (kubecfg) call Kubernetes API, management kubernetes main components pods, Access to Services, Minions, and containers. Master is made up of API Server, Scheduler, and registry. From the known master workflow is mainly divided into the following steps:

1. Kubecfg sends a specific request, such as creating a pod, to the Kubernetes Client.
2. Kubernetes client sends the request to API server.
3. The API server is based on the type of request, such as the Storage type is pods when the pod is created, and then the rest Storage API is chosen to process the request accordingly.
4. The REST Storage API handles the request accordingly.
5. The processed results are stored in the high-availability key-value storage System ETCD.
6. After the API server responds to the KUBECFG request, Scheduler runs pod and minion information in the cluster based on the Kubernetes client.
7. Based on the information obtained from the Kubernetes client, Scheduler distributes the unallocated pod to the available Minion nodes.

The following is a detailed description of Master's main artifacts.

3.1.1 Minion Registry

Minion Registry is responsible for tracking how many minion (Host) are in the Kubernetes cluster. Kubernetes Package Minion Registry to implement the RESTful API interface rest of Kubernetes API server, through which we can create, Get, List, The delete operation, since Minon can only be created or deleted, does not support the update operation and stores the minion related configuration information to ETCD. In addition, the scheduler algorithm determines whether the new pod is distributed to the Minion node based on the Minion's resource capacity.

You can curl http://{master-apiserver-ip}:4001/v2/keys/registry/minions/ verify what is stored in the ETCD.

3.1.2 Pod Registry

Pod Registry is responsible for tracking how many pods are running in the Kubernetes cluster, and how these pods map to minion. Encapsulates pod registry and cloud provider information and other related information to implement RESTful API interface rest for Kubernetes API server. With these APIs, we can create, Get, List, UPDATE, delete operations on pods, store pod information in Etcd, and monitor pod changes through the watch interface, such as a pod being created, deleted, or updated.

3.1.3 Service Registry

Service Registry is responsible for tracking all services running in the Kubernetes cluster. The service registry is encapsulated as a RESTful API interface rest that implements Kubernetes API server, based on the cloud provider and Minion registry information provided. With these interfaces, we can create, Get, List, Update, delete operations on the service, and watch operations that monitor service changes, and store service information in ETCD.

3.1.4 Controller Registry

Controller Registry is responsible for tracking all Replication controller,replication controllers in the Kubernetes cluster maintaining a specified number of copies of the pod copy (replicas). If one of the containers dies, the Replication controller automatically launches a new container, and if the dead container resumes, it kills the extra container to ensure that the specified copy does not change. By encapsulating the Controller registry to implement the RESTful API interface rest of Kubernetes API server, we can use these interfaces to create, Get, The List, Update, delete operations, and watch operations that monitor the replication controller changes, and store the replication controller information in ETCD.

3.1.5 Endpoints Registry

Endpoints Registry is responsible for collecting service endpoint, such as name: "MySQL", Endpoints: ["10.10.1.1:1909", "10.10.2.2:8834"], same pod Registry,controller Registry also implements the RESTful API interface for Kubernetes API server, which can do create, Get, List, Update, delete, and watch operations.

3.1.6 Binding Registry

The binding includes an ID that needs to bind the pod and the pod is bound to the Host,scheduler write binding registry, and the pod to bind to is bound to a host. The binding registry also implements the Kubernetes API server's RESTful API interface, but the binding registry is a Write-only object, all only the create operation can use, otherwise it will cause an error.

3.1.7 Scheduler

Scheduler collects and analyzes the resource (memory, CPU) load of all Minion nodes in the current Kubernetes cluster, and then distributes the newly created pod to the nodes available in the Kubernetes cluster. Because once the Minion node's resources are assigned to the pod, the resources are no longer allocated to other pods, unless the pods are deleted or exited, so kubernetes needs to analyze the resource usage of all Minion in the cluster. Ensure that the distribution of the workload does not exceed the current Minion node's available??? Resource scope. Specifically, Scheduler does the following:

1. Real-time monitoring of non-distributed pods in kubernetes clusters.
2. Real-time monitoring of all running Pod,scheduler in the Kubernetes cluster requires that the unallocated pod be distributed securely to the specified Minion node based on the resource conditions of these pods.
3. Scheduler also monitors minion node information, and scheduler caches an up-to-date information locally due to frequent lookups of minion nodes.
4. Finally, after distributing the pod to the specified Minion node, scheduler writes the pod-related information binding back to API Server.

3.2 Kubelet

According to the known kubelet is the connection point of each Minion and Master API server in the Kubernetes cluster, Kubelet runs on each minion and is the bridge between the Master API server and the minion. Receives the commands and work assigned to it by the master API server, interacts with the persistent key-value store Etcd, file, server, and HTTP to read configuration information. Kubelet's main job is to manage the Pod and container lifecycle, including Docker client, Root Directory, pod Workers, ETCD client, Cadvisor client, and health checker components , the specific work is as follows:

1. Asynchronously runs a specific action for a pod through a worker
2. Setting environment variables for a container
3. Bind a volume to a container
4. Bind Port to Container
5. Runs a single container based on the specified pod
6. Kill the Container
7. Create a network container for the specified pod
8. Remove all containers from pod
9. Synchronizing the status of Pods
10. Get container info, pod info, root info, machine info from Cadvisor
11. Detecting container health status information for pods
12. Run the command in the container.

3.3 Proxy

Proxies are designed to address the ability of an external network to access application services provided across a machine cluster, running on each minion. Proxy provides a proxy for TCP/UDP sockets, each creating a service,proxy primarily from ETCD to obtain services and endpoints configuration information (also available from file), Then, based on the configuration information, a proxy process is started on Minion and the corresponding service port is monitored, and when an external request occurs, proxy distributes the request to the correct container processing on the backend based on the load balancer.

Therefore, the proxy not only solves the problem of the same host service port conflict, but also provides the service forwarding service Port's ability to provide services externally, the proxy backend uses the random, round-robin load balancing algorithm. For more Kube-proxy content kubernetes code Minion NODE component Kube-proxy.

4. Etcd

Etcd mentioned a few times on the top of the frame, but it's not part of the kubernetes, it's a management configuration information and services Discovery (Service discovery) project initiated by the CoreOS team. The goal is to build a highly available distributed key-value (Key-value) database. As with Kubernetes and Docker, products that are in rapid iterative development are not as mature as zookeeper. Have the opportunity to introduce another article.

(reprint) Introduction of Kubernetes architecture and components of open source container cluster Management system