Kubelet

247

The kubelet is the primary “node agent” that runs on each node.

The kubelet monitors resources like CPU, memory, disk space, and filesystem inodes on your cluster’s nodes. When one or more of these resources reach specific consumption levels, the kubelet can proactively fail one or more pods on the node to reclaim resources and prevent starvation.

Stuff you wanna know:

Kubelets can register the node with the apiserver. It does so, using one of — the hostname; a flag to override the hostname; or specific logic for a cloud provider.
The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy.
The kubelet can also listen for HTTP and respond to a simple API to submit a new manifest.
A kubelet’s HTTPS endpoint exposes APIs which give access to data of varying sensitivity, and allow you to perform operations with varying levels of power on the node and within containers.
The kubelet uses certificates for authenticating to the Kubernetes API.
The kubelet doesn’t manage containers which were not created by Kubernetes.
Since the kubelet is a daemon, it needs to be maintained by some kind of an init system or service manager.
Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while other configuration aspects need to be set on a per-kubelet basis to accommodate the different characteristics of a given machine (such as OS, storage, and networking).
The lifecycle of the kubeadm CLI tool is decoupled from the kubelet. (The kubeadm CLI tool is executed by the user when Kubernetes is initialized or upgraded, whereas the kubelet is always running in the background.)
When the kubelet is installed using DEBs or RPMs, systemd is configured to manage the kubelet. (You can use a different service manager instead, but you need to configure it manually.)

Stuff you wanna know:

Ref: