Kubernetes General Architecture Diagram

This article CSDN blog address: http://blog.csdn.net/huwh_/article/details/71308171

First, the kubernetes of the general structure of the two, kubernetes each component introduction (a) kube-master[control node]

• Workflow Flowchart for Master

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/node 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/node nodes.

1. API server[resource Operation Portal]

1. Provides a unique operation entry for a resource object, all other components must manipulate the resource data through the APIs it provides, only API server communicates with the storage, and other modules access the cluster state through the API server.

   1. The first is to ensure the security of the cluster state access.

   2. The second is to isolate how the cluster state accesses and how the backend storage is implemented: API server is a way of state access and will not be changed by the etcd of back-end storage technology.

2. As the entrance of the kubernetes system, it encapsulates the additions and deletions of core objects, which are provided to external customers and internal component calls in a restful interface. The relevant resource data "full-volume query" + "Change monitoring" to complete the relevant business functions in real time.

For more information on API server, please refer to: kubernetes core principle (i) API Server2, controller manager[Internal Management control center]

1. Realize cluster fault detection and recovery automation, responsible for the implementation of a variety of controllers, mainly:

   • Endpoint-controller: Periodically correlate the service and POD (the association information is maintained by the endpoint object), ensuring that service-to-pod mappings are always up-to-date.

   • Replication-controller: Periodically correlate replicationcontroller and pods to ensure that the number of copies Replicationcontroller defined is always the same as the number of pods actually running.

For more information on Controller manager, refer to: Kubernetes core principle (ii) Controller MANAGER3, scheduler[cluster Dispatch Scheduler]

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

2. Real-time monitoring of all running pods that are not distributed and distributed in the Kubernetes cluster.

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.

For more scheduler information, please refer to: Kubernetes core principle (iii) Scheduler (ii) kube-node[service node]

• Kubelet structure diagram

1. Pod steward on kubelet[node]

1. Responsible for all lifecycle management of pod creation, modification, monitoring and deletion on node nodes.

2. Periodically escalate the status information of this node to API Server.

3. Kubelet is the bridge between Master API server and Minion, which receives the commands and work assigned to it by the Master API server, interacting with the persistent key-value store Etcd, file, server, and HTTP. Read configuration information.

4. The specific work is as follows:

   1. Sets the container's environment variable, binds the container to the volume, binds the container to port, runs a single container from the specified pod, and creates a network container for the specified pod.

   2. Sync pod status, sync pod status, get container info from cadvisor, pod info, root info, machine info.

   3. Run the command in the container, kill the container, and delete all the containers for the pod.

2, proxy[load Balancing, routing and forwarding]

1. Proxy is designed to address the external network's ability to access application services provided across the container in a machine cluster, running on each node. 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.

2. Proxy not only solves the same host service port conflict problem, also provides service forwarding service port to provide services, the proxy backend using a random, round-robin load balancing algorithm.

3. Kubectl (Kubelet client) [Cluster Management command line toolset]

1. Through the KUBECTL command set operation of the client, the API server responds to the corresponding command result, thus achieving the management of the Kubernetes cluster.

Reference article:

Https://yq.aliyun.com/articles/47308?spm=5176.100240.searchblog.19.jF7FFa

Kubernetes General Architecture Diagram