在前面的系列文章中，我们从微服务聊到Pod，了解到Pod除了业务容器外，还有负责初始化的Init容器以及与Pod生命周期强绑定的Pause容器。我们也提到Pod是Kubernetes最小的调度单位，但你是否想过，Kubernetes究竟是如何部署Pod、配置Pod并获知其运行状态的呢？
本篇将聚焦于这三个核心问题，带您深入Kubernetes节点的内部世界。我们将探讨节点中的DaemonSet（如kube-proxy、网络与存储插件）如何与Container Runtime等组件协同工作，最终实现Pod的调度与管理。本文将从以下几个方面展开：
- Kubernetes节点与DaemonSet是什么？
- kubelet如何通过CRI、CNI、CSI三大标准接口进行Pod管理？
- 基于CRI的容器生命周期监控与健康检查机制。
- DaemonSet在节点管理中的核心作用。
一、Kubernetes节点与DaemonSet：基础设施的基石
1. 什么是Kubernetes节点？
Kubernetes节点是集群的工作单元，可以是物理机或虚拟机。每个节点都包含了运行Pod所需的一系列核心组件，是承载容器化应用的实体。
# 查看节点信息
$ kubectl describe node <node-name>
Name: node-1
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=node-1
kubernetes.io/os=linux
Taints: <none>
CreationTimestamp: Mon, 01 Jan 2023 00:00:00 +0000
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
MemoryPressure False Tue, 02 Jan 2023 10:00:00 +0000 Mon, 01 Jan 2023 00:00:00 +0000 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Tue, 02 Jan 2023 10:00:00 +0000 Mon, 01 Jan 2023 00:00:00 +0000 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Tue, 02 Jan 2023 10:00:00 +0000 Mon, 01 Jan 2023 00:00:00 +0000 KubeletHasSufficientPID kubelet has sufficient PID available
Ready True Tue, 02 Jan 2023 10:00:00 +0000 Mon, 01 Jan 2023 00:00:00 +0000 KubeletReady kubelet is posting ready status
一个典型的Kubernetes节点主要包含以下核心组件：
- kubelet：负责与Master节点通信，管理Pod和容器的生命周期。
- 容器运行时（如Docker、containerd）：负责具体运行容器。
2. 什么是DaemonSet？
DaemonSet是Kubernetes中一种特殊的控制器，它确保集群中（或满足特定条件的）每个节点上都运行一个指定的Pod副本。当新节点加入集群时，DaemonSet会自动在该节点上创建Pod；当节点被移除时，其上的Pod也会被自动清理。这非常适合于部署集群级别的基础设施服务，节点上常见的DaemonSet组件包括：
- kube-proxy：负责Service的网络代理和负载均衡。
- CNI插件（如Calico， Flannel）：负责配置Pod的网络。
- CSI节点插件（可选）：负责在节点上挂载存储卷。
- 日志收集器（如Fluentd）：负责收集节点和容器日志。
- 监控代理（如Prometheus Node Exporter）：负责收集节点监控指标。
二、kubelet 与三大标准接口
1. kubelet 的核心定位：节点层 Pod 管理的「总管家」
kubelet 是运行在每个 Kubernetes 节点上的核心代理，它是连接控制平面与工作节点的唯一桥梁，也是Pod部署、配置和状态监控的绝对主导者。其设计体现了Kubernetes通过抽象和标准化来简化复杂容器管理任务的思想。
kubelet 的核心职责可以概括为：
- Pod 生命周期的唯一管理者：负责Pod的创建、启动、停止、监控和重启等全生命周期操作。
- 控制平面指令的执行者：通过监听API Server，获取调度到本节点的Pod清单，并确保它们按预期运行。
- 标准化接口的统一调用者：通过CRI、CNI、CSI三大接口与底层基础设施通信，实现与具体实现的解耦。
- 节点状态的实时报告者：定期向控制平面报告节点资源、Pod状态和容器健康状况，为集群调度和自愈提供依据。
2. 三大标准接口的设计理念与核心价值
Kubernetes 的 CRI、CNI、CSI 三大接口完美诠释了云原生架构 “解耦与标准化” 的核心设计理念。通过定义统一的接口规范，Kubernetes实现了与底层基础设施的解耦，使得不同的容器运行时、网络方案和存储后端可以无缝替换，极大地提升了系统的灵活性和可扩展性。
-
CRI（容器运行时接口）：定义了kubelet与容器运行时（如containerd、CRI-O）之间的通信协议。它的目标是屏蔽下层容器运行时的差异，让kubelet无需关心底层是Docker还是其他实现。因此，kubelet不直接调用Docker API，而是通过CRI接口来间接执行所有容器操作。
Pod调度到节点
↓
kubelet接收Pod定义
↓
调用CRI接口 → 容器运行时
↓
创建pause容器（Pod沙盒）
↓
拉取镜像 → 镜像仓库
↓
创建业务容器
↓
启动容器
↓
持续健康监控 ←→ 探针检查
-
CNI（容器网络接口）：定义了容器运行时应如何调用网络插件来为Pod配置网络。其核心思想是：当kubelet创建或销毁一个Pod时，它会调用预先配置好的CNI插件，传递“为这个Pod配置网络”（ADD命令）或“清理网络”（DEL命令）的指令。这为 Service Mesh 等高级网络功能提供了基础。
Pod创建完成pause容器
↓
kubelet调用CNI插件
↓
传递网络命名空间路径
↓
CNI插件配置网络
├── 创建veth设备对
├── 分配IP地址
├── 设置路由规则
└── 配置iptables规则
↓
返回网络配置结果
↓
Pod获得网络连通性
-
CSI（容器存储接口）：定义了容器编排系统与存储供应商之间的标准交互方式。CSI的目标是将存储驱动从Kubernetes核心代码中解耦出来，实现存储系统的插件化管理。在CSI出现之前，添加新存储系统需要修改Kubernetes核心代码，而CSI允许存储插件独立开发并部署，极大地促进了存储生态的繁荣。
Pod请求持久化存储
↓
PVC绑定PV
↓
Pod调度到节点
↓
kubelet调用CSI节点插件
↓
CSI插件挂载存储设备
├── 设备发现
├── 文件系统格式化
├── 挂载到临时目录
└── 绑定到Pod目录
↓
容器使用持久化存储
↓
Pod删除时卸载存储
3. 三大接口的协作关系
在Pod的完整生命周期中，这三个接口会按照特定顺序被kubelet调用，紧密协作：
Pod 创建阶段：
- kubelet首先调用CRI接口创建pause容器（Pod沙箱）。
- 接着调用CNI接口为Pod沙箱配置网络。
- 如果Pod定义了存储卷，则调用CSI接口挂载存储设备。
- 最后再次调用CRI接口创建并启动业务容器。
Pod 运行阶段：
- kubelet通过CRI接口持续监控容器状态和执行健康检查。
- 通过CSI接口确保存储卷的可用性。
- 网络通常由CNI插件初始化后保持，kubelet通过系统状态间接感知。
Pod 销毁阶段：
- kubelet通过CRI接口停止并删除业务容器。
- 调用CSI接口卸载存储卷。
- 调用CNI接口清理网络命名空间和相关资源。
- 最后通过CRI接口删除pause容器（Pod沙箱）。
这种清晰的协作流程确保了Pod从生到死的整个生命周期都能得到精准、有序的管理。
三、基于CRI的容器生命周期监控与健康检查
Kubernetes 完善的容器生命周期监控与健康检查机制是保障应用高可用性的关键。它使系统能够自动发现并处理故障，实现应用的自愈。
1. 容器状态的三种类型
Kubernetes 定义了容器的三种基本状态，每种状态都包含了用于诊断的详细信息：
- Waiting（等待）：容器正在等待启动所需的条件被满足（如正在下载镜像）。
- Running（运行中）：容器正在正常运行。
- Terminated（已终止）：容器已经停止运行（正常退出或异常终止）。
2. 健康检查机制详解
Kubernetes 提供了三种健康检查探针（Probe），由kubelet通过CRI接口执行：
2.1 存活探针（Liveness Probe）
- 作用：判断容器是否“活着”。如果检测失败，kubelet会杀死该容器并根据重启策略决定是否重启。
- 适用场景：检测应用死锁或内部错误导致的“进程在但服务已死”的情况。
- 检查方式：
- ExecAction：在容器内执行指定命令，返回码为0表示健康。
- TCPSocketAction：尝试与容器的指定端口建立TCP连接。
- HTTPGetAction：向容器的指定IP和端口发送HTTP GET请求，状态码为2xx或3xx表示健康。
2.2 就绪探针（Readiness Probe）
- 作用：判断容器是否已准备好接收流量。如果检测失败，则该Pod的IP地址会从服务的负载均衡端点列表中移除。
- 适用场景：控制流量进入时机，例如应用启动后需要加载大量数据或预热缓存。
- 检查方式：与存活探针相同（Exec、TCP、HTTP）。
2.3 启动探针（Startup Probe）
- 作用：判断应用是否已成功启动。在启动探针成功之前，存活探针和就绪探针都不会启动。
- 适用场景：启动速度特别慢的旧式应用，避免在启动过程中被存活探针误杀。
- 检查方式：与存活探针相同。
3. 状态报告机制
kubelet 负责将容器的状态实时同步给控制平面：
- 定期状态更新：kubelet默认每隔20秒向API Server报告一次节点及Pod状态。
- 事件记录：重要的状态变化（如容器启动失败、健康检查失败）会被记录为Event对象，方便用户通过
kubectl describe或kubectl get events查看。
- Pod阶段更新：kubelet会根据容器整体状态更新Pod的
status.phase字段（Pending， Running， Succeeded， Failed， Unknown）。
四、DaemonSet在Kubernetes节点中的工作流程
DaemonSet 作为节点级服务的载体，其工作流程是Kubernetes基础设施层稳定的保障：
- 节点加入：当新节点加入集群并通过认证后，DaemonSet控制器会检测到该节点。
- Pod创建：如果节点标签符合DaemonSet的选择器（selector），控制器会在该节点上创建一个对应的Pod。
- Pod启动：该节点的kubelet监听到Pod创建事件，通过CRI等接口启动Pod内的容器。
- 健康维护：kubelet持续监控该DaemonSet Pod的健康状态，确保其持续运行。如果Pod异常退出，kubelet会重启它。
- 节点退出：当节点被从集群中移除或变为NotReady状态时，DaemonSet控制器会删除在该节点上运行的Pod副本。
五、总结：Kubernetes节点的协同工作
在Kubernetes节点内部，各个组件通过标准接口和明确分工，实现了高效协同：
- CRI：作为Kubernetes与容器运行时的桥梁，实现了Pod的创建、运行和生命周期管理。
- CNI：作为网络抽象层，连接Kubernetes与多样化的网络插件，实现了Pod的网络联通性和隔离性。
- CSI：作为存储抽象层，连接Kubernetes与各种存储后端，实现了Pod数据的持久化存储。
- DaemonSet：作为部署模式，确保如kube-proxy、CNI插件、CSI插件、监控代理等集群基础设施服务在每个需要的节点上稳定运行。
正是这种通过 DaemonSet部署核心插件，再借由 kubelet调用CRI、CNI、CSI标准化接口 的架构，使得Kubernetes能够灵活支持丰富的生态组件，同时保持了核心系统的简洁、稳定与可维护性。理解这一协同机制，是掌握Kubernetes 容器化 与集群运维的关键。
如果你想深入了解云原生和 DevOps 的更多实践，欢迎到 云栈社区 与更多开发者交流讨论。
发表于 7 天前
|
查看: 14|
回复: 0
