Introduction to Kubernetes system architecture

1. Preface

Together we'll ensure that Kubernetes are a strong and open container management framework for all application and in any Environment, whether in a private, public or hybrid cloud.

Urs Hölzle, Google

As an important member of the Docker ecosystem, Kubernetes is an open source version of Google's large-scale container management technology for many years, and is the best practice for production line experience [G1]. 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'll use a series of articles to explore what kubernetes is, what to do and how to do it.

2. What is Kubernetes

Kubernetes is the Google Open Source container cluster Management system, which provides application deployment, maintenance, extension mechanisms 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 manner.

3) solve the problem of communication between docker across 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.

Next, this paper mainly elaborates kubernetes from the following aspects:

1) The main concept of kubernetes.

2) Kubernetes components, including the master component, Kubelet, proxy detailed introduction.

3. kubernetes Main Concept 3.1. Pods

The pod is the basic operating unit of the Kubernetes, which forms one or more of the associated containers into 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.

3.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 interface that does not require an understanding of how the backend works, which can be a significant benefit to the extended or maintenance backend.

3.3. Replication Controllers

Replication Controller ensures that at any time a specified number of pod copies (replicas) are running in the Kubernetes cluster, if fewer than a specified number of pod copies (replicas), Replication The 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:

1) 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.

2) Scaling

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

3) Rolling Updates

The design principle of the Replication controller allows the pods to be rolling to the updates service with one-to-one replacement.

4) Multiple release tracks

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

3.4. Labels

Labels is a key/value key pair used to differentiate pod, service, Replication Controller, pod, service, Replication controller can have more than one label, However, each label key can only correspond to one value. Labels is the basis for service and replication controller operation, 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. Similarly, the Replication controller uses labels to manage a set of containers created through pod templates, so that Replication controller makes it easier and easier to manage multiple containers, regardless of the number of containers.

4. Kubernetes Components

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

Figure 3-1 Kubernetes High Level widget

4.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 3-2, Master's 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) API server depends on the type of request, such as the Storage type is pods when creating the pod, and then chooses which rest Storage API to handle the request.

4) The REST Storage API handles the request accordingly.

5) Store the processed results in a high-availability key-value storage System ETCD.

6) After the API server responds to the KUBECFG request, Scheduler will get the 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 components:

Figure 3-2 Master main components and workflow

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.

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 distributed workload does not exceed the available resource range for the current Minion node. Specifically, Scheduler does the following:

1) real-time monitoring of non-distributed pods in the Kubernetes cluster.

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 status of these pods.

3) Scheduler also monitors Minion node information, because the Minion node is frequently found, scheduler caches a copy of the latest information locally.

4) Finally, after distributing the pod to the specified Minion node, scheduler writes the pod-related information binding back to API Server.

4.2. Kubelet

Figure 3-3 kubernetes Detail Widget

According to 3-3, Kubelet is the connection point for each Minion and Master API server in the Kubernetes cluster, Kubelet runs on each minion and is the bridge between Master API server and 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 the pod through the worker.

2) Set the environment variables for the container.

3) Bind the volume to the container.

4) Bind port to the container.

5) Run a single container according to the specified pod.

6) Kill the container.

7) Create a network container for the specified pod.

8) Remove all containers from the pod.

9) Synchronize the status of the pod.

10) Get container info, pod info, root info, machine info from Cadvisor.

11) Detection of POD health status information.

12) Run the command in the container.

4.3. Proxy

Proxy is designed to address the external network's ability to access the application services provided across the container in the machine cluster, and from 3-3 the proxy service is also running on each minion. Proxy provides TCP/UDP sockets proxy, each creating a service,proxy mainly from ETCD to obtain services and endpoints configuration information, or can also be obtained 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.

5. Next Topic

The next chapter is about using Kubernetes to manage containers on CentOS7.

6. Personal Profile

Yang Zhangxin, currently working for Cisco, is mainly engaged in WebEx SaaS service operations, system performance analysis and so on. Special attention is paid to technologies such as cloud computing, automated operations and deployment, especially go, Openvswitch, Docker and its ecosystem technologies, such as Docker-related open source projects such as Kubernetes and Flocker. Email: [email protected]

7. References

1. Https://github.com/GoogleCloudPlatform/kubernetes/tree/master/docs
2. Http://www.slideshare.net/rajdeep
3. Http://www.docker.com

Thank Guo for the planning and revision of this article.

See Http://www.infoq.com/cn/articles/Kubernetes-system-architecture-introduction in the original

Introduction to Kubernetes system architecture