1. 课程概述
1.1 什么是准入控制 Webhook
Kubernetes 准入控制（Admission Control）是 API Server 在处理资源请求（如创建 Pod、修改 Deployment）时，在对象持久化到 etcd 之前 执行的一组拦截与校验机制。准入控制分为两个阶段：
- Mutating（变更）阶段：通过 MutatingAdmissionWebhook 修改请求对象（如注入 Sidecar、设置默认值）。
- Validating（验证）阶段：通过 ValidatingAdmissionWebhook 校验对象是否符合策略（如检查镜像来源、禁止特权容器）。
准入控制 Webhook 是 Kubernetes 动态准入控制的核心扩展点。集群管理员可以注册外部 HTTPS 服务，API Server 在资源持久化前以 Webhook 回调 方式调用该服务，并根据返回的 allowed 字段决定是否放行请求。
关键特性： 准入 Webhook 在对象写入 etcd 之前执行，因此可以拦截非法配置、注入安全策略、记录审计日志，是集群安全与合规的“最后一道门”。
1.2 为什么需要检测存储版本漂移
Kubernetes 资源对象在 API Server 内部存在多个版本（如 v1、v1beta1、v1alpha1）。当集群升级或 API 版本废弃时，etcd 中存储的对象版本可能与当前 API Server 使用的首选版本（storage version）不一致，这种现象称为 存储版本漂移（Storage Version Drift）。
| 场景 | 风险 |
|---|---|
| 集群从 v1.20 升级到 v1.25，旧 CRD 版本被废弃 | etcd 中仍存在旧版本对象，API Server 无法正确反序列化 |
| 手动修改 etcd 数据或迁移工具不完整 | 对象字段丢失、类型转换错误，导致 Pod 启动失败 |
| 多个 API 版本共存，但 storage version 未统一 | 控制器或 Webhook 读取到不一致的版本，产生逻辑冲突 |
| 安全策略依赖特定字段（如 PodSecurityPolicy 迁移到 Pod Security Admission） | 旧版本对象绕过新策略检查，造成安全漏洞 |
通过准入控制 Webhook 检测存储版本漂移，可以在资源写入 etcd 前实时比对对象的 apiVersion 与集群当前 storage version，拒绝 或 转换 不匹配的请求，从而避免数据损坏、兼容性故障和安全盲区。
注意： 存储版本漂移是 Kubernetes 升级失败和 etcd 数据损坏的常见原因之一。官方建议在集群升级后立即执行
kubectl convert 或使用 storage-version-migrator 工具，但 Webhook 检测提供了更实时、更细粒度的防护。
1.3 课程目标与受众
课程目标
- 理解 Kubernetes 准入控制 Webhook 的工作原理与配置方法。
- 掌握存储版本漂移的成因、检测策略与修复手段。
- 能够编写并部署一个 ValidatingAdmissionWebhook，实时拦截存储版本不匹配的资源请求。
- 学会结合日志、监控和告警，构建版本漂移的持续检测体系。
目标受众
| 角色 | 前置知识 | 收益 |
|---|---|---|
| Kubernetes 集群管理员 | 熟悉 kubectl、YAML 配置、集群升级流程 | 掌握 Webhook 部署与版本漂移检测实战 |
| 平台 / SRE 工程师 | 了解 API Server 架构、etcd 存储 | 能够设计自动化漂移检测与修复流水线 |
| 安全架构师 | 熟悉 Kubernetes 安全基线、准入策略 | 将版本一致性纳入安全合规框架 |
| DevOps 工程师 | 有 Go / Python 开发经验 | 可以编写自定义 Webhook 服务 |
1.4 核心架构图：准入控制 Webhook 检测存储版本漂移
架构要点： 客户端请求到达 API Server 后，API Server 在将对象写入 etcd 之前，先调用注册的 ValidatingAdmissionWebhook。Webhook 服务内部的版本漂移检测模块比对对象版本与集群 storage version，若不一致则返回
allowed: false，API Server 拒绝该请求并返回错误给客户端。只有通过检测的请求才会被持久化到 etcd。