读 CNCF 的地图 — 成熟度、交付、服务网格
一句话总结
CNCF Landscape 中数百个 logo 不是需要背诵的对象。按它们位于解决哪类问题的位置分组， 即使出现新项目，也能找到它所属的位置。成熟度阶段则是社区对该项目现在是否适合用于生产的信号。
为什么需要它
Kubernetes 是刻意保持不完整的。网络交给 CNI，运行时交给 CRI，存储交给 CSI。 如果本体包办一切，不但无法维护，还会与特定实现绑定。
代价是选择的负担。从“选哪种 CNI”到“选哪个策略引擎”，需要作出许多决定。 CNCF 是为这个生态提供中立管理与成熟度信号的基金会。
它如何运作
项目成熟度的三个阶段
| 阶段 | 含义 | 示例 |
|---|---|---|
| Sandbox | 实验性。面向早期采用者。API 可能发生破坏性变更 | 新项目 |
| Incubating | 已有多个生产使用案例，committer 也更加多元 | （随时间变化） |
| Graduated | 成熟。已具备安全审计、治理和多元贡献者 | Kubernetes、Prometheus、Envoy、containerd、etcd、Argo、OPA |
阶段不代表功能优劣，而是治理和采用的成熟度。Sandbox 不表示性能差， Graduated 也不表示一定适合我们的情况。但它可以作为“使用期间项目会不会消失”的风险信号。
扩展接口——Kubernetes 如何调用外部实现
- CRI——容器运行时（containerd、CRI-O）
- CNI——网络（Cilium、Calico、Flannel）
- CSI——存储（各类 driver）
- CRD + 控制器——用户扩展 API 本身的方式
最后一项尤其重要。Operator 模式是“用 CRD 定义新的资源类型， 再附加监视该资源的控制器，把领域知识变成代码”。也就是把 Kubernetes 的 reconciliation loop 复用于自己的问题。
交付——CI、CD 与 GitOps
CI 是“每次提交都构建和测试”，CD 是“自动部署构建结果”。 GitOps 又把 CD 反转了一次。
- 不由 pipeline 推入集群（push），
- 而由集群中的 agent 持续观察 Git repository，并自行缩小差异（pull）。
Git repository 就是期望状态，agent 像控制器一样进行 reconcile。 准确地说，这是把 Kubernetes 的声明式模型扩展到组织流程。 由此获得的是可审计性（提交日志记录谁在何时更改了什么）、drift 检测 （即使有人手动修改，也会恢复原状）和回滚（还原 commit）。Argo CD 与 Flux 是代表性实现。
Service Mesh
它源于这样的需求：不修改应用代码，也能加入重试、timeout、mTLS、流量切分和请求级观测。 传统实现会为每个 Pod 附加代理（sidecar），让所有流量都通过它。
代价也很明确：每个 Pod 都增加一个代理，内存和延迟随之增加，还多出一个需要运维的组件。 因此最近出现了不使用 sidecar，而在节点级代理或 eBPF 中完成相同工作的趋势，例如 ambient 模式。
开放标准
- OpenTelemetry(OTel)——采集并传输 trace、metric、log 的厂商中立规范与 SDK。 完成一次 instrumentation 后，即使更换 backend 也无需修改代码。
- OpenMetrics——对 Prometheus 暴露格式进行标准化。
- SPIFFE/SPIRE——向 workload 签发加密身份（SVID）的规范， 用来替代“IP 地址就是身份”的陈旧假设。它也是 Service Mesh mTLS 所依赖的基础。
在实际工作中会遇到的情况
作者家庭实验室的平台栈，以实物形式呈现了这张地图： 网络是 Cilium 1.20（eBPF、无 kube-proxy），L4 load balancer 是 MetalLB（地址池 10.0.0.200-215）， 存储是 csi-driver-nfs + NAS，GitOps 是 ArgoCD，registry 是 Harbor，观测采用 kube-prometheus-stack， DB 是 CloudNativePG（PostgreSQL 18、双实例 streaming replication），虚拟化使用 KubeVirt v1.9.0。 核心在于：每个位置插入一个组件。按位置阅读 Landscape，便能如此整理。
版本兼容的咬合点也在实际中出现过。使用 Cilium Gateway API 时，
需要 Gateway API CRD v1.6.1。在 v1.2 中，tlsroutes 与 referencegrants 还不是 v1，
导致控制器直接拒绝启动。“CRD 也有 API 版本，版本不匹配时控制器无法启动”，
这就是扩展模型的现实。
最令人印象深刻的教训来自 KubeVirt。所有组件状态均为 AllComponentsReady，VM 却无法启动。
拆开 virt-launcher Pod spec 后，发现缺少包含 init container 所需可执行文件的 volume mount。
照作者的原话来说：“状态为 Ready”与“实际能够运行”是两个不同命题。
这已经是同一集群第三次确认这个事实，也是对“为什么 observability 不能止于一个状态字段”最简短的解释。
接下来阅读什么
本模块没有实验。后续读物会整理 observability signal，最后通过测验结束课程。