4. Kubernetes 节点池架构:节点池概念、节点生命周期、kubelet 与容器运行时交互、CNI 网络模型

4.1 节点池概念与设计目标

节点池(Node Pool)是 Kubernetes 集群中一组具有相同配置、标签、污点和资源的节点集合。在云原生环境中,节点池通常对应同一实例规格、同一镜像版本、同一可用区的虚拟机或物理机。节点池的核心设计目标是实现工作负载的差异化调度与基础设施的批量管理。

维度节点池 A(通用型)节点池 B(GPU 型)节点池 C(存储型)
实例规格4C8G8C32G + NVIDIA A10016C64G + NVMe SSD
容器运行时containerd 1.6containerd 1.7 + nvidia-container-toolkitcontainerd 1.6
镜像缓存策略按需拉取预缓存 GPU 基础镜像预缓存大数据基础镜像
CNI 插件Calico (VXLAN)Calico (BGP) + SR-IOVCalico (VXLAN) + 巨帧
典型工作负载无状态微服务模型训练、推理数据库、日志存储
节点池与 eBPF 观测的关联: 不同节点池的容器运行时版本、CNI 数据面模式、内核参数直接影响 eBPF 程序的挂载点与数据采集路径。巡检时需按节点池维度聚合性能指标,避免跨池混淆。

4.2 节点生命周期与状态转换

Kubernetes 节点从加入集群到最终移除,经历一系列状态转换。每个状态转换点都是 eBPF 观测的关键时机。

  1. Pending(待调度):节点对象已创建,但 kubelet 尚未完成注册。此时可观测 kubelet 启动日志与证书签发流程。
  2. Ready(就绪):kubelet 成功上报节点状态,控制面将节点标记为可调度。此时 eBPF 程序可挂载到网络设备与系统调用。
  3. NotReady(未就绪):kubelet 心跳超时或节点资源耗尽。需通过 eBPF 追踪 kubelet 与 API Server 之间的 gRPC 连接状态。
  4. DiskPressure / MemoryPressure(资源压力):节点磁盘或内存达到驱逐阈值。eBPF 可采集 OOM killer 事件与 I/O 延迟分布。
  5. Terminating(终止中):节点被驱逐或缩容。需观测 Pod 迁移过程中的网络连接迁移与 CNI 清理操作。
节点生命周期状态转换图 Pending Ready NotReady Terminating DiskPressure MemoryPressure eBPF 观测时机:kubelet 注册 → 心跳超时 → 资源驱逐 → 连接迁移 关键挂载点:tracepoint/sched/sched_process_exit, kprobe/tcp_connect, kprobe/skb_copy_datagram_iter

4.3 kubelet 与容器运行时交互

kubelet 是节点上最核心的 agent,它通过 CRI(Container Runtime Interface)与容器运行时通信。CRI 基于 gRPC 协议,定义了 RuntimeService 和 ImageService 两个服务。eBPF 可以在 gRPC 调用层、Unix Domain Socket 层和系统调用层进行观测。

CRI 方法功能eBPF 观测点性能指标
RunPodSandbox创建 Pod 沙箱(网络命名空间)kprobe: netns_create沙箱创建延迟
CreateContainer创建容器(镜像拉取 + 存储层准备)kprobe: overlay_mount, tracepoint: syscalls/sys_enter_openat镜像层挂载时间
StartContainer启动容器进程tracepoint: sched/sched_process_fork进程启动延迟
PullImage拉取容器镜像kprobe: tcp_sendmsg, tracepoint: block/block_rq_complete镜像拉取吞吐量
RemoveContainer删除容器kprobe: overlay_unmount清理完成时间
关键交互路径: kubelet 通过 /var/run/containerd/containerd.sock 与 containerd 通信。eBPF 可挂载到 unix_stream_sendmsg 和 unix_stream_recvmsg 来捕获 CRI 请求与响应的完整延迟分布。

4.4 CNI 网络模型与数据面

CNI(Container Network Interface)是 Kubernetes 网络插件的标准接口。kubelet 在创建 Pod 沙箱后调用 CNI 插件,完成网络命名空间创建、接口配置和路由规则设置。CNI 网络模型直接影响 Pod 间通信的延迟与吞吐量。

CNI 网络模型与 eBPF 观测点 Pod A eth0: veth pair netns: pod-a IP: 10.1.1.2 Pod B eth0: veth pair netns: pod-b IP: 10.1.1.3 主机网络命名空间(root netns) veth 对端 → cbr0 / 路由表 → 转发决策 CNI 插件:Calico / Flannel / Cilium eBPF 挂载点:tc/egress, tc/ingress, xdp CNI 网络模型核心流程:创建 veth pair → 一端移入 Pod netns → 配置 IP/路由 → 主机端连接网桥或路由表 eBPF 观测指标:veth 对端延迟、iptables 规则匹配次数、overlay 隧道封装/解封装开销 常见 CNI 数据面对比 Calico (BGP):直接路由,无封装,性能最优 Calico (VXLAN):overlay 隧道,跨子网通信,封装开销约 5-10% Cilium (eBPF):直接路由 + eBPF 加速,可绕过 iptables,延迟降低 30-50%

4.5 节点池巡检的关键观测维度

基于上述架构,节点池巡检应聚焦以下四个维度,每个维度都与 eBPF 观测点直接对应:

  • 节点状态稳定性:通过 eBPF 追踪 kubelet 与 API Server 之间的 gRPC 心跳延迟,识别 NotReady 的前兆模式。
  • 容器运行时性能:使用 eBPF 采集 CRI 调用延迟,特别是 PullImage 和 CreateContainer 阶段的镜像层操作耗时。
  • CNI 数据面质量:在 veth 对端和 overlay 隧道端点挂载 eBPF 程序,采集包转发延迟、丢包率和重传率。
  • 资源压力事件:通过 tracepoint 捕获 OOM killer、磁盘 I/O 延迟超过阈值的进程,关联到具体 Pod 和节点池。
常见陷阱: 不同节点池可能使用不同的 CNI 插件版本或配置模式(如 Calico 的 VXLAN vs BGP)。eBPF 程序必须感知节点池标签,避免将不同数据面的指标混入同一聚合窗口。