kubelet is the main "node agent" running on each node, Each node will start the kubelet process to process the tasks sent by the Master node to the node, and manage the Pod and its containers according to the PodSpec description (PodSpec is a YAML or JSON object used to describe a pod).

kubelet obtains a set of PodSpecs through various mechanisms (mainly through apiserver) and ensures the healthy operation of the containers described in these PodSpecs.

Second, the main functions of kubelet

1, kubelet default Monitor four ports, namely 10250, 10255, 10248, 4194

LISTEN 0 128 *:10250 *:*  users:(("kubelet",pid=48500,fd=28)) LISTEN 0 128 *:10255 *:* users:(("kubelet",pid=48500,fd= 26)) LISTEN 0 128 *:4194 *:* users:(("kubelet" ,pid=48500,fd=13)) LISTEN 0 128 127.0.0.1:< span class="hljs-number">10248 *:* users:(("kubelet" ,pid=48500,fd=23))   span> 

• 10250 (Kubelet API): The port for communication between kubelet server and apiserver. The apiserver is periodically requested to obtain the tasks that it should handle. Through this port, node resources and status can be accessed.

• 10248 (health check port): By accessing this port, you can determine whether the kubelet is working properly, and through the kubelet startup parameter --healthz-port and --healthz-bind-address to specify the listening address and port.

$ curl http://127.0.0.1 :10248/healthz ok 

• 4194 (cAdvisor monitoring): kublet can obtain the environment information of the node and the status of the container running on the node through this port , Visit http://localhost:4194 to see the management interface of cAdvisor, and you can specify the start port through the kubelet startup parameter --cadvisor-port.

$ curl http://127.0.0.1:4194/metrics 

• 10255 (readonly API): provides pod and node information, the interface is exposed in read-only form, and access to this port does not require authentication and authorization.

// Get the pod interface, and apiserver’s // http ://127.0.0.1:8080/api/v1/pods?fieldSelector=spec.nodeName= The interface is similar to $ curl http://127.0.0.1:10255/pods // Node information interface, providing disk, network, CPU, memory and other information $ curl http://127.0.0.1:10255/spec/  

2. The main functions of kubelet:

• Pod management: kubelet monitors regularly The data source obtains the desired state of the pod/container on the node (what container is running, the number of running copies, how the network or storage is configured, etc.), and calls the corresponding container platform interface to reach this state.

• Container health check: After the kubelet creates the container, it is necessary to check whether the container is running normally. If the container runs incorrectly, it must be handled according to the restart strategy set by the pod.

• Container monitoring: kubelet will monitor the resource usage of the node where it is located, and report to the master regularly. Resource usage data is obtained through cAdvisor. Knowing the resource conditions of all nodes in the entire cluster is essential for pod scheduling and normal operation.

3. Modules in the kubelet component

modules in the kubelet component

The above figure shows the modules in the kubelet component and the division between modules.

• 1. PLEG (Pod Lifecycle Event Generator)
  PLEG is the core module of kubelet. PLEG will always call the container runtime to obtain the information of the containers/sandboxes of this node and communicate with itself The maintained pods cache information is compared, the corresponding PodLifecycleEvent is generated, and then output to the eventChannel, sent to the kubelet syncLoop through the eventChannel for consumption, and then the kubelet syncPod triggers the pod synchronization process, and finally reaches the user's desired state.

• 2, cAdvisor
  cAdvisor (https://github.com/google/cadvisor) is a container monitoring tool developed by Google, integrated in kubelet, to collect For the monitoring information of this node and container, most companies obtain the monitoring data of the container from cAdvisor. The cAvisor module provides an interface interface, which is also used by imageManager, OOMWatcher, containerManager, etc.

• 3. OOMWatcher
  The OOM monitor of the system will establish SystemOOM with the cadvisor module, and receive the OOM signal from the cadvisor through the Watch method, and generate related event.

• 4, probeManager
  probeManager relies on statusManager, livenessManager, containerRefManager, and will regularly monitor the health of the container in the pod. Currently, two types of probes are supported: livenessProbe And readinessProbe.
  livenessProbe: Used to determine whether the container is alive. If the detection fails, kubelet will kill the container and deal with it according to the container's restart strategy.
  readinessProbe: Used to determine whether the container is started, add the successfully probed container to the endpoints of the service where the pod is located, and remove it otherwise. There are three ways to implement readinessProbe and livenessProbe: http, tcp, and cmd.

• 5, statusManager
  statusManager is responsible for maintaining status information and updating pod status to apiserver, but it is not responsible for monitoring changes in pod status, but provides corresponding The interface is called by other components, such as probeManager.

• 6. ContainerRefManager
  Management of container references, a relatively simple Manager, used to report container creation, failure and other events. The containerID and v1 are realized by defining the map. .ObjectReferece The mapping of container references.

• 7, evictionManager
  When the node's memory, disk, or inode resources are insufficient, the configured evict strategy is reached, and the node will become a pressure state. At this time, kubelet The pod will be driven out in the order of qosClass to ensure the stability of the node. The evict strategy value can be determined by configuring the kubelet startup parameter --eviction-hard=.

• 8, imageGC
  imageGC is responsible for the image recovery of the node node. When the local disk space storing the image reaches a certain threshold, it will trigger the image recovery and delete Remove the image that is not used by the pod, and the threshold for reclaiming the image can be set by the kubelet startup parameter --image-gc-high-threshold and --image-gc-low-threshold to set.

• 9, containerGC
  containerGC is responsible for cleaning up the dead containers on the node. The specific GC operations are implemented by the runtime.

• 10. imageManager
  Call the PullImage/GetImageRef/ListImages/RemoveImage/ImageStates method provided by kubecontainer to ensure the image required for pod operation.

• 11, volumeManager
  Responsible for the management of the volume used by the pod on the node, the volume is associated with the life cycle of the pod, and is responsible for the mount/umount of the volume during the pod creation and deletion process In the /attach/detach process, kubernetes adopts volume plugins to implement storage volume mounting and other operations, with dozens of built-in storage plugins.

• 12. ContainerManager
  Responsible for the cgroup configuration information of the container running on the node. If the kubelet startup parameter is specified --cgroups-per-qos When, kubelet will start the goroutine to periodically update the cgroup information of the pod to maintain its correctness. This parameter defaults to true, which implements the three levels of Qos of Guaranteed/BestEffort/Burstable of the pod. .

• 13. RuntimeManager
  containerRuntime is responsible for docking kubelet with different runtime implementations, and realizes the operation of the underlying container. The runtime instance obtained after initialization will be described previously Components used. You can use the kubelet startup parameter --container-runtime to define whether to use docker or rkt. The default is docker.

• 14, podManager
  podManager provides an interface to store and access pod information, maintain the relationship between static pod and mirror pods, podManager will be controlled by statusManager/volumeManager/runtimeManager Call, the secretManager and configMapManager are called in the podManager's interface processing flow.

certificateManager
cgroupManager
containerManager
cpuManager
nodeContainerManager
configmapManager
containerReferenceManager
evictionManager
nvidiaGpuManager
imageGCManager
kuberuntimeManager
hostportManager
podManager
proberManager
secretManager
statusManager
volumeManager
tokenManager