Introduction to Kubernetes system Architecture __java

Kubernetes, as an important member of the Docker ecosystem, is an open source version of Google's many years of large-scale container management technology, as Urs Hölzle said, whether it is a public cloud or a private cloud or even a hybrid cloud, kubernetes will be used as an application for any The container management framework for any environment is ubiquitous. Because of this, it is now favored by major and start-up companies, such as Microsoft, VMWare, Red Hat, CoreOS, Mesos, and so on, have added to the Kubernetes contribution code. With the continuous improvement and development of kubernetes community and major manufacturers, Kuberentes will become the leader in container management field.

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 Google open source container cluster Management system, which provides application deployment, maintenance, extension mechanism and other functions, the use of kubernetes can easily manage the application of the container-run across the machine, its main functions are as follows:

1 Use Docker for application wrapping (package), instantiating (instantiate), running (run).

2 to run and manage the containers across the machine in a cluster manner.

3 to solve the communication problem between Docker and cross machine containers.

4 Kubernetes's self-healing mechanism makes the container cluster always run in the user's desired state.

The current kubernetes support GCE, Vshpere, CoreOS, OpenShift, Azure and other platforms, in addition, can also run directly on the physical machine.

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

1) The main concepts of kubernetes.

2) Kubernetes components, including master component, Kubelet, proxy detailed introduction. 3. kubernetes Main concept 3.1. Pods

Pod is the basic operating unit of a kubernetes, which forms a pod of the relevant one or more containers, and usually the container in the pod runs the same application. The pod contains containers that run on the same minion (Host) as a unified snap-in, sharing the same volumes and network NAMESPACE/IP and port spaces. 3.2. Services

Services is also the basic unit of operation of Kubernetes, is the abstraction of the real application service, each service has a lot of corresponding containers to support, through proxy port and service Selector decision Service request pass to the back-end service delivery container, External performance as a single provider, the outside does not need to understand how to run the backend, which has great benefits to extend or maintain the backend. 3.3. Replication controllers

Replication controller Ensure that a specified number of pod replicas (replicas) are running at any time in the Kubernetes cluster, if less than a specified number of pod replicas (replicas), Replication Controller will start a new container, whereas it will kill extra to keep the quantity unchanged. Replication controller uses a predefined pod template to create pods, and once the creation is successful, the pod template has nothing to do with the pods created, and you can modify the pod template without having any effect on the created pods. You can also update the pods created by replication controller directly. The Pods,replication controller created using the pod template is associated according to the label selector, and the corresponding pods can be deleted by modifying the Pods label. Replication controller mainly uses the following:

1) Rescheduling

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

2) Scaling

Expand or shrink the running pods horizontally by modifying the number of copies (replicas) of the replication controller.

3) Rolling Updates

The design principle of Replication controller makes it possible to replace pods to rolling updates service one by one.

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 used to differentiate the Key/value key pairs of pod, service, Replication Controller, pod, service, Replication controller can have more than one label, But each label key can only correspond to one value. Labels is the basis for service and replication controller operations, and in order to forward requests for access to services to multiple containers that provide service to the backend, it is by identifying the labels of the container that the correct container is selected. Similarly, Replication controller uses labels to manage a set of containers created through the pod template, so that Replication controller makes it easier and easier to manage multiple containers, no matter how many containers. 4. Kubernetes Components

The Kubenetes overall framework is shown in Figure 3-1, which 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 declarations of the Kubernetes cluster MASTER/API server, including pod Registry, Controller Registry, Service Registry, Endpoint Registry, Minion Registry, Binding Registry, Reststorage, and client, are client (KUBECFG) invoke Kubernetes API, Management kubernetes main component pods, Access to Services, Minions and containers. Master consists of API Server, Scheduler, and registry. From figure 3-2 below, Master's workflow is mainly divided into the following steps:

1 Kubecfg a specific request, such as creating a pod, to send to Kubernetes Client.

2 Kubernetes client sends the request to the API server.

