4. 内置准入控制器详解：NamespaceLifecycle、LimitRanger、ResourceQuota、PodSecurity 等关键控制器

Kubernetes 内置了数十个准入控制器（Admission Controller），它们作为 API 请求的“守门人”，在对象被持久化到 etcd 之前执行验证（Validating）或修改（Mutating）逻辑。本章聚焦于与资源配额、命名空间生命周期及安全策略最相关的四个核心控制器，理解它们的工作原理是构建多租户集群和网络性能调优的基础。

4.1 控制器分类与执行顺序

准入控制器分为 Mutating（修改请求）和 Validating（验证请求）两类。Mutating 控制器先于 Validating 控制器执行，确保所有默认值注入后再进行校验。以下表格列出了本章重点控制器的类型与核心职责：

控制器名称 类型 核心职责 影响网络性能
NamespaceLifecycle Validating 阻止对正在终止的 Namespace 创建新资源；防止创建系统保留 Namespace 间接（防止资源泄漏导致网络策略失效）
LimitRanger Mutating + Validating 为未显式设置资源请求/限制的 Pod 注入默认值；验证 Pod 资源不超 LimitRange 直接（CPU/内存限制影响 CNI 带宽限速）
ResourceQuota Validating 确保 Namespace 内资源总量不超过配额；拒绝超配请求 直接（配额耗尽导致 Pod 调度失败，影响网络拓扑）
PodSecurity Validating 根据 Pod Security Standards（Privileged / Baseline / Restricted）验证 Pod 安全上下文 间接（限制 hostNetwork / hostPort 使用，影响网络模式选择）
执行顺序提示： 在 kube-apiserver 启动参数 --enable-admission-plugins 中，Mutating 控制器（如 LimitRanger 的注入部分）必须排在 Validating 控制器之前。推荐顺序：NamespaceLifecycle, LimitRanger, ResourceQuota, PodSecurity。

4.2 NamespaceLifecycle 控制器

该控制器是集群稳定性的第一道防线。它主要执行两个关键操作：

  • 阻止创建系统 Namespace： 拒绝在 kube-system、kube-public、kube-node-lease 等系统 Namespace 中创建非系统级资源。
  • 冻结 Terminating Namespace： 当 Namespace 处于 Terminating 状态时，拒绝所有新的资源创建请求。这避免了在 Namespace 清理过程中产生“孤儿”资源。
网络性能关联： 如果 Namespace 因资源残留长时间处于 Terminating 状态，其关联的网络策略（NetworkPolicy）和 Service 端点可能无法及时清理，导致 kube-proxy 或 CNI 插件维护过期的转发规则，增加不必要的 CPU 开销。

4.3 LimitRanger 控制器

LimitRanger 是资源配额的“微调器”。它通过 LimitRange 对象为 Namespace 内的 Pod 设置默认资源请求（Request）和限制（Limit），并验证单个 Pod 的资源声明是否在允许范围内。

4.3.1 典型配置示例

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limit-range
  namespace: production
spec:
  limits:
  - max:
      cpu: "4"
      memory: "8Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    type: Container

4.3.2 对网络性能的影响

当 LimitRanger 为 Pod 注入 CPU 限制时，CNI 插件（如 Calico、Cilium）的带宽限速功能会读取 Pod 的 requests.cpu 或 annotations 来分配网络带宽权重。如果未设置默认值，可能导致高优先级 Pod 无法获得预期的网络吞吐量。

调优建议： 在性能敏感 Namespace 中，显式设置 defaultRequest.cpu 为 Pod 实际需要的 CPU 下限，避免 LimitRanger 注入过低的默认值导致网络带宽限速不足。

4.4 ResourceQuota 控制器

ResourceQuota 是 Namespace 级别的资源“总闸”。它通过 ResourceQuota 对象限制 Namespace 内所有 Pod 的资源总和，防止单个 Namespace 耗尽集群资源。

4.4.1 配额维度

配额维度 示例 网络影响
计算资源 requests.cpu, limits.memory CPU 配额耗尽 → Pod 无法调度 → 网络拓扑变化
存储资源 requests.storage, persistentvolumeclaims PVC 配额满 → 无法挂载卷 → 影响有状态服务网络
对象数量 pods, services, configmaps Service 数量超限 → DNS 解析失败 → 网络连通性受损
扩展资源 requests.nvidia.com/gpu GPU 配额不足 → 推理 Pod 无法启动 → 网络负载失衡

