1. 课程导论：服务目录平台概念、运行基线核验的重要性、Kyverno 策略引擎简介
1.1 服务目录平台：云原生时代的服务“黄页”
在微服务架构与云原生生态中，一个组织通常会运行成百上千个微服务。服务目录平台（Service Catalog Platform）应运而生，它充当了所有服务的“注册中心”与“元数据仓库”，提供服务的发现、治理、依赖关系可视化以及生命周期管理能力。
一个成熟的服务目录平台通常包含以下核心能力：
| 能力维度 | 说明 | 典型实现 |
|---|---|---|
| 服务注册与发现 | 服务启动时自动注册，消费者通过目录查找目标服务端点 | Kubernetes Service / CoreDNS |
| 元数据管理 | 维护服务名称、版本、Owner、SLA、标签、依赖关系 | 自定义 CRD + 标签注解 |
| 健康与合规状态 | 展示服务运行状态、策略合规评分、安全基线达标情况 | Prometheus + Kyverno 报告 |
| 访问控制与审批 | 控制谁可以注册、修改、下线服务 | RBAC + OPA/Gatekeeper |
| 拓扑与依赖可视化 | 自动生成服务调用关系图，辅助故障定位 | Kiali / 自研图谱 |
关键认知： 服务目录平台不仅仅是“服务列表”，它是运维治理、安全合规、成本优化在云原生环境中的统一数据底座。没有目录，基线核验就失去了可观测的载体。
1.2 运行基线核验：为什么是“必须做”的事？
运行基线（Runtime Baseline）是指一个服务在生产环境中安全、稳定运行所必须满足的一组最低配置与行为约束。基线核验（Baseline Verification）就是持续检查服务是否偏离了这些约束。
基线核验的重要性体现在三个层面：
- 安全层面： 防止容器以 root 运行、禁止特权提升、强制只读根文件系统、限制网络策略。
- 稳定性层面： 确保资源请求/限制合理、存活探针配置正确、反亲和性规则生效。
- 合规层面： 满足内部审计要求（如标签必须包含 Owner 和 CostCenter）、外部监管要求（如 PCI-DSS、SOC2）。
行业数据： 根据 CNCF 2024 年调查，超过 60% 的生产环境安全事件源于基线配置漂移。手动核验已无法应对每天数百次的部署变更。
基线核验的典型流程如下：
- 定义基线： 将安全与运维规范转化为可执行的策略规则。
- 持续校验： 在服务部署、更新、运行阶段自动触发检查。
- 告警与阻断： 对不合规服务发出告警，或直接拒绝变更（强制模式）。
- 审计与报告： 生成合规报告，供安全团队和审计方查阅。
1.3 Kyverno 策略引擎：Kubernetes 原生的策略执行者
Kyverno 是一个为 Kubernetes 设计的策略引擎，由 Nirmata 开源，目前是 CNCF 毕业项目。与 OPA/Gatekeeper 不同，Kyverno 使用 Kubernetes 自定义资源（CRD）来定义策略，无需学习专用的策略语言（如 Rego）。
Kyverno 的核心特性包括：
| 特性 | 描述 | 优势 |
|---|---|---|
| Kubernetes 原生 | 策略使用 YAML 定义，与 Kubernetes 资源模型一致 | 学习成本低，运维人员可直接上手 |
| 多种策略类型 | 支持 Validate（校验）、Mutate（变更）、Generate（生成） | 覆盖准入控制、配置注入、资源自动创建 |
| 集群与资源范围 | 可作用于整个集群、特定命名空间或特定资源类型 | 粒度灵活，适配不同管控场景 |
| 策略报告 | 自动生成 PolicyReport 和 ClusterPolicyReport | 审计友好，可直接对接服务目录平台 |
| 无需 Sidecar | 以 Admission Webhook 和后台扫描方式运行 | 对业务 Pod 无侵入 |
注意： 虽然 Kyverno 策略用 YAML 编写，但复杂逻辑（如跨资源校验、正则匹配）仍需一定的学习曲线。本课程后续章节会逐步拆解常见模式。
1.4 三者协同：从策略到基线再到目录
本课程的核心逻辑是：Kyverno 策略引擎 作为执行层，将安全与运维规范转化为可编程策略；运行基线核验 作为检查层，持续验证服务是否符合策略；服务目录平台 作为展示与治理层，聚合所有服务的合规状态，提供全局视图。