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

This article shares with you the content of a sample analysis of how kubelet works in kubernetes. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

One: brief introduction

In a Kubernetes cluster, a Kubelet service is started on each Node node. This process is used to handle the tasks sent to this node by the Master node, and to manage the containers in Pod and Pod. Each Kubelet process registers the node's own information on the API SERVER, periodically reports the use of node resources to the Master node, and monitors the container and node resources through cAdvise.

Second: node management

The node decides whether to register itself with kubelet by setting the startup parameter "- register-node" of API Server, which defaults to true. You can view this parameter through kubelet-help.

Kubelet registers node information through API Server at startup, and regularly sends new node information to API Server. After receiving these messages, API Server writes these messages to etcd. Through the kubelet startup parameter "--node-status-update-frequency" setting how often the node status is reported to API Server, the default is 10s.

Kubelet configuration parameters

# # kubelet (minion) config

#

# # The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)

KUBELET_ADDRESS= "--address=10.116.82.28"

#

# # The port for the info server to serve on

# KUBELET_PORT= "--port=10250"

#

# # You may leave this blank to use the actual hostname

KUBELET_HOSTNAME= "--hostname-override=10.116.82.28"

#

# # location of the api-server

# KUBELET_API_SERVER= "--api-servers= http://10.116.137.196:8080"

#

# # pod infrastructure container

# KUBELET_POD_INFRA_CONTAINER= "--pod-infra-container-image=sz-pg-oam-docker-hub-001.tendcloud.com/library/pod-infrastructure:rhel7"

KUBELET_POD_INFRA_CONTAINER= "--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure"

#

# # Add your own!

KUBELET_ARGS= "--cgroup-driver=systemd-- cluster-dns=10.254.0.2-- experimental-bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig-- kubeconfig=/etc/kubernetes/kubelet.kubeconfig-- require-kubeconfig-- cert-dir=/etc/kubernetes/ssl-- cluster-domain=cluster.local. Hairpin-mode promiscuous-bridge-- serialize-image-pulls=false-- runtime-cgroups=/systemd/system.slice-- kubelet-cgroups=/systemd/system.slice"

Three: Pod management

1.kubelet listens to the "/ registry/nodes/$ current node name" and "/ registry/pods" directories in the way API Server Client uses Watch+List to synchronize the acquired information to the local cache.

2.kubelet listens to etcd, and all operations against Pod will be heard by kubelet. If you find a new Pod bound to this node, create the Pod. Exe as required by the Pod list.

When kubelet reads the monitored information, it does the following:

a. Create a data directory for the Pod

b. Read the Pod list from API Server

c. Mount external volumes for this Pod

d. Download the Secret used by Pod

e. Create a pause container

f. Create an application container

Four: container health check

The health status of Pod can be checked by two types of probes: LivenessProbe and ReadinessProbe.

1.LivenessProbe probe: used to determine whether the container is alive. If the LivenessProbe probe detects that the container is unhealthy, kubelet will kill the container and handle it accordingly according to the container's restart policy. If a container does not contain a LivenessProbe probe, kubelet thinks that the LivenessProbe probe return value of the container is always "Success".

2.ReadinessProbe probe: used to determine whether the container has been started and can receive requests. If the ReadinessProbe probe detects a failure, the state of the Pod will be modified. Endpoint Controller removes Endpoint. Endpoint Controller from Service's Endpoint, including the Pod where the container is located.

Fifth: cAdvisor resource monitoring

In a Kubernetes cluster, application execution can be monitored at different levels, including container, Pod,Service, and the entire cluster.

The 1.Heapster project provides a basic monitoring platform for Kubernetes, which is cluster-level monitoring.

2.cAdvisor is an open source proxy tool for analyzing container resource usage and performance characteristics. CAdvisor is integrated into Kubernetes code, and cAdvisor automatically finds all containers on its nodes and automatically collects statistics on CPU, memory, file system and network usage. CAdvisor collects and analyzes the overall use of the node through the Root container of the node machine where it is located.

Thank you for reading! This is the end of the article on "sample Analysis of the operating Mechanism of kubelet in kubernetes". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.