3 API Server According to the type of request, such as the Storage type when creating pod is pods, then choose which rest Storage API to process the request accordingly.

4 The REST Storage API handles the request accordingly.

5 The processed results are stored in the high available key value storage System ETCD.

6 after the API server responds to KUBECFG's request, scheduler will run pod and minion information in the Kubernetes client acquisition cluster.

7 According to the information obtained from the Kubernetes client, Scheduler distributes the undistributed pod to the available Minion nodes.

The following is a detailed description of the main components of master:

Figure 3-2 Master main component and Workflow 3.1.1. Minion Registry

Minion Registry is responsible for tracking the number of Minion (Host) in the Kubernetes cluster. The Kubernetes package Minion registry the RESTful API interface rest for implementing Kubernetes API server, through which we can create, get, List, Delete operation, because Minon can only be created or deleted, the update operation is not supported and Minion configuration information is stored to ETCD. In addition, the scheduler algorithm determines whether the new pod is distributed to the Minion node according to the Minion 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 pod and Minion are mapped. Encapsulate Pod Registry and cloud provider information and other related information into the RESTful API interface rest that implements the Kubernetes API server. With these APIs, we can create, get, List, UPDATE, delete operations on POD, 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. According to the cloud provider and Minion registry information provided, the service registry is encapsulated into the Kubernetes API interface rest required to implement RESTful API server. With these interfaces, we can perform create, get, List, Update, delete operations on the service, and watch operations to monitor service changes and store service information to ETCD. 3.1.4. Controller Registry

Controller Registry is responsible for tracking all Replication controller,replication Controller in the Kubernetes cluster to maintain a specified number of pod copy (replicas) copies. If one of the containers dies, Replication controller automatically launches a new container, and if the dead container recovers, it kills the extra containers to ensure that the specified copy does not change. By encapsulating Controller Registry to implement the RESTful API interface rest for Kubernetes API server, we can use these interfaces to create, get, List, Update, delete operations, and watch actions to monitor replication controller changes, and store replication controller information to 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"], with 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

Binding includes an ID that needs to bind the pod and the pod bound Host,scheduler write binding registry, the pod to bind to is bound to a host. Binding Registry also implements the RESTful API interface for Kubernetes API server, but Binding registry is a Write-only object that can be used by all only create operations, causing errors. 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 new pod to the Kubernetes cluster nodes that are available. Because once the Minion node's resources are allocated to the pod, the resources are no longer allocated to other pods, unless the pod is 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 scope of the current Minion node. Specifically, scheduler do the following:

1) real-time monitoring of kubernetes pod in the cluster.

2 The real-time monitoring of all running Pod,scheduler in the Kubernetes cluster requires the safe distribution of the undistributed pod to the specified Minion node based on these pod resource conditions.

3 Scheduler also monitors Minion node information, because it will frequently look up Minion nodes, scheduler caches an updated information locally.

4 Finally, scheduler the pod-related information binding to the API Server after distributing the pod to the specified minion node. 4.2. Kubelet

Figure 3-3 kubernetes Detail Widget

According to figure 3-3 above, 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, interacting with persistent key-value storage Etcd, file, server, and HTTP to read configuration information. Kubelet's main job is to manage the lifecycle of pods and containers, including 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 through the worker to the pod.

2 Set the environment variable of the container.

3) Bind 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 of pod.

9 synchronization of Pod status.

10 from Cadvisor get container info, pod info, root info, machine info.

11 Detection of POD container health status information.

12 Run the command in the container. 4.3. Proxy

Proxy is designed to address the application services provided by containers across the machine cluster, and the proxy service runs on each minion, as shown in Figure 3-3 above. Proxy provides proxy for TCP/UDP sockets, each of which creates a service,proxy that obtains services and endpoints configuration information primarily from ETCD, or can be obtained from file, Then, based on the configuration information, a proxy process is started on the minion and the corresponding service port is monitored, and when an external request occurs, the proxy distributes the request to the back-end proper container processing according to the load balancer.