3. Kubernetes 节点池概念：节点池定义、节点池与 NodeSelector/Taints 的关系、多节点池场景下的安全挑战
3.1 节点池定义与核心属性
在 Kubernetes 集群管理中，节点池（Node Pool） 是一组具有相同配置、标签、污点及资源规格的节点集合。节点池通常由云服务商（如 AKS、EKS、GKE）或集群生命周期管理工具（如 Cluster API）提供，用于简化大规模集群的节点分组管理。
节点池的核心属性包括：
| 属性 | 说明 | 典型值示例 |
|---|---|---|
| 节点规格 | 节点的 CPU、内存、GPU 等硬件配置 | Standard_D8s_v3 (8 vCPU, 32 GB) |
| 节点数量 | 节点池内期望运行的节点数（支持自动扩缩容） | min: 3, max: 20 |
| 节点标签 | 自动附加到所有节点的标签，用于调度匹配 | node-pool-type: gpu |
| 节点污点 | 阻止非容忍 Pod 调度到该节点池 | gpu=true:NoSchedule |
| 操作系统 | 节点使用的操作系统镜像 | Ubuntu 22.04, Container-Optimized OS |
| 网络配置 | 子网、安全组、DNS 设置 | subnet-10.0.1.0/24 |
安全视角： 节点池是安全边界的物理载体。不同节点池之间的网络隔离、内核版本差异、eBPF 程序加载策略都可能成为攻击面。在 eBPF 节点池安全巡检中，节点池的标签和污点配置直接影响巡检策略的生效范围。
3.2 节点池与 NodeSelector / Taints 的关系
节点池、NodeSelector 和 Taints/Tolerations 共同构成了 Kubernetes 的调度控制体系，但它们的职责和粒度不同：
| 调度机制 | 作用层级 | 控制方向 | 与节点池的关系 |
|---|---|---|---|
| 节点池 | 集群管理 | 基础设施分组 | 定义节点分组，自动注入标签和污点 |
| NodeSelector | Pod 调度 | Pod 选择节点 | Pod 通过匹配节点池自动注入的标签来调度到特定节点池 |
| Taints / Tolerations | Pod 调度 | 节点排斥 Pod | 节点池设置污点，只有带对应容忍的 Pod 才能调度 |
典型的工作流程如下：
- 管理员创建节点池时，指定一组标签（如
pool=production）和污点（如critical=true:NoSchedule）。 - 节点池控制器自动将这些标签和污点附加到池内所有节点。
- Pod 通过
nodeSelector或nodeAffinity匹配标签，同时通过tolerations容忍污点，最终被调度到目标节点池。
安全含义： 节点池的标签和污点配置错误可能导致敏感工作负载（如 eBPF 审计代理）被调度到非预期节点，或非授权 Pod 进入高安全节点池。巡检时需验证节点池标签与 Pod 调度策略的一致性。
3.3 多节点池场景下的安全挑战
当集群中存在多个节点池时，安全挑战呈指数级增长。以下是最关键的四个安全挑战：
挑战 1：节点池间网络隔离不足
默认情况下，同一集群内不同节点池的 Pod 可以互相通信。如果节点池用于隔离不同安全等级的工作负载（如生产 vs 开发），缺乏网络策略可能导致横向移动攻击。eBPF 流量审计需要能够区分节点池间的流量，并标记跨池访问。
默认情况下，同一集群内不同节点池的 Pod 可以互相通信。如果节点池用于隔离不同安全等级的工作负载（如生产 vs 开发），缺乏网络策略可能导致横向移动攻击。eBPF 流量审计需要能够区分节点池间的流量，并标记跨池访问。
挑战 2：节点池内核版本碎片化
不同节点池可能运行不同内核版本（如 Ubuntu 20.04 vs 22.04），导致 eBPF 程序兼容性问题。某些 eBPF 辅助函数或 BPF 类型格式（BTF）可能在旧内核上不可用，造成审计盲区。
不同节点池可能运行不同内核版本（如 Ubuntu 20.04 vs 22.04），导致 eBPF 程序兼容性问题。某些 eBPF 辅助函数或 BPF 类型格式（BTF）可能在旧内核上不可用，造成审计盲区。
挑战 3：节点池污点/标签配置漂移
手动修改节点标签或污点后，节点池控制器可能不会自动同步，导致调度策略失效。攻击者可能利用配置漂移将恶意 Pod 调度到高权限节点池。
手动修改节点标签或污点后，节点池控制器可能不会自动同步，导致调度策略失效。攻击者可能利用配置漂移将恶意 Pod 调度到高权限节点池。
挑战 4：eBPF 程序跨节点池部署不一致
使用 Helm 部署 eBPF 审计代理时，如果节点池配置不同（如 seccomp 策略、AppArmor 配置），可能导致 eBPF 程序在某些节点池加载失败或被绕过。
使用 Helm 部署 eBPF 审计代理时，如果节点池配置不同（如 seccomp 策略、AppArmor 配置），可能导致 eBPF 程序在某些节点池加载失败或被绕过。
下图展示了多节点池场景下的安全挑战拓扑：
3.4 节点池安全巡检的关键检查项
基于上述挑战，eBPF 节点池安全巡检应覆盖以下检查项：
| 检查类别 | 检查项 | eBPF 检测方法 | 风险等级 |
|---|---|---|---|
| 网络隔离 | 跨节点池 Pod 通信是否受 NetworkPolicy 约束 | eBPF 跟踪 connect/sendmsg 系统调用，标记源和目标节点池 | 高 |
| 内核兼容性 | 节点池内核版本是否支持所需 eBPF 特性 | eBPF 程序加载前检查 BTF 可用性和辅助函数列表 | 中 |
| 配置一致性 | 节点池标签/污点是否与预期一致 | eBPF 监控节点对象变更事件，对比期望配置 | 高 |
| 调度合规 | 敏感 Pod 是否被调度到非预期节点池 | eBPF 跟踪 Pod 创建事件，校验 nodeSelector 匹配 | 高 |
| eBPF 代理状态 | 各节点池的 eBPF 审计代理是否正常运行 | eBPF 程序心跳检测 + 节点池粒度健康检查 | 中 |
实践建议： 在 Helm Chart 中为每个节点池定义独立的 values 配置段，通过
.Values.nodePools 映射节点池标签到 eBPF 审计策略。这样可以在 Helm 部署时自动为不同节点池生成差异化的 eBPF 程序配置，避免“一刀切”导致的兼容性问题。