Kubernetes Node Runtime Observability Security Design

这页合并讲 sig-node 里除 DRA 和 in-place resize 之外的核心 feature：kubelet/CRI runtime 边界、CPU/Memory/Topology Manager、Pod lifecycle、安全隔离、节点可观测和 resource health。逐个 KEP 的 Alpha/Beta/GA、是否实现和 feature gate 见 kubernetes-keps-implementation-matrix。

一句话定位

SIG Node 的核心设计方向是把 kubelet 从“绑定某个 runtime 和一堆节点本地实现细节的执行器”，演进为“通过 CRI、resource managers、status/metrics、security primitives 管理节点执行状态的标准控制点”。

Runtime Boundary: kubelet / CRI / RuntimeClass

2040-kubelet-cri、2221-remove-dockershim、585-runtime-class 是 runtime 边界的基础线：

kubelet
  |
  +-- CRI
        |
        +-- containerd
        +-- CRI-O
        +-- sandboxed runtime
        +-- Windows / other runtimes

Pod.spec.runtimeClassName
  |
  +-- runtime handler selection

设计意义：

• kubelet 不再内置 Docker 特殊路径。
• runtime 能通过 CRI 独立演进。
• RuntimeClass 把 sandboxed runtime、gVisor/Kata-like runtime、特殊 runtime handler 变成 Pod 级选择。
• 4033-group-driver-detection-over-cri 继续减少 kubelet/runtime cgroup driver 配置不一致。
• 5825-cri-pagination 面向大规模节点 runtime API 性能。

边界判断：kubelet 负责 Kubernetes Pod lifecycle 和节点资源语义；runtime 负责容器创建、运行、状态、日志和低层隔离执行。

Resource Managers

CPU Manager、Memory Manager、Topology Manager 是性能型 workload 的节点侧底座。

这组 feature 和 kubernetes-in-place-pod-resize-design 强相关。resize 如果只改 spec，不理解 CPU Manager static policy、Memory Manager、Topology Manager，就会在高性能节点上失败或造成不可解释状态。

Device Plugin / CDI / PodResources

传统 device plugin 仍然是 Kubernetes 设备接入的稳定路径：

• 3573-device-plugin 提供 kubelet device plugin API。
• 4009-add-cdi-devices-to-device-plugin-api 让 device plugin 返回 CDI devices，减少 runtime-specific 注入逻辑。
• 3695-pod-resources-for-dra 扩展 PodResources API，使其包含 DRA resource。

这条线和 kubernetes-dra-design-deep-dive 的关系是：device plugin 是旧但稳定的离散设备模型；DRA 是新的结构化 claim 模型；CDI 是两者都可使用的 runtime 注入表达。

Pod Lifecycle

SIG Node 的 lifecycle KEP 不是杂项，它们决定 kubelet 如何解释 Pod 内部容器关系：

Sidecar containers 对 Job、service mesh、agent runtime 都很重要：没有明确 sidecar 语义时，Job 完成、主容器退出、sidecar 终止顺序会变得混乱。

Security / Isolation

节点安全线覆盖 user namespace、rootless kubelet、seccomp、cgroup v2 和 kubelet authz：

这组 KEP 的共同方向是：把“容器隔离靠 runtime 默认行为”升级为“Pod API、kubelet、runtime、kernel primitives 明确协作”。

Observability / Node Health

可观测线是 autoscaling、scheduling 和排障的输入信号：

2371 对 metrics-server 和 HPA 都重要：如果 kubelet 的 stats 来源不稳定，autoscaling 的输入就不可靠。4680 对 GPU/DRA workload 重要：Pod pending 或 degraded 时，用户需要知道是设备健康而不是普通资源不足。

合并设计图

Pod API
  |
  +-- runtimeClass / sidecar / userns / resize / resource claims
  |
kubelet
  |
  +-- CRI runtime boundary
  +-- CPU / Memory / Topology Manager
  +-- Device Plugin / DRA kubelet plugin / CDI
  +-- Pod lifecycle and eviction
  +-- Pod status / Node conditions / metrics
  |
container runtime + kernel
  |
  +-- cgroups / namespaces / seccomp / devices

和其他设计页的关系

• kubernetes-in-place-pod-resize-design 依赖 resource managers、CRI resource update、status/metrics。
• kubernetes-dra-design-deep-dive 依赖 kubelet plugin、CDI、PodResources API、resource health。
• kubernetes-hpa-autoscaling-design 依赖 kubelet stats、CRI stats、metrics-server。
• kubernetes-scheduler-core-design 依赖 node labels、resource health、Node Conditions、declared features 作为调度输入。

关键失败模式

关键 KEP 实现状态

追踪重点

• CRI stats 是否足够替代 cAdvisor 依赖，并被 metrics-server 稳定消费。
• resource health status 是否覆盖 DRA 和传统 device plugin。
• rootless kubelet / HostNetwork userns 是否有清晰生产约束。
• CPU/Memory/Topology Manager 与 Pod-level resources、in-place resize 的兼容性。
• sidecar containers 与 Job、LWS、agent runtime 的实际行为是否符合用户直觉。