1. 课程导论：云原生安全基线概念、冷启动场景定义、Kyverno在安全基线中的角色
1.1 云原生安全基线：从“合规检查”到“运行时护栏”
云原生安全基线不是一份静态的 PDF 文档，而是一组可编程、可观测、可自动执行的安全准入规则集合。它定义了容器、Pod、Namespace 在创建或更新时必须满足的最低安全条件，例如：
- 禁止特权容器：
securityContext.privileged: true直接拒绝。 - 强制只读根文件系统：
readOnlyRootFilesystem: true。 - 限制 Linux Capabilities：仅允许
NET_BIND_SERVICE等必要能力。 - 禁止 hostNetwork / hostPID / hostIPC：防止逃逸。
- 强制 ImagePullPolicy：避免本地缓存恶意镜像。
在 Kubernetes 集群中，安全基线通常通过 Admission Webhook 实现。Kyverno 作为 CNCF 毕业项目，是当前最主流的策略引擎之一，它用 Kubernetes 原生的 ClusterPolicy 资源来描述基线规则。
关键认知： 安全基线不是“一次性扫描”，而是“每次资源创建/更新时的强制校验”。这种校验的延迟直接决定了集群的冷启动速度。
1.2 冷启动场景定义：为什么“第一次”最慢？
冷启动（Cold Start）在云原生安全上下文中特指：集群从零开始启动，或大规模扩缩后，Kyverno 首次加载并评估大量安全基线策略的过程。典型场景包括：
| 场景 | 触发条件 | 瓶颈特征 |
|---|---|---|
| 集群新建 | kubeadm / EKS / AKS 创建后首次部署 | Kyverno Pod 启动慢，Webhook 注册延迟 |
| 大规模扩缩 | 从 10 节点扩至 500 节点 | 策略缓存未预热，并发评估队列积压 |
| 策略批量更新 | 一次性应用 50+ 条 ClusterPolicy | Webhook 重新加载，规则编译耗时剧增 |
| 灾备恢复 | 从备份恢复 etcd 后重启集群 | 所有资源重新触发准入检查 |
冷启动的核心矛盾在于：安全基线策略越多、越复杂，Kyverno 的首次评估延迟就越长。在生产环境中，这种延迟可能导致 Pod 创建超时、Deployment 滚动更新卡住、甚至集群控制面过载。
常见误区： 很多人认为冷启动只影响“第一次”，但实际上，每次 Kyverno Pod 重启、Leader 选举切换、策略热更新都会触发部分冷启动。在 Serverless 或 Fargate 等弹性场景中，冷启动可能频繁发生。
1.3 Kyverno 在安全基线中的角色：策略引擎 + 准入控制器
Kyverno 在云原生安全基线架构中承担三个核心角色：
- 策略定义者：通过
ClusterPolicy/Policy资源描述安全基线规则，支持validate、mutate、generate三种动作。 - 准入控制器：作为
ValidatingWebhookConfiguration和MutatingWebhookConfiguration注册到 API Server，拦截所有匹配的资源请求。 - 策略执行者：在 Webhook 回调中执行规则匹配、JSON 校验、补丁生成，并返回
allowed: true/false给 API Server。
下图展示了 Kyverno 在安全基线冷启动过程中的完整链路：
1.4 冷启动瓶颈的典型表现
当安全基线策略数量超过 30 条，或策略中包含复杂的 context 调用（如 APICall、ConfigMap 引用）时，冷启动阶段会出现以下可观测现象：
- Pod 创建延迟：从
kubectl run到 Pod 进入Running状态的时间从 2s 飙升到 15s+。 - Webhook 超时：API Server 日志中出现
context deadline exceeded错误。 - Kyverno 内存飙升：策略编译阶段 RSS 从 200MB 涨至 1.5GB+。
- Leader 选举抖动：冷启动期间 Kyverno 多个副本频繁切换 Leader。
课程预告： 在后续章节中，我们将深入分析 Kyverno 策略缓存的内部实现（LRU + TTL）、规则编译的 Goroutine 模型、以及 Webhook 超时重试机制。你将学会如何通过
--admissionControllerThreads、--backgroundScanInterval 等参数调优冷启动性能。
1.5 本章小结
云原生安全基线是 Kubernetes 集群的第一道防线，Kyverno 是执行这道防线的核心引擎。冷启动场景下，策略加载、缓存预热、规则编译三个环节最容易成为瓶颈。理解这些瓶颈的成因，是后续进行性能诊断和调优的前提。