4.4.2 配额耗尽时的行为

当 ResourceQuota 达到上限时，控制器会立即拒绝新的创建请求，并返回 HTTP 403 Forbidden。这直接影响了 Pod 的调度密度和网络负载分布。

监控指标： 使用 kubectl describe resourcequota 查看当前使用量。建议为每个 Namespace 设置 pods 和 services 配额，防止因对象数量过多导致 kube-proxy 或 CoreDNS 性能下降。

4.5 PodSecurity 控制器

PodSecurity 是 Kubernetes v1.23 引入的内置准入控制器，替代了废弃的 PodSecurityPolicy。它根据预定义的 Pod Security Standards（PSS）对 Pod 进行验证。

4.5.1 安全等级

  • Privileged： 无限制，允许 hostNetwork、hostPort、特权容器等。
  • Baseline： 禁止已知的提权行为，但允许默认网络模式。
  • Restricted： 严格限制，禁止 hostNetwork、hostPort、hostPID 等，强制使用非 root 用户。

4.5.2 网络性能权衡

使用 Restricted 等级会禁止 Pod 使用 hostNetwork: true，这意味着 Pod 必须通过 CNI 插件分配虚拟网络接口。对于需要原始套接字或高性能网络（如 DPDK）的工作负载，必须使用 Privileged 或 Baseline 等级。

性能陷阱： 在 Restricted 模式下，如果 Pod 未设置 securityContext.capabilities.drop: ["ALL"]，控制器会拒绝创建。这可能导致网络插件（如 Cilium 的 Envoy 代理）无法正常启动，因为某些 sidecar 容器需要 NET_ADMIN 或 NET_RAW 能力。

4.6 控制器协同工作流程

以下 SVG 图展示了四个控制器在 Pod 创建请求中的协同处理顺序：

内置准入控制器协同流程 内置准入控制器协同处理流程 API 请求（创建 Pod） 1. NamespaceLifecycle (Validating) 检查 Namespace 状态 & 系统保留 2. LimitRanger (Mutating + Validating) 注入默认资源限制 & 验证范围 3. ResourceQuota (Validating) 检查 Namespace 资源总量配额 4. PodSecurity (Validating) 验证安全上下文 & 能力限制 写入 etcd / 返回拒绝 Mutating 控制器（LimitRanger 注入）先于 Validating 控制器执行，确保配额校验基于完整对象

4.7 控制器配置与性能调优建议

在实际集群中，合理配置这四个控制器可以显著提升网络性能和资源利用率：

  1. 启用顺序： 在 kube-apiserver 的 --enable-admission-plugins 中，确保 NamespaceLifecycle, LimitRanger, ResourceQuota, PodSecurity 按此顺序排列。
  2. LimitRanger 默认值： 为每个 Namespace 设置合理的 defaultRequest.cpu，避免 CNI 带宽限速插件使用过低的默认值。
  3. ResourceQuota 对象配额： 设置 pods 和 services 配额上限，防止单个 Namespace 创建过多对象导致 kube-proxy 和 CoreDNS 性能下降。
  4. PodSecurity 豁免： 对于需要 hostNetwork 或 NET_ADMIN 能力的网络插件（如 Cilium、Calico 的 Felix），使用 Privileged 等级或配置 exemptions。
性能基准测试： 在启用所有四个控制器后，使用 kubectl bench 或自定义脚本测试 API 响应延迟。通常每个控制器增加 1-3ms 的延迟，但资源配额校验可以避免因资源争抢导致的网络抖动，整体收益远大于开销。

4.8 常见问题与排查

问题现象 可能原因 排查命令
Pod 创建被拒绝，提示 Forbidden ResourceQuota 达到上限 kubectl describe resourcequota -n <ns>
Pod 资源限制与预期不符 LimitRanger 未注入默认值 kubectl get limitrange -n <ns> -o yaml
Pod 无法使用 hostNetwork PodSecurity 等级为 Restricted kubectl describe ns <ns> | grep pod-security
Namespace 无法删除 NamespaceLifecycle 阻止清理 kubectl get ns <ns> -o json | jq '.status.phase'

理解这四个内置准入控制器的工作机制，是构建稳定、高性能 Kubernetes 集群的必修课。它们不仅保障了资源公平性，还间接影响了网络拓扑的稳定性和数据平面的转发效率。

← 上一章 📖 返回目录 下一章 →