读 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，最后通过测验结束课程。