K8s-kubelet(Overview)
K8s-kubelet(Overview)
基于1.25
kubelet是K8s中最重要的节点代理程序，运行在集群的每个节点上。
- 能够自动将节点注册到集群
- 将节点上、Pod运行状态和资源使用情况周期性上报到控制平面
- 同时接受控制平面发送到工作任务、启动停止容器、维护管理Pod
- 也包含对cAdvusor资源用量监控、容器和镜像垃圾回收
kubelet架构设计
kubelet整体架构采用了基于事件的处理模型，通过syncLoop和不断调谐Podtatus和PodSpec差距
PodSpec主要来源自三个来源，kube-apiserver、file和HTTP。
- file和HTTP主要用于发现Static类型的Pod
- kubelet默认每隔20s执行一次检测
PodStatus实际状态主要是通过PLEG周期性扫描冗余运行时的运行状态获取。
PLEG每隔1s，从容器运行时获取Pod和Container信息，并于本地缓存进行对比，发生变更的时候，生成PLEG事件，并且发送给事件订阅者触发执行事件处理程序。
- 默认，当产生PLEG事件，kubelet会执行sync调谐
- kubelet提供了HTTPServer，端口10250，支持metrics指标采集、监控检查、接受来自kube-apiserver的Debug请求
- 比如，执行kubectl logs，kubectl 发送给kube-apiserver，kube-apiserver完成合法性校验，会向Pod所在的kubelet的日志服务端点/containerLogs发起请求，有kubelet读取容器日志，返回给kube-apiserver
管理器功能列表
| 名称 | 功能描述 |
|---|---|
| cAdvisor | 采集当前节点的容器、机器资源、内核和运行版本、文件系统等监控信息 |
| CertificateManager | 自动向kube-apiserver申请节点颁发kubelet-client证书，并在在证书过期前更新本地证书 |
| CgroupManger | 维护和管理Pod、Container的Cgroup层级结构，基层基于libcontainer的cgroups实现 |
| CloudResourcesSyncManager | 从云厂商同节点状态，如更新NodeAddress地址信息 |
| ConfigMapManager | kubelet读取ConfigMap对象的接口，支持3种检测变更方法，分别如下1. Watch：使用Informer List-Watch机制监听ConfigMap变化，及时更新超过生存时间的ConfigMap自动失效，被重新加载2.Cache：使用固定的TTL超过时间，超过生存时间ConfigMap自动失效3. Get：不使用缓存，直接从kube-apiserver读取最新的ConfigMap对象 |
| ContainerGC | 容器垃圾回收，清理已经消亡的Container，可以通过GCPolicy控制垃圾回收策略 |
| ContainerLogManager | 容器日志管理Rotate滚动，每隔10s检查并执行一次日志Rotate操作，可以通过LogRotatePolicy控制器控制Rotate策略（如最大日志文件大小，最大日志文件数量） |
| ContainerManager | 主要负责节点上运行的容器的cgroup配置，通过调用Cgroup配置cgroup。如果指定了kubelet的–cgroups-per-qos启动参数为true（默认true），则kubelet会建立cgroup层级结构，确保不同的QOS Pod资源隔离，目前支持3种QOS等级，分别Guaranceed、BestEffort、Burstable |
| CPUManager | 维护和管理CPU资源分配，目前支持俩种cpuset管理策略，分别是none（默认策略）、static。定期通过CRI写入资源更新，以保证PodCPU分配和cgroup设置一致 |
| DeviceManager | 启动gRPC监听kubelet.sock，device plugin通过连接gRPC注册device信息，kubelet通过List-Watch机制监听deice更新，维护节点可分配和cgroup设置一样 |
| EvictionManager | 当节点的内存、磁盘、PID等资源不足，达到了配置了驱逐阈值的时候，驱逐管理器会按照Pod QOS等级，按顺序驱逐低优先级的Pod，以保证节点的稳定性。可以通过–eviction-hard参数配置驱逐阈值。 |
| ImageGCManager | 维护本地镜像列表，当镜像磁盘使用率达到了配置的上限阈值，清理节点上不使用的镜像，直到镜像磁盘使用率下降到配置的下限阈值，可以通过ImageGCPolciy设置镜像回收策略 |
| kubeGenericRuntimeManger | Runtime接口的默认实现，封装了对Pod和Container常见操作，管理Pod和Container的生命周期，底层通过CRI调用Remote ContainerRuntime实现对容器运行时的操作 |
| MemoryManager | 维护和管理Memory资源分配，支持俩种管理策略分别是none（默认策略）、static。当启用MemoryManager featuregate，默认启用 |
| NodeLeaseController | 周期性声明和刷新节点的Lease对象，维持节点活跃状态 |
| NodeShutdownManager | 监听节点关机时间，在关机前，执行优雅关闭逻辑 |
| OOMWatcher | 监听操作系统OOM事件，并且记录为节点的Event |
| PluginManager | 插件管理器，主要用于处理插件的验证、注册、反注册，目前支持Device和CSI。通过监听特定目录（/var/lib/kubelet/plugins_registry)下拓展名为 .sock的文件的创建发现插件，并且通过gRPC发起连接获取插件信息，完成对插件的管理。当拓展名.sock被移除，执行反注册 |
| PodManager | 提供存储和访问Pod信息的接口，封装关于Pod操作的接口，维持StaticPod和Mirror Pod的映射关系 |
| ProbeManager | 负责执行容器监控探测，目前支持三种探针，readiness、liveness、statup |
| QOSContainerManager | 负责维护Pod的QOS等级，通过调用CgroupManager完成cgroup设置 |
| RuntimeClassManager | 监听和缓存RuntimeClass信息，提供kubelet启动容器时使用，Pod可通过设置RuntimeClassName字段指定容器运行时使用的特定Runtime如（runc）启动容器 |
| SecretManager | kubelet读取secret对象接口，目前支持三种变更检测1.Watch：使用Informer监听Secret 2.Cache：使用固定的TTL超时时间，超过生存时间的Secret自动失效，被重新加载 3.Get：不使用缓存，直接从kube-apiserver读取最新的Secret |
| StatusManager | 维护和存储最新的Pod Status信息，并将Pod Status信息不断同步回kube-apiserver |
| TokenManager | 维护Service Account Token缓存，负责申请Token，并清理已经失效的Token |
| TopologyManager | 负责维护CPU和硬件涉笔的拓扑状态，以支持在进行资源分配的时候进行硬件级的亲和条有哦，提升性能。支持4种分配策略，分别为Node（默认）、best-errfort、retricted、single-numa-node |
| VolumeManager | 管理存储卷attach、mount、unmount、detach操作，底层通过调用CSI实现 |
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Joohwan！
alipay
相关推荐
2026-03-22
K8s-Pod在节点落地流程
Pod 在节点落地通信流程目标这篇文档只回答一个核心问题：kubelet 如何把“期望运行”的 Pod 变成“真实运行”的容器？ 重点放在 kubelet 内部各组件之间的协作与 CRI 通信边界，而不是每一个 gRPC 字段的含义。 一句话摘要kubelet 收到 Pod 更新后，把期望态交给 podWorkers；podWorkers 驱动单 Pod 生命周期状态机，再由 kubeGenericRuntimeManager 通过 CRI 调用容器运行时完成 sandbox、镜像与容器操作。 1. 流程总览从通信视角看，这条链路可以拆成 3 个阶段： 更新接入阶段：kubelet 从 Pod source 收到属于本节点的 Pod 更新，并交给内部子系统。 状态机驱动阶段：podWorkers 根据当前状态决定执行同步、终止还是清理。 运行时执行阶段：runtime manager 通过 CRI 把操作翻译给容器运行时，完成 sandbox 和容器的创建/销毁。 Mermaid：总览图flowchart LR A[Pod update from sour...
2026-03-22
K8s-节点心跳与健康流程
节点心跳与健康状态通信流程目标这篇文档只回答一个核心问题：kubelet 如何把节点健康信号汇报给控制面，控制面又如何据此做出判断和后续动作？ 重点放在两类心跳信号的协作关系，以及控制面如何综合判断节点健康。 一句话摘要kubelet 周期性更新 NodeStatus 并续约 Lease；node lifecycle controller 通过 informer/lister 观察 Node 与 Lease，综合判断节点健康，再触发 taint、Pod not-ready 传播与后续驱逐流程。 1. 流程总览从通信视角看，这条链路包含两类并行的心跳信号： NodeStatus 心跳：携带节点条件（Ready、MemoryPressure 等）和容量信息。 Lease 心跳：轻量级的存活信号，用于快速检测节点失联。 控制面会综合这两类信号来判断节点健康状态。 Mermaid：总览图flowchart LR A[Kubelet] --> B[syncNodeStatus] A --> C[nodeLeaseController] B...
2026-03-22
K8s-kubelet深度剖析
Kubelet 深度分析本文档深入分析 Kubernetes Kubelet 组件的架构设计、启动流程、核心功能和关键子系统。 目录 架构概览 关键数据结构 启动流程分析 核心功能原理 关键子系统详解 5.1 PodManager 5.2 StatusManager 5.3 ProbeManager 5.4 VolumeManager 5.5 EvictionManager 5.6 PLEG 边界情况与错误处理 性能优化 最佳实践 1. 架构概览1.1 Kubelet 在 Kubernetes 架构中的位置Kubelet 是 Kubernetes 集群中运行在每个节点上的核心代理（Node Agent），是 Kubernetes 控制平面与节点级容器运行时之间的桥梁。它负责维护节点上容器的生命周期，并将节点状态上报给 API Server。 在 Kubernetes 整体架构中，Kubelet 处于如下位置： 12345678910111213141516171819202122+-------------------------+ +----------...
2026-03-22
K8s-kubelet状态与事件反馈流程
Kubelet 状态与事件回传流程目标这篇文档只回答一个核心问题：kubelet 如何把节点侧观察到的 Pod 运行结果回传给控制面？ 重点放在状态回传与事件上报两条通信链路的区别，以及控制器真正依赖的观察面是什么。 一句话摘要kubelet 通过 statusManager 异步批量把 PodStatus 同步到 API Server，并通过事件记录器上报诊断性 Event；控制器主要观察的是 API Server 中资源对象的状态变化，而不是 kubelet 内部事件流本身。 1. 流程总览从通信视角看，这条链路包含两条并行但职责不同的子链路： 状态回传链路：kubelet 把 Pod 运行状态写回 API Server，成为控制面的共享事实。 事件上报链路：kubelet 把诊断性 Event 写入 API Server，用于排障与审计。 这两条链路共享 API Server 作为存储，但消费方和语义完全不同。 Mermaid：总览图flowchart LR A[Kubelet subsystems] --> B[statusManager] A...
2026-03-22
K8s-kubelet认证授权流程
Kubelet 认证授权通信流程目标这篇文档只回答一个核心问题：kubelet 如何验证和授权对 kubelet API 的访问请求？ 重点放在 kubelet 的认证模块、授权模块以及与 API Server 的交互流程。 一句话摘要kubelet 通过 webhook 认证和授权，将客户端请求转发给 API Server 进行验证，支持匿名访问、证书认证和 bootstrap token 认证等多种方式。 1. 流程总览从通信视角看，这条链路包含三个层次： **认证层 (Authentication)**：验证客户端身份。 **授权层 (Authorization)**：验证客户端是否有权限执行操作。 **准入层 (Admission)**：对请求进行额外检查和修改（仅部分操作）。 架构总览图flowchart TB subgraph 客户端["请求来源"] direction LR API[kube-apiserver<br/>proxy/attach/exec] KUBECTL[...
2026-03-22
Kubelet 资源驱逐 (Eviction) 通信流程
Kubelet 资源驱逐 (Eviction) 通信流程目标这篇文档只回答一个核心问题：kubelet 如何在节点资源不足时决定并执行 Pod 驱逐？ 重点放在 EvictionManager 的监控机制、驱逐决策逻辑以及驱逐执行流程。 一句话摘要kubelet 的 EvictionManager 定期监控节点资源使用，当资源超过阈值时，根据 QoS 和优先级选择 Pod 进行驱逐，以保护节点稳定性。 1. 流程总览从通信视角看，这条链路可以拆成 3 个阶段： 资源监控阶段：EvictionManager 定期采集节点资源使用情况。 决策判断阶段：根据阈值和策略决定是否需要驱逐以及驱逐哪些 Pod。 执行驱逐阶段：通过 API Server 删除选中的 Pod。 架构总览图flowchart TB subgraph 资源采集["资源采集层"] direction TB CAD[cAdvisor<br/>容器资源监控] SYS[系统信息<br/>节点资源] SI...
评论
