Kubelet: Difference between revisions
| (26 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
=Overview= | =Overview= | ||
Each node runs an agent called kubelet, which is responsible with the node's registration with the cluster. Once a node is registered, its CPU, RAM and storage are pooled into the wider cluster pools of corresponding resources. | Each node runs an agent called kubelet, which is responsible with the node's registration with the cluster. Once a node is registered, its CPU, RAM and storage are pooled into the wider cluster pools of corresponding resources. The kubelet is part of the [[Kubernetes_Control_Plane_and_Data_Plane_Concepts#Control_Plane|control plane]] and acts as a bridge between the Kubernetes [[Kubernetes_Control_Plane_and_Data_Plane_Concepts#Master_Node|master]] and the [[Kubernetes_Control_Plane_and_Data_Plane_Concepts#Worker_Node|node]], managing the pods and containers running on the machine it is installed on. The kubelet is watching the API server for work (pod) assignments and attempts to run them. If it is not successful for any reason, it reports the condition back to the API server. The task of actually running the pods is delegated to the local [[Kubernetes_Container_Runtime_Concepts#Container_Runtime|container runtime]]. The kubelet maintains a [[#Cache|cache]], and takes part in [[#Metrics_Collection|resource metrics collection]]. The kubelet has a HTTPS endpoint that exposes APIs which give access to metrics and other data, and also allow perform operations on the node and within containers. The kubelet is also in charge with managing the [[Kubernetes_Pod_and_Container_Concepts#Static_Pods|static pods]] deployed in its node. | ||
=<span id='Container_State'></span><span id='Container_Creation_and_State_Monitoring'></span>Container Creation, State Monitoring and Restart= | |||
The kubelet acts as a bridge between the Kubernetes master and the | Once the scheduler assigns a [[Kubernetes_Pod_and_Container_Concepts#Pod|pod]] to a node, the kubelet starts creating [[Kubernetes_Pod_and_Container_Concepts#Container|containers]] for the pod, using the node's container runtime. The kubelet then tracks pods' containers [[Kubernetes_Pod_and_Container_Concepts#Container_States|states]] and may [[Kubernetes_Pod_and_Container_Concepts#Container_Restart_Policy|restart]] failed containers, depending on the pod configuration. | ||
=Container Probe Execution= | |||
The kubelet is watching the API server for work (pod) assignments and attempts to run them. If it is not successful for any reason, it reports the condition back to the API server. The task of actually running the pods is delegated to the local [[ | The kubelet executes [[Kubernetes_Container_Probes#Overview|container probes]]. | ||
The kubelet maintains a [[#Cache|cache]], | |||
=Cache= | =Cache= | ||
The kubelet has a cache it uses to serve various values to the node. For example, the [[Kubernetes_Cluster_Configuration_Concepts#Secrets_Projected_as_Files|secrets projected as files]] in pods running on the node are | The kubelet has a cache it uses to serve various values to the node. For example, the [[Kubernetes_Cluster_Configuration_Concepts#Secrets_Projected_as_Files|secrets projected as files]] in pods running on the node are served from this cache. The cache characteristics are configurable. The cached values can be propagated via watch (default), ttl-based or simply redirecting all requests to the API server. | ||
=Image Pulling= | =Image Pulling= | ||
The kubelet performs [[Kubernetes_Container_Image_Pull_Concepts#Overview|image pulling]] on behalf of the pods scheduled on the node. | The kubelet performs [[Kubernetes_Container_Image_Pull_Concepts#Overview|image pulling]] on behalf of the pods scheduled on the node. <font color=darkgray>Verify this, the container runtime says [[Kubernetes_Container_Runtime_Concepts#Container_Runtime|it does image pulling]].</font> | ||
=Metrics Collection= | =Metrics Collection= | ||
The kubelet | The kubelet keeps track of constituent containers for each pod and fetches individual container usage statistics from the container runtime through the [[Kubernetes_Container_Runtime_Concepts#Container_Runtime_Interface_.28CRI.29|Container Runtime Interface]]. The kubelet also fetches this information from the integrated <span id='cAdvisor'></span>cAdvisor for the legacy Docker integration. cAdvisor runs in the host network namespace. Finally, the kubelet gathers node-level metrics. It then exposes the aggregated pod resource usage statistics to the [[Kubernetes Metrics Server#Overview|metrics server]], which in turn exposes these statistics via the [[Metrics_in_Kubernetes#Resource_Metrics_API|Resource Metrics API]]. The API is served at <code>/metrics/resource/v1beta1</code> on the kubelet's authenticated and read-only ports. kubelet also exposes metrics in <code>/metrics/cadvisor</code> and <code>/metrics/probes</code>. | ||
=Authentication/Authorization= | =Authentication/Authorization= | ||
| Line 27: | Line 26: | ||
=API Access= | =API Access= | ||
{{External|https://www.deepnetwork.com/blog/kubernetes/2020/01/13/kubelet-api.html}} | {{External|https://www.deepnetwork.com/blog/kubernetes/2020/01/13/kubelet-api.html}} | ||
Port: 10250 | |||
<syntaxhighlight lang='bash'> | <syntaxhighlight lang='bash'> | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Latest revision as of 00:29, 16 November 2021
External
Internal
Overview
Each node runs an agent called kubelet, which is responsible with the node's registration with the cluster. Once a node is registered, its CPU, RAM and storage are pooled into the wider cluster pools of corresponding resources. The kubelet is part of the control plane and acts as a bridge between the Kubernetes master and the node, managing the pods and containers running on the machine it is installed on. The kubelet is watching the API server for work (pod) assignments and attempts to run them. If it is not successful for any reason, it reports the condition back to the API server. The task of actually running the pods is delegated to the local container runtime. The kubelet maintains a cache, and takes part in resource metrics collection. The kubelet has a HTTPS endpoint that exposes APIs which give access to metrics and other data, and also allow perform operations on the node and within containers. The kubelet is also in charge with managing the static pods deployed in its node.
Container Creation, State Monitoring and Restart
Once the scheduler assigns a pod to a node, the kubelet starts creating containers for the pod, using the node's container runtime. The kubelet then tracks pods' containers states and may restart failed containers, depending on the pod configuration.
Container Probe Execution
The kubelet executes container probes.
Cache
The kubelet has a cache it uses to serve various values to the node. For example, the secrets projected as files in pods running on the node are served from this cache. The cache characteristics are configurable. The cached values can be propagated via watch (default), ttl-based or simply redirecting all requests to the API server.
Image Pulling
The kubelet performs image pulling on behalf of the pods scheduled on the node. Verify this, the container runtime says it does image pulling.
Metrics Collection
The kubelet keeps track of constituent containers for each pod and fetches individual container usage statistics from the container runtime through the Container Runtime Interface. The kubelet also fetches this information from the integrated cAdvisor for the legacy Docker integration. cAdvisor runs in the host network namespace. Finally, the kubelet gathers node-level metrics. It then exposes the aggregated pod resource usage statistics to the metrics server, which in turn exposes these statistics via the Resource Metrics API. The API is served at /metrics/resource/v1beta1 on the kubelet's authenticated and read-only ports. kubelet also exposes metrics in /metrics/cadvisor and /metrics/probes.
Authentication/Authorization
API Access
Port: 10250