3.1 云原生与容器化开源项目
3.1 云原生与容器化开源项目
本节摘要：Kubernetes 在 2026 年已经不是"要不要用"的问题，而是"怎么用好"的问题。本节梳理云原生核心项目的最新状态——从容器运行时（containerd）到编排（K8s），从服务网格（Istio/Linkerd）到可观测性（Prometheus/Grafana），再到平台工程（Backstage）的兴起。
本节导航
阅读完本节，你应当能够：
- 说出 Kubernetes 生态在 2026 年的核心演进方向
- 对比 Istio 和 Linkerd 的适用场景
- 理解平台工程（Platform Engineering）解决什么问题
- 选择合适的可观测性工具组合
一、问题与直觉
五年前，公司的技术决策是"要不要上 Kubernetes"。今天，决策变成了"Kubernetes 集群太多了，怎么管"。
一个中型公司可能有 5-10 个 K8s 集群，分布在不同的云和区域。每个集群需要配置、升级、监控、安全策略。开发者需要创建新服务时，要写 Deployment、Service、Ingress、ConfigMap、Secret……一堆 YAML。
云原生在 2026 年的核心矛盾是：基础设施能力已经足够，但开发者体验跟不上。
二、核心原理
容器运行时：containerd 成为默认
Docker 在 2019 年从 Kubernetes 中移除了 dockershim，containerd 成为 K8s 的默认容器运行时。2026 年，containerd 已经是生产环境的事实标准。Docker Desktop 仍然在开发者本地使用，但生产环境几乎都是 containerd。
| 运行时 | 定位 | 特点 |
|---|---|---|
| containerd | K8s 默认 | 轻量、稳定、CNCF 毕业项目 |
| CRI-O | Red Hat 系 | OpenShift 默认，与 Podman 配合 |
| gVisor | 安全沙箱 | Google 出品，应用内核隔离 |
| Kata Containers | 安全虚拟机 | 轻量 VM 级别的隔离 |
服务网格：从"要不要用"到"选哪个"
| 维度 | Istio | Linkerd |
|---|---|---|
| 复杂度 | 高（功能全但配置复杂） | 低（开箱即用） |
| 性能 | 默认 Envoy sidecar，资源占用较高 | 微代理设计，更轻量 |
| 功能 | mTLS、流量管理、可观测性、策略 | mTLS、基础流量管理、可观测性 |
| 适合 | 大型企业、多集群、需要高级流量策略 | 中小团队、追求简单 |
💡 关键直觉：如果你的团队没有专职的平台工程师，选 Linkerd。Istio 的功能强大但运维成本高，没有专人维护容易变成技术债。
可观测性：Prometheus + Grafana + OpenTelemetry
2026 年可观测性的三件套已经稳定：Prometheus 采集指标、Grafana 可视化、OpenTelemetry 统一 Trace/Metric/Log 的采集标准。
OpenTelemetry（OTel）是近年最重要的变化。在它之前，每个可观测性厂商都有自己的 SDK（Datadog Agent、Jaeger Client、Zipkin Library）。OTel 统一了这些接口，让你可以无感切换后端。
平台工程：Backstage 的兴起
平台工程是 2025-2026 年的热词。核心思想：给开发者一个自助式门户，让他们自己创建服务、查看文档、管理配置，而不是每次都要找运维。
Spotify 开源的 Backstage 是这个领域的代表项目。它提供了一个插件化的开发者门户框架，可以集成 CI/CD 状态、API 文档、基础设施目录、模板创建等功能。
三、工程实践要点
2026 年云原生选型建议
| 场景 | 推荐组合 |
|---|---|
| 标准 K8s 部署 | containerd + Helm + Argo CD |
| 需要服务网格 | 小团队用 Linkerd，大团队用 Istio |
| 可观测性 | OpenTelemetry + Prometheus + Grafana |
| 开发者门户 | Backstage + 自定义插件 |
| 多云管理 | Crossplane + Terraform |
⚠️ 常见坑：不要同时引入太多 CNCF 项目。Kubernetes 生态有超过 600 个项目，每个都有学习成本。从核心需求出发，按需引入。
K8s 周边必知项目清单
Kubernetes 本身只解决"容器编排"，真正让集群可用的是一圈配套项目。下面按职责列一份高频清单，方便对照自己的技术栈缺口：
| 职责 | 代表项目 | 解决的问题 |
|---|---|---|
| 应用打包 | Helm | 把一组 YAML 打包成可复用的 Chart |
| 配置覆盖 | Kustomize | 不改 Chart 就能按环境覆盖配置 |
| 水平伸缩 | HPA / KEDA | 按 CPU 或业务指标自动扩缩 |
| 发布策略 | Argo Rollouts | 金丝雀、蓝绿发布 |
| 网络插件 | Cilium / Calico | 集群内网络与网络策略 |
| 流量入口 | Gateway API / Ingress | 外部流量接入集群 |
| 存储 | Longhorn / Rook | 分布式块存储与对象存储 |
| 备份恢复 | Velero | 集群与应用级备份 |
| 策略执行 | Kyverno / OPA | 资源合规检查 |
| 多集群 | Karmada / OCM | 统一管理多个集群 |
很多团队在"缺什么装什么"的过程中把集群变成了动物园。建议先画一张自己真实的调用链，只装链上需要的组件，其余项目知道"它是干什么的"就够了。
CNI 与网络模型
容器网络是新手最容易踩坑的地方。Kubernetes 的网络模型要求每个 Pod 都有独立 IP、Pod 之间直接互通，这个模型由 CNI 插件实现。Flannel 简单但只有 Overlay 网络，Calico 支持 BGP 直连加网络策略，Cilium 基于 eBPF 在性能和安全上更强，还自带可观测能力。选型不是越新越好：小集群用 Flannel 或 Calico 足够，大规模、强安全要求、要细粒度策略的再上 Cilium。换 CNI 意味着全集群网络重建，这是上线后很难回头的决定，务必在测试环境先验证。
存储：应用数据不能只靠本地盘
无状态应用好部署，有状态应用才是真问题。常见路径有三种：云厂商托管盘（性能稳定、成本高）、自建分布式存储（Longhorn 基于 RDS 的思路做副本，Rook 管理 Ceph 提供块和对象存储）、以及交给云外的存储服务。数据库这类对延迟敏感的应用，优先托管盘；日志、备份这类吞吐型数据，用对象存储；测试环境的临时数据，EmptyDir 就够了。存储选型直接决定故障恢复时间，生产环境务必配置快照和定期备份。
集群升级与运维的坑
Kubernetes 的维护成本集中在上线之后。升级是最大风险点：跨小版本升级还好，跨大版本往往伴随 API 变更，老资源对象可能在新版本被移除。建议的节奏是小版本及时跟、大版本先看变更清单、升级前在测试集群跑一遍兼容性检查。etcd 是集群的大脑，备份和恢复演练要定期做，否则一次坏盘就能让整个集群瘫痪。控制面组件（kube-apiserver、controller-manager）的证书轮换、资源配额、命名空间治理，都是"平时看不见、出事才想起"的环节。
流量治理：Ingress 之外的 Gateway API
服务网格不是唯一做流量的方式。2026 年另一个值得关注的变化是 Gateway API 逐渐取代传统 Ingress：它把流量治理拆成网关类、路由类、策略类三组资源，比 Ingress 的单一注解体系更结构化，还统一了南北向与东西向的管理体验。如果你的团队不需要服务网格的完整能力（mTLS、熔断、灰度），先用 Gateway API 加一款 CNI 就覆盖了绝大多数场景，等复杂度真的上来了再评估 Istio 这类重型方案。
一节小结
- containerd 是生产标准：Docker 留给本地开发，生产用 containerd
- 服务网格选型看团队：小团队 Linkerd，大团队 Istio
- OpenTelemetry 统一了可观测性：不再被厂商 SDK 锁定
- 平台工程解决开发者体验：Backstage 是代表，但不是唯一选择
- 克制引入项目的冲动：CNCF 景观图很诱人，但每个项目都有运维成本
云原生基础设施搭好了，下一节看怎么在它之上构建自动化的 DevOps 流水线。