K8s准入控制机制

Kubernetes准入机制完全指南：生产环境该用什么？

Kubernetes的准入机制（Admission Control）就像集群的“安检员”，所有API请求在真正执行前都要经过它的检查。这个机制决定了哪些请求能通过、哪些需要修改、哪些直接拒绝。下面从生产实践角度解析它的核心要点。

---

准入机制三大核心功能

1. 拦截检查

   • 当用户执行kubectl apply或通过API操作资源时，请求会先经过准入控制层
   • 检查时间点：认证（Authentication）→ 授权（Authorization）→ 准入控制（Admission）

2. 修改请求

   • 某些控制器可以动态修改请求内容（比如自动给Pod注入Sidecar容器）
   • 典型场景：Istio自动注入Envoy代理

3. 拒绝非法操作

   • 不符合安全策略的请求直接拦截（比如创建特权容器）
   • 错误示例：

     Error from server: admission webhook "deny-privileged-pods" denied the request: Privileged mode is not allowed
     

---

生产环境必知的两类准入控制器

Kubernetes内置了30+准入控制器（可通过kube-apiserver --enable-admission-plugins查看），生产环境重点关注以下两类：

1. 原生内置控制器

控制器名称	作用	生产场景示例
NamespaceLifecycle	防止删除正在使用的Namespace	避免误删关键业务命名空间
ResourceQuota	限制Namespace资源总量（CPU/内存/Pod数）	防止单个团队占用过多集群资源
LimitRanger	设置Pod/容器的默认资源限制	强制所有容器配置requests/limits
PodSecurity	替代已废弃的PSP，实施Pod安全策略	禁止以root用户运行容器

2. 动态Webhook控制器

类型	功能特点	推荐工具
ValidatingWebhook	只检查不修改，用于合规性验证	OPA Gatekeeper、Kyverno
MutatingWebhook	可修改请求内容，用于自动化注入	Istio、Vault Agent

---

生产环境四大实战场景

场景1：强制所有镜像来自私有仓库

• 问题：防止部署来源不明的镜像
• 方案：使用ValidatingWebhook检查Pod的镜像地址

  # OPA Gatekeeper策略示例
  package kubernetes.admission
  deny[msg] {
    input.request.kind.kind == "Pod"
    image := input.request.object.spec.containers[_].image
    not startswith(image, "harbor.mycompany.com/")
    msg := "只允许使用私有仓库镜像"
  }
  

场景2：自动为Pod添加资源限制

• 方案：使用MutatingWebhook + LimitRange组合拳

  # LimitRange配置示例（自动填充requests/limits）
  apiVersion: v1
  kind: LimitRange
  metadata:
    name: cpu-limit-range
  spec:
    limits:
    - default:
        cpu: "500m"
      type: Container
  

场景3：禁止特权容器

• 方案：启用PodSecurity准入控制器

  # API Server配置启用PodSecurity
  apiVersion: apiserver.config.k8s.io/v1
  kind: AdmissionConfiguration
  plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: "restricted"  # 严格模式
  

场景4：多租户环境隔离

• 方案：ValidatingWebhook + 自定义标签验证

  # 验证Deployment必须携带team标签
  deny[msg] {
    input.request.kind.kind == "Deployment"
    not input.request.object.metadata.labels.team
    msg := "所有工作负载必须标注所属团队"
  }
  

---

准入控制器的启用与排错

如何启用控制器？

修改kube-apiserver启动参数（以kubeadm部署为例）：

# /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
  containers:
  - command:
    - kube-apiserver
    - --enable-admission-plugins=NamespaceLifecycle,LimitRanger,PodSecurity,ResourceQuota
    - --disable-admission-plugins=AlwaysAdmit  # 关闭危险默认项

常见问题排查

1. Webhook超时导致API卡顿

   • 调整超时时间：--default-timeout-seconds=10
   • 配置故障策略：failurePolicy: Ignore（生产环境慎用）

2. 控制器顺序导致策略失效

   • MutatingWebhook执行顺序由配置顺序决定
   • 关键策略应设置webhookTimeoutSeconds和reinvocationPolicy

---

生产级工具推荐

工具名称	适用场景	核心优势
OPA Gatekeeper	复杂策略管理（如合规检查）	策略即代码，支持Rego语言
Kyverno	Kubernetes原生策略引擎	无需学习新语言，YAML编写策略
Cert-Manager	自动管理TLS证书	与Let's Encrypt深度集成
Vault Agent Injector	动态注入敏感信息（数据库密码等）	避免Secrets明文存储

---

总结：准入机制是集群安全的基石

在生产环境中，建议采用 "原生控制器兜底 + Webhook扩展定制" 的组合方案。每季度进行一次准入策略审计，重点关注：

1. 是否所有工作负载都经过安全策略校验
2. Webhook服务的性能和高可用保障
3. 策略版本是否与K8s版本兼容

记住：好的准入控制策略既要足够严格（拦住危险操作），又要保持灵活（不影响正常业务发布）。