4. 变更门禁核心概念
在 Kubernetes 存储变更场景中，变更门禁是一道在变更操作生效前强制执行的校验与决策关卡。它并非 Kubernetes 原生资源，而是一种由平台工程团队通过准入控制器、策略引擎和外部系统组合实现的安全护栏，确保只有满足预定义条件的存储变更才能进入集群状态机。
4.1 什么是变更门禁
变更门禁（Change Gate）是一个逻辑上的“停止-检查-放行”节点，部署在用户提交变更请求与实际执行变更之间。它的核心职责包括：
- 校验变更内容：检查 PVC 扩容、StorageClass 切换、PV 回收策略修改等操作是否符合规范。
- 验证依赖状态：确认底层存储后端（如 Ceph、NFS、云盘）是否健康、容量是否充足。
- 评估变更风险：根据变更影响范围（如是否涉及有状态应用、是否触发数据迁移）自动打分。
- 执行审批策略：低风险变更自动放行，高风险变更推送给审批人。
关键认知： 变更门禁不是单一组件，而是一组策略和流程的集合。在 Kubernetes 中，它通常以 ValidatingAdmissionWebhook 或 MutatingAdmissionWebhook 的形式存在，但门禁逻辑本身可以外挂到 CI/CD 流水线、GitOps 控制器或自定义 Operator 中。
4.2 门禁的触发条件
变更门禁并非对所有 API 请求都生效，它只在满足特定触发条件时被激活。下表列出了 Kubernetes 存储场景中最常见的触发条件：
| 触发条件 | API 资源 | 典型操作 | 门禁关注点 |
|---|---|---|---|
| PVC 创建 | PersistentVolumeClaim | CREATE | StorageClass 是否存在、容量是否超限、访问模式是否合法 |
| PVC 更新 | PersistentVolumeClaim | UPDATE | 扩容是否触发数据迁移、是否修改了不可变字段（如 storageClassName） |
| PV 回收策略变更 | PersistentVolume | UPDATE | 从 Retain 改为 Delete 是否会导致数据丢失、是否有应用正在使用 |
| StorageClass 创建/更新 | StorageClass | CREATE / UPDATE | provisioner 是否受信任、参数是否与后端存储兼容 |
| StatefulSet 更新 | StatefulSet | UPDATE | volumeClaimTemplates 变更是否影响已有 PVC、是否触发 Pod 重建 |
| Pod 创建（挂载存储） | Pod | CREATE | 引用的 PVC 是否存在、是否处于 Bound 状态、节点是否可访问存储 |
除了上述资源级触发条件，门禁还可以基于上下文信息触发：
- 变更窗口：仅在维护窗口内允许执行存储变更。
- 用户角色：普通开发者提交的存储变更必须经过门禁，集群管理员可跳过。
- 变更频率：同一 PVC 在 24 小时内被多次修改时触发二次审批。
- 集群健康状态：当集群节点或存储后端处于异常状态时，所有存储变更均被门禁拦截。
4.3 门禁与准入控制器（Admission Controller）的关系
准入控制器是 Kubernetes API Server 内置的请求拦截机制，而变更门禁是业务策略层的实现。两者之间的关系可以用下图概括：
从架构上看，变更门禁与准入控制器的关系可以总结为以下三点：
| 维度 | 准入控制器（Admission Controller） | 变更门禁（Change Gate） |
|---|---|---|
| 定位 | Kubernetes API Server 的插件机制 | 基于准入控制器实现的业务策略层 |
| 职责 | 拦截并处理所有 API 请求（认证、授权、变异、校验） | 针对存储变更执行特定的业务规则和审批流程 |
| 实现方式 | 内置控制器 + Webhook（Mutating / Validating） | 通常以 ValidatingAdmissionWebhook 形式部署，也可集成到 Operator 或 CI/CD 中 |
| 决策范围 | 语法校验、资源配额、安全策略等通用规则 | 存储容量规划、数据迁移风险、变更窗口、审批链等业务逻辑 |
| 执行时机 | 请求认证后、对象持久化前（Admission 阶段） | 在 ValidatingWebhook 阶段执行，也可在变更前由外部系统触发 |
| 失败影响 | 请求被拒绝，返回错误给客户端 | 请求被拒绝或进入审批队列，变更不生效 |
实践建议： 在搭建存储变更门禁时，优先使用 ValidatingAdmissionWebhook 而非 MutatingAdmissionWebhook。因为存储变更通常涉及数据安全，变异操作（如自动修改 PVC 大小）可能带来意外风险。门禁应专注于“校验-拒绝”或“校验-放行”，而非自动修复。
4.4 门禁的典型工作流程
一个完整的变更门禁流程通常包含以下步骤：
- 请求到达：用户通过 kubectl、API 或 GitOps 提交存储变更请求。
- API Server 拦截：请求进入准入控制器链，触发注册的 ValidatingAdmissionWebhook。
- 门禁服务接收：Webhook 服务端（即变更门禁服务）收到 AdmissionReview 请求。
- 策略匹配：门禁根据请求的资源类型、操作、用户身份、集群状态等上下文匹配预定义策略。
- 外部校验：门禁调用外部系统（如存储管理平台、CMDB、容量规划工具）获取实时数据。
- 风险评分：基于校验结果和预置规则计算变更风险等级（低/中/高）。
- 决策输出：
- 允许：返回 AdmissionResponse 的 allowed=true，变更继续执行。
- 拒绝：返回 allowed=false 并附带拒绝原因，变更被 API Server 拦截。
- 审批中：返回 allowed=false 并提示“需要审批”，变更进入外部审批流程，审批通过后重新提交。
- 审计日志：无论结果如何，门禁都将决策记录到审计系统，用于事后追溯。
常见陷阱： 门禁服务本身必须是高可用的。如果 ValidatingAdmissionWebhook 配置了
failurePolicy: Fail，门禁服务宕机会导致所有匹配的 API 请求被拒绝，包括正常的 Pod 创建和 PVC 使用。建议在门禁服务未就绪时使用 failurePolicy: Ignore 并配合监控告警，或者部署多副本 + 负载均衡。
4.5 门禁策略的配置示例
以下是一个基于 ValidatingAdmissionWebhook 的变更门禁配置片段，它拦截 PVC 更新请求并调用外部门禁服务：
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: storage-change-gate
webhooks:
- name: gate.storage.example.com
clientConfig:
service:
name: storage-gate-svc
namespace: kube-system
path: /validate
caBundle: <base64-encoded-ca-cert>
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: [""]
apiVersions: ["v1"]
resources: ["persistentvolumeclaims"]
scope: "*"
admissionReviewVersions: ["v1"]
sideEffects: None
timeoutSeconds: 5
failurePolicy: Ignore
matchPolicy: Equivalent
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values: ["kube-system", "gate-system"]
objectSelector:
matchLabels:
gate-enabled: "true"
该配置的关键设计点：
- 只拦截 PVC 的 CREATE 和 UPDATE，不拦截 DELETE（删除操作通常由回收策略管理）。
- failurePolicy: Ignore 确保门禁服务故障时不影响集群正常运行。
- namespaceSelector 排除系统命名空间，避免门禁自身组件被拦截。
- objectSelector 只对带有
gate-enabled: true标签的 PVC 生效，实现按需启用门禁。
通过这种配置，变更门禁可以精确地作用于目标存储资源，既保证了安全，又避免了对整个集群的过度约束。