Shulou(Shulou.com)05/31 Report--

How to analyze the Pod synchronization process in kubelet, I believe that many inexperienced people are at a loss about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

1. Core process

The core function of kubelet is to create and manage pod on nodes according to the instructions of master. Currently, for kubelet, there are three ways to get a list of managed pod:

File-specify the configuration directory through the startup parameter-config and check for changes periodically.

HTTP Endpoint-specified by the-- manifest-url parameter to check for updates periodically.

API Server-listens to the etcd directory through API Server and synchronizes the pod list in real time.

Listening to the Pod list through API Server and maintaining the corresponding Pod instance on the node is the core main process of the entire kubelet process. The following figure approximately describes this process:

Note: in the actual research process, it is found that the calling logic of the system implemented in go is very different from that implemented in Java/C++. In addition to the mutual method calls between objects in go language, there are also a large number of cases in which goroutine send message calls through channel. Therefore, logically, calls to the go language are actually concurrent, similar to mesh. Instead of the traditional synchronous call, linear relationship. Therefore, it is difficult to use UML diagrams to represent the order of calls between objects. The above figure just shows the key object and method entry, and there are a lot of omissions. If there is any mistake or better expression, please let the author know.

two。 Core structure and invocation relationship 2.1 Kubelet

The Kubelet structure in the / pkg/kubelet/kubelet.go file is the core data structure of the entire kubelet process, holding all associated entity objects. There are two main entry methods for Kubelet:

NewMainKubelet-create and initialize a Kubelet structure (initialize all associated instances).

Run-start all secondary goroutines and the main process mentioned above.

In the NewMainKubelet method, a private method of makePodSourceConfig is called, which returns a pointer to the PodConfig object. One of the field is called updates chan kubetypes.PodUpdate, which is used to pass pod update messages.

On one side of the updates channel is the goroutines that obtains pod update information from three sources. On the other hand, it is consumed by the main process of kubelet, that is, the pod update information is obtained and the Pod instance is operated synchronously.

The main process method entry of kubelet is Kubelet.syncLoopIteration, which is used to continuously distribute messages in the updates channel.

2.2 PodWorkers

The podWorkers structure in the / pkg/kubelet/pod_workers.go file is a pool of protocols. PodWorkders will set up a separate goroutine for each pod to consume the update information related to the pod and implement the pod operation.

There are two key approaches to podWorkers:

The UpdatePod-update entry, which starts and manages the update protocol for each pod.

The actual logic of managePodLoop-worker, which ends up calling the Kubelet.syncPod method.

After each Pod synchronization of managePodLoop, the wrapUp method is called. This method is used to periodically synchronize the pod even if no changes are received from the API Server push.

The wrapUp method will push the timestamp of the next synchronization in the workQueue of podWorkers. At the same time, the kubelet.syncLoopIteration method periodically pulls the pod list that needs to be synchronized at the current time from podWorkers.workQueue, and triggers the SyncPod operation.

2.3 kubeGenericRuntimeManager

1. It is described in the key module documentation of Kubelet, which implements the kubecontainer.Runtime interface and encapsulates the operations related to Container & Image.

The SyncPod method of the structure is called in the main process, which calculates the actions that need to be performed on the Pod and is performed through the CRI interface.

2.4 dockerService & kubeDockerClient

In the implementation of CRI interface in dockershim, kubeGenericRuntimeManager and dockerService actually communicate through gRPC.

KubeDockerClient is the encapsulation of libdocker.Interface interface and communicates with docker daemon through HTTP (s).

After reading the above, have you mastered how to analyze the Pod synchronization process in kubelet? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.