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 it is the best performance of practical experience in production lines [G1] . As Urs Hölzle said, whether it is a public cloud, a private cloud or even a hybrid cloud, Kubernetes will serve as a container management framework for any application and any environment everywhere. Because of this, it is currently favored by major giants and startups, such as Microsoft, VMWare, Red Hat, CoreOS, Mesos, etc., have joined to contribute code to Kubernetes. With the continuous improvement and development of the Kubernetes community and major manufacturers, Kubernetes will become a leader in the field of container management.
Next, we will use a series of articles to explore what Kubernetes is, what it can do, and how to do it.
2. What is Kubernetes
Kubernetes is Google's open-source container cluster management system. It provides functions such as application deployment, maintenance, and expansion mechanisms. Using Kubernetes can easily manage containerized applications running across machines. Its main functions are as follows:
1) Use Docker to package, instantiate, and run the application.
2) Run and manage containers across machines as a cluster.
3) Solve the communication problem between Docker cross-machine containers.
4) The self-healing mechanism of Kubernetes makes the container cluster always run in the state expected by the user.
Currently, Kubernetes supports platforms such as GCE, vShpere, CoreOS, OpenShift, and Azure. In addition, it can also run directly on physical machines.
Next, this article mainly describes Kubernetes from the following aspects:
1) The main concepts of Kubernetes.
2) The components of Kubernetes, including the detailed introduction of the Master component, Kubelet, and Proxy.
3. Kubernetes main concepts
3.1. Pods
Pod is the basic operation unit of Kubernetes. One or more related containers form a Pod. Usually, the containers in the Pod run the same application. The containers contained in the Pod run on the same Minion (Host), which is regarded as a unified management unit and share the same volumes and network namespace/IP and Port space.
3.2. Services
Services is also the basic operation unit of Kubernetes, an abstraction of real application services. Each service is supported by many corresponding containers. Through the port of Proxy and the service selector, the service request is passed to the container that provides the service to the backend, which is expressed as A single access interface, the outside does not need to know how the backend works, which brings great benefits to extending or maintaining the backend.
3.3. Replication Controllers
Replication Controller ensures that the specified number of pods are present in the Kubernetes cluster at any one timeThe replicas (replicas) are running. If there are less than the specified number of pod replicas (replicas), the Replication Controller will start a new Container, otherwise it will kill the excess to keep the number unchanged. Replication Controller creates pods using pre-defined pod templates. Once created successfully, the pod template has nothing to do with the created pods. You can modify the pod template without affecting the created pods, or you can directly update the pods created by Replication Controller. . For pods created using pod templates, the Replication Controller is associated with the label selector, and the corresponding pods can be deleted by modifying the label of the pods. Replication Controller is mainly used as follows:
1) Rescheduling
As mentioned above, the Replication Controller ensures that the specified pod replicas (replicas) in the Kubernetes cluster are running, even in the event of a node failure.
2) Scaling
Horizontally scale up or down running pods by modifying the number of replicas in the Replication Controller.
3) Rolling updates
The design principle of Replication Controller makes it possible to replace pods one by one to roll updates service.
4) Multiple release tracks
If you need to run multiple release services in the system, Replication Controller uses labels to distinguish multiple release tracks.
3.4. Labels
Labels are key/value pairs used to distinguish Pod, Service, and Replication Controller. Pod, Service, and Replication Controller can have multiple labels, but each label's key can only correspond to one value. Labels are the basis for the operation of the Service and Replication Controller. In order to forward the request to access the Service to multiple containers that provide services on the backend, the correct container is selected by identifying the labels of the container. Similarly, Replication Controller also uses labels to manage a set of containers created through pod templates, so that Replication Controller can more easily and conveniently manage multiple containers, no matter how many there are.
4. Kubernetes artifacts
The overall framework of Kubenetes is shown in Figure 3-1, which mainly includes kubecfg, Master API Server, Kubelet, Minion(Host) and Proxy.
Figure 3-1 Kubernetes High Level components
4.1. Master
The Master defines the main declarations of the Kubernetes cluster Master/API Server, including Pod Registry, Controller Registry, Service Registry, Endpoint Registry, Minion Registry, Binding Registry, RESTStorage, and Client. It is the client (Kubecfg) that calls the Kubernetes API and manages Pods, the main components of Kubernetes. , Services, Minions, the entry of the container. Master consists of API Server, Scheduler, and Registry. From Figure 3-2 below, it can be seen that the workflow of the Master is mainly divided into the following steps:
1) Kubecfg sends specific requests, such as creating Pods, to Kubernetes Client.
2) Kubernetes Client sends the request to the API server.
3) The API Server selects the REST Storage API to process the request according to the type of request, for example, when creating a Pod, the storage type is pods.
4) The REST Storage API handles the request accordingly.
5) Store the processed results in the high-availability key-value storage system Etcd.
6) After the API Server responds to the Kubecfg request, the Scheduler will obtain the information of the running Pod and Minion in the cluster according to the Kubernetes Client.
7) Based on the information obtained from the Kubernetes Client, the Scheduler distributes the undistributed Pods to the available Minion nodes.
The following is a detailed introduction to the main components of the Master:
Figure 3-2 Master main components and workflow
3.1.1. Minion Registry
The Minion Registry is responsible for keeping track of how many Minions (Hosts) are in the Kubernetes cluster. Kubernetes encapsulates Minion Registry into a RESTful API interface REST that implements Kubernetes API Server. Through these APIs, we can doCreate , Get, List, Delete operations, because Minon can only be created or deleted, so the Update operation is not supported, and the related configuration information of Minion is stored in etcd. In addition, the Scheduler algorithm determines whether to distribute the newly created Pod to the Minion node according to the resource capacity of the Minion.
3.1.2. Pod Registry
The Pod Registry is responsible for tracking how many Pods are running in the Kubernetes cluster and how these Pods are mapped to Minions. Encapsulate the Pod Registry and Cloud Provider information and other related information into the RESTful API interface REST that implements the Kubernetes API Server. Through these APIs, we can perform Create, Get, List, Update, and Delete operations on Pods, store Pod information in etcd, and monitor Pod changes through the Watch interface, such as when a Pod is newly created, deleted, or updated. .
3.1.3. Service Registry
Service Registry is responsible for tracking all services running in a Kubernetes cluster. According to the provided Cloud Provider and Minion Registry information, the Service Registry is encapsulated into the RESTful API interface REST required by the Kubernetes API Server. Using these interfaces, we can perform Create, Get, List, Update, and Delete operations on the Service, as well as watch operations to monitor changes in the Service, and store the Service information in etcd.
3.1.4. Controller Registry
The Controller Registry is responsible for tracking all Replication Controllers in the Kubernetes cluster. The Replication Controller maintains a specified number of pod replicas. If one of the containers dies, the Replication Controller will automatically start a new container. If the dead container recovers , which will kill the extra containers to keep the specified copy unchanged. By encapsulating the Controller Registry to implement the RESTful API interface REST of the Kubernetes API Server, using these interfaces, we can perform Create, Get, List, Update, Delete operations on the Replication Controller, as well as watch operations to monitor the changes of the Replication Controller, and put the Replication Controller Information is stored in etcd.
3.1.5. Endpoints Registry
The Endpoints Registry is responsible for collecting the endpoints of the Service, such as Name: "mysql", Endpoints: ["10.10.1.1:1909", "10.10.2.2:8834"], the same as the Pod Registry, the Controller Registry also implements the RESTful API of the Kubernetes API Server Interface, which can do Create, Get, List, Update, Delete and watch operations.
3.1.6. Binding Registry
Binding includes an ID that needs to be bound to the Pod and the Host to which the Pod is bound. After the Scheduler writes the Binding Registry, the Pod to be bound is bound to a host. Binding Registry also implements the RESTful API interface of Kubernetes API Server, but Binding Registry is a write-only object, so only the Create operation can be used, otherwise it will cause an error.
3.1.7. Scheduler
The Scheduler collects and analyzes the resource (memory, CPU) load of all Minion nodes in the current Kubernetes cluster, and then distributes the newly created Pods to the available nodes in the Kubernetes cluster accordingly. Because once the resources of Minion nodes are allocated to Pods, these resources cannot be allocated to other Pods unless these Pods are deleted or exited. Therefore, Kubernetes needs to analyze the resource usage of all Minions in the cluster to ensure that the distributed workload does not It will exceed the range of available resources of the current Minion node. Specifically, Scheduler does the following:
1) Real-time monitoring of undistributed Pods in the Kubernetes cluster.
2) To monitor all running Pods in the Kubernetes cluster in real time, the Scheduler needs to safely distribute undistributed Pods to the specified Minion nodes according to the resource status of these Pods.
3) Scheduler also monitors Minion node information. Since Minion nodes are frequently searched, Scheduler will cache a copy of the latest information locally.
4) Finally, after the Scheduler distributes the Pod to the specified Minion node, it will write the Pod-related information Binding back to the API Server.
4.2. Kubelet
Figure 3-3 Kubernetes detailed components
According to Figure 3-3 above, the Kubelet is the connection point between each Minion and the Master API Server in the Kubernetes cluster. The Kubelet runs on each Minion and is a bridge between the Master API Server and the Minion. It receives the data allocated to it by the Master API Server. commands and work, interact with persistent key-value stores etcd, file, server, and http, and read configuration information. The main job of Kubelet is to manage the life cycle of Pod and container, which includes Docker Client, Root Directory, Pod Workers, Etcd Client, Cadvisor Client and Health Checker components. The specific work is as follows:
1) Run a specific Action asynchronously for the Pod through the Worker.
2) Set the environment variables of the container.
3) Bind Volume to the container.
4) Bind the Port to the container.
5) Run a single container against the specified Pod.
6) Kill the container.
7) Create a network container for the specified Pod.
8) Delete all containers of the Pod.
9) Synchronize the state of the Pod.
10) Get container info, pod info, root info, machine info from Cadvisor.
11) Detect the container health status information of the Pod.
12) Run the command in the container.
4.3. Proxy
Proxy is designed to solve the problem that the external network can access the application services provided by the containers in the cross-machine cluster. From Figure 3-3 above, we can see that the Proxy service also runs on each Minion. Proxy provides a proxy for TCP/UDP sockets. Each time a Service is created, Proxy mainly obtains the configuration information of Services and Endpoints from etcd, or can also be obtained from file, and then starts a Proxy process on Minion according to the configuration information and monitors the corresponding Service port. When an external request occurs, the Proxy will distribute the request to the correct backend container for processing according to the Load Balancer.
5. Next topic
The next article describes using Kubernetes to manage containers on CentOS7.
6. Personal Profile
Yang Zhangxian is currently working at Cisco, mainly engaged in WebEx SaaS service operation and maintenance, system performance analysis, etc. Special attention is paid to cloud computing, automated operation and maintenance, deployment and other technologies, especially Go, OpenvSwitch, Docker and its ecosystem technologies, such as Kubernetes, Flocker and other Docker-related open source projects. Email: [email protected]