4. 内置准入控制器详解：NamespaceLifecycle、LimitRanger、ResourceQuota、PodSecurity等常用内置控制器
Kubernetes 内置了数十个准入控制器（Admission Controller），它们作为 API 请求的“守门员”，在对象被持久化到 etcd 之前执行校验、修改或默认值注入。本章聚焦于对 Pod 密度与资源管控影响最直接的四个内置控制器：NamespaceLifecycle、LimitRanger、ResourceQuota 和 PodSecurity。理解它们的工作原理与性能特征，是优化集群准入阶段延迟、提升 Pod 调度密度的前提。
4.1 控制器分类与执行阶段
内置准入控制器按功能分为两类：
- Mutating（变更）：修改请求对象，注入默认值或转换字段。
- Validating（验证）：校验请求对象是否符合集群策略，拒绝非法请求。
执行顺序为：所有 Mutating 控制器 → 所有 Validating 控制器。同一阶段内的控制器按 kube-apiserver 启动参数 --enable-admission-plugins 中指定的顺序执行。
| 控制器名称 | 类型 | 核心作用 | 对 Pod 密度影响 |
|---|---|---|---|
| NamespaceLifecycle | Validating | 阻止在 Terminating 或不存在 Namespace 中创建资源 | 低（仅做存在性检查） |
| LimitRanger | Mutating + Validating | 为未设置资源限制的 Pod 注入默认 request/limit | 中（影响资源超卖比例） |
| ResourceQuota | Validating | 校验 Namespace 级别的资源总量是否超限 | 高（直接限制可调度 Pod 数量） |
| PodSecurity | Validating | 根据 Pod Security Standards 拒绝不安全 Pod | 中（拒绝高风险 Pod 影响密度） |
4.2 NamespaceLifecycle 控制器
NamespaceLifecycle 是一个轻量级的 Validating 控制器，主要执行两项检查：
- 禁止在 Terminating 状态的 Namespace 中创建新资源：当 Namespace 正在被删除（处于 Terminating 状态）时，拒绝所有 CREATE 请求，防止资源残留。
- 禁止在不存在的 Namespace 中创建资源：确保所有资源必须归属于一个活跃的 Namespace。
4.3 LimitRanger 控制器
LimitRanger 是 Mutating + Validating 双重控制器，作用于 Namespace 级别。它通过 LimitRange 资源定义默认值和范围约束：
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
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对 Pod 密度的影响：
- 默认值注入：未显式设置资源 request/limit 的 Pod 会被注入默认值，避免因缺失限制导致节点资源过载。
- 超卖控制：通过
min/max约束，防止单个 Pod 占用过多资源，间接提升整体 Pod 密度。 - 性能开销：Mutating 阶段需要解析 Pod 模板并注入字段，单次处理耗时约 0.5–2ms，属于可接受范围。
defaultRequest 但未设置 default，则 Pod 的 limit 不会被注入，可能导致 QoS 类别降级为 Burstable。建议始终同时设置 default 和 defaultRequest。
4.4 ResourceQuota 控制器
ResourceQuota 是纯 Validating 控制器，用于限制 Namespace 级别的资源总量。它是影响 Pod 密度的最直接因素：
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: production
spec:
hard:
requests.cpu: "20"
requests.memory: "40Gi"
limits.cpu: "40"
limits.memory: "80Gi"
pods: "100"
count/deployments.apps: "10"关键性能指标：
| 指标 | 说明 | 优化建议 |
|---|---|---|
| Quota 计算延迟 | 每次 CREATE 请求需计算当前 Namespace 已使用量 | 避免在单个 Namespace 中创建过多资源对象（建议 < 5000） |
| Quota 更新频率 | 资源释放后 Quota 状态异步更新 | 使用 --quota-resync-period 参数控制同步间隔（默认 5s） |
| Pod 密度上限 | 由 pods 和 requests.cpu/memory 共同决定 |
合理设置 pods 配额，避免资源配额先于 Pod 数量耗尽 |
requests.cpu 和 limits.cpu，利用超卖比例（limits/requests）控制节点资源利用率。例如，设置 limits.cpu: "40" 和 requests.cpu: "20" 允许 2:1 的超卖。
4.5 PodSecurity 控制器
PodSecurity（自 Kubernetes v1.23 起替代 PodSecurityPolicy）是一个 Validating 控制器，根据 Pod Security Standards 的三个等级（Privileged、Baseline、Restricted）校验 Pod 安全上下文：
| 安全等级 | 策略严格度 | 对 Pod 密度影响 | 典型限制 |
|---|---|---|---|
| Privileged | 无限制 | 无影响 | 允许特权容器、hostNetwork、hostPID 等 |
| Baseline | 中等 | 低 | 禁止特权容器、禁止 hostPID/IPC，允许非 root 用户 |
| Restricted | 最严格 | 中 | 强制只读根文件系统、禁止特权提升、必须使用 Seccomp |
对 Pod 密度的影响：
- 拒绝高风险 Pod：Restricted 等级会拒绝大量需要特权的 Pod，降低可调度 Pod 数量。
- 性能开销：校验 Pod 安全上下文涉及字段级检查，单次耗时约 0.3–1ms，对整体延迟影响较小。
- 推荐实践：对生产 Namespace 使用 Baseline 等级，对高安全需求 Namespace 使用 Restricted 等级，避免全局使用 Privileged。
4.6 控制器组合策略与性能调优
在实际集群中，这四个控制器通常同时启用。以下组合策略可最大化 Pod 密度同时保持稳定性：
- 启用顺序：在 kube-apiserver 启动参数中，将 LimitRanger 放在 ResourceQuota 之前，确保默认值注入后再进行配额校验。
- Namespace 隔离：对高密度 Namespace（如 CI/CD 环境）使用较宽松的 ResourceQuota 和 Baseline 安全等级；对生产 Namespace 使用严格配额和 Restricted 等级。
- 监控 Quota 使用率：通过
kubectl describe resourcequota监控配额使用率，设置告警阈值（如 80% 使用量触发扩容或清理）。 - 避免过度校验：如果集群中所有 Pod 都显式设置了资源限制，可考虑关闭 LimitRanger 以减少 Mutating 阶段开销。