知识花园

最近更新

云原生与平台工程 MOC

31分钟阅读

云原生与平台工程

一台服务器，一个 sysadmin，一份 runbook。这是二十年前软件运营的基本单元。

现在呢？一个互联网服务可能有数百个微服务，跑在数千个容器里，分布在多个可用区，每天有数十次变更被推上生产——而负责运维的团队规模可能比服务数量少一个数量级。

传统运维的核心动作是”登录机器，执行命令，修改配置，验证状态”。这套方式的问题不是慢，是无法重复：同样的操作在第二台机器上的结果可能不同，因为这台机器有不同的历史——不同的人在不同时间做过不同的修改，没人记得清楚。配置漂移（configuration drift）不是事故，是时间的必然结果。

云原生的回答是：把”我做过什么”变成”系统应该是什么状态”。

这是声明式范式的核心转变。Dockerfile 声明环境，Kubernetes YAML 声明期望状态，Terraform 声明基础设施，GitOps 让 Git commit 成为运行时的真相之源。每个工具解决的具体问题不同，但底层哲学一致：描述意图，让系统自己收敛。

这个系列分两个层次：

核心技术（01-04）：那些已经成为行业基础设施的技术——容器打包、Kubernetes 编排、IaC 代码化、GitOps 声明式交付。理解它们不只是为了用，是为了理解”为什么这样设计，不这样设计会怎样”。

演进范式（05-08）：当云原生工具链本身变得足够复杂时，社区的下一个回答是什么——Platform Engineering 把平台当产品来建，eBPF 把策略下沉到内核，服务网格让流量治理从代码中解脱，Serverless 把无状态化推向极致。

一、目录

本系列共 8 篇文章，分两层：核心技术（01-04）建立基础认知，演进范式（05-08）探索前沿方向。

60-platform/
├── 00-platform-MOC.md                                         ← 本文件
│
├── 10-containers/                                             # 核心技术（60%）
│   └── 01-容器：隔离是手段，交付是目的.md                    ← namespace / cgroups / OCI 标准
│
├── 20-kubernetes/
│   └── 02-Kubernetes：声明意图，控制器维持世界.md             ← 控制循环 / 声明式 API / 调度器
│
├── 30-iac/
│   └── 03-IaC：把基础设施变成可版本化的意图.md               ← Terraform / Ansible / 状态漂移
│
├── 40-gitops/
│   └── 04-GitOps：Git 成为系统运行时的真相之源.md            ← pull 模型 / operator / ArgoCD
│
└── 50-new-paradigms/                                          # 演进范式（40%）
    ├── 05-平台工程：把开发者体验当产品来建.md                 ← IDP / 黄金路径 / Backstage
    ├── 06-eBPF：内核变成可编程的基础设施.md                   ← verifier / Maps / Cilium / Tetragon
    ├── 07-服务网格：流量治理从应用代码中解脱.md               ← Istio / Ambient Mesh / mTLS
    └── 08-Serverless：无状态化的收益与代价.md                 ← FaaS / 冷启动 / Knative / WASM

二、概念线索

这是整套系列的核心：8 篇文章里反复出现的五条思想脉络。 读懂这五条线索，就抓住了云原生设计哲学的骨架。

mindmap
  root((云原生))
    核心技术
      容器 隔离与交付标准
      Kubernetes 声明式编排
      IaC 基础设施代码化
      GitOps Git成为运行时真相
    演进范式
      平台工程 开发者体验即产品
      eBPF 内核可编程化
      服务网格 流量治理解耦
      Serverless 无状态极致抽象
    共同主题
      声明式收敛
      控制面与数据面分离
      不可变基础设施
      可编程内核
      抽象的代价

线索一：「声明式收敛」——描述意图，让系统持续维持

命令式：依次执行这些步骤。声明式：这是系统应该处于的状态，你去实现并持续维持它。两者的区别不只是语法，是关于谁承担复杂性。

  • Dockerfile（01-容器：隔离是手段，交付是目的）：不描述”如何搭建环境”，描述”环境应该是什么”——FROM 指定起点，每一层指令声明需要的变更，镜像构建过程是幂等的。
  • Kubernetes reconciliation loop（02-Kubernetes：声明意图，控制器维持世界）：你提交 YAML 声明期望状态（“我要 3 个副本”），控制器持续观察现实状态，发现偏差就采取行动——pod 崩溃了，控制器重建它；节点下线了，控制器重新调度。“自愈”不是魔法，是收敛循环在运行。
  • Terraform plan/apply（03-IaC：把基础设施变成可版本化的意图）：先 plan 计算当前状态与期望状态的 diff，再 apply 执行变更。State 文件是当前现实的镜像；任何漂移都会在下一次 plan 中被发现。
  • GitOps operator（04-GitOps：Git 成为系统运行时的真相之源）：ArgoCD / Flux 持续 watch Git 仓库，一旦仓库状态与集群状态不一致，operator 主动拉取并 sync——集群无法”独立”于 Git 之外演进。
  • Platform golden paths（05-平台工程：把开发者体验当产品来建）：开发者声明”我需要一个带数据库的 Python 服务”，Platform 自动配置好 Kubernetes 工作负载、Service Account、数据库连接、Secret 注入——意图声明，平台实现。

这条线索的终点：声明式的真正价值不是”代码更简洁”，是可审计、可重现、可自愈。声明即文档，文档即运行时。

线索二：「控制平面与数据平面」——分离决策与执行

一个系统如果把”做什么决策”和”执行决策”混在一起，扩展会变得困难。分离控制平面和数据平面，让两者可以独立演进、独立伸缩。

  • Kubernetes 的分离（02-Kubernetes：声明意图，控制器维持世界）：API Server + etcd + Controller Manager 是控制平面，存储期望状态、运行控制循环；kubelet + kube-proxy + 容器运行时是数据平面，在节点上执行实际工作。两者通过 watch/list API 解耦——控制平面挂了，已运行的 pod 不受影响。
  • 服务网格的分离（07-服务网格：流量治理从应用代码中解脱）：Istiod 是控制平面，管理证书、分发路由规则、收集遥测元数据；Envoy sidecar（或 ztunnel）是数据平面，实际处理每一个 TCP 包。控制平面负责”什么规则”，数据平面负责”每包执行”。
  • eBPF 的角色（06-eBPF：内核变成可编程的基础设施）：eBPF 程序是数据平面——在内核路径上高速执行；用户空间的 loader 和控制逻辑是控制平面——编译、验证、加载 eBPF 字节码，更新 Maps。Cilium 用这个模式替换了 kube-proxy：控制平面计算路由，eBPF 数据平面执行包转发。
  • IDP 作为元控制平面（05-平台工程：把开发者体验当产品来建）：Internal Developer Platform 是所有工程工具的控制平面——它不直接运行工作负载，而是协调 Kubernetes、数据库、CI/CD、Secret 管理等工具，对开发者暴露统一的意图接口。

这条线索的终点：控制平面和数据平面的分离是所有大规模分布式系统的架构共识——决策逻辑集中、执行逻辑下推。理解这个结构，就理解了为什么 K8s 可以管理数千个节点，为什么服务网格可以做到零代码侵入。

线索三：「不可变基础设施」——替换而不是修改

宠物（pets）与牛群（cattle）的比喻：宠物病了你要治好它，牛生病了你换一头新的。不可变基础设施是把所有服务器和容器都当成牛群来运营的系统性做法。

  • 容器镜像的不可变层（01-容器：隔离是手段，交付是目的）：镜像是只读的内容寻址对象——一旦构建，内容不变，hash 不变，任何机器上拉取到的是完全相同的东西。你不”修改”运行中的容器，你重建镜像、重新部署。
  • Kubernetes 的 rolling update（02-Kubernetes：声明意图，控制器维持世界）：更新不是 SSH 进每个 pod 修改配置，是提交新的 Deployment spec，控制器滚动替换——新 pod 起来通过 readiness probe，旧 pod 逐步销毁。
  • IaC 的 replace 策略（03-IaC：把基础设施变成可版本化的意图）：理想状态下，更新基础设施等于重建它——用新 AMI 重新创建 EC2 实例，而不是登录旧实例打补丁。配置漂移的解法不是检测后修复，是用声明状态重建。
  • GitOps 的回滚语义（04-GitOps：Git 成为系统运行时的真相之源）：回滚不是”撤销操作”，是 git revert——用旧的声明状态替换现在的声明状态，operator 执行 sync。每次变更都有完整的 diff 和责任人。

这条线索的终点：不可变基础设施把”调试运行中的系统”变成”重建系统”。代价是需要强大的构建和部署流水线；收益是不再有隐性的历史状态，也不再有”我以为和之前一样”的事故。

线索四：「可编程内核」——策略下沉到基础设施

传统上，网络策略、访问控制、可观测性逻辑写在应用代码里，或者配置在用户空间的 iptables / 代理里。eBPF 打开了第三个选项：把这些逻辑安全地注入到内核路径上。

  • eBPF 的本质（06-eBPF：内核变成可编程的基础设施）：eBPF 是内核里的沙箱虚拟机——你写一小段 C，编译成 eBPF 字节码，verifier 在加载时证明它不会崩溃内核，然后挂载到内核路径上的钩子点（socket、tracepoint、kprobe、XDP……）执行。数据在内核里就被处理，不需要复制到用户空间。
  • Cilium 替换 kube-proxy（06-eBPF：内核变成可编程的基础设施 / 02-Kubernetes：声明意图，控制器维持世界）：kube-proxy 用 iptables 规则做 Service 的负载均衡——规则数量随 Service 数量线性增长，到数万条时性能下降明显。Cilium 用 eBPF Maps 存储路由表，每次包查找是 O(1) 的哈希查找，完全绕过 iptables。
  • 服务网格的 Ambient 模式（07-服务网格：流量治理从应用代码中解脱）：Sidecar 模式给每个 pod 注入 Envoy 代理，有资源开销也有 pod 数量倍增的复杂性。Istio Ambient 用每节点的 ztunnel 处理 L4 流量，eBPF 负责重定向——零 sidecar，但保留流量治理能力。eBPF 让数据平面从用户空间迁移回内核。
  • Tetragon 的内核安全策略（06-eBPF：内核变成可编程的基础设施）：传统 Linux 安全是 POSIX 权限 + seccomp 白名单。Tetragon 在内核层用 eBPF 追踪进程行为——哪个进程读了哪个文件，哪个进程建立了哪个网络连接——实时、精确、零误报，且策略违反可以在内核层直接终止进程。

这条线索的终点：eBPF 是过去十年 Linux 内核最重要的架构变化。它不只是一个工具，是一个平台——可观测性、网络、安全三个领域都在向 eBPF 收敛。理解 eBPF，就理解了云原生下一个五年的底层趋势。

线索五：「抽象的代价」——每一层便利都有税

每增加一层抽象，你获得便利，也支付代价。云原生的技术栈已经叠了好几层——理解每层的代价，才能做出正确的选择。

  • 容器 vs VM（01-容器：隔离是手段，交付是目的）：容器比 VM 轻，但共享内核——一个内核漏洞可能影响同机所有容器（容器逃逸）。镜像体积和扫描、Registry 管理、Layer 缓存失效是新的运营负担。
  • Kubernetes 的复杂性税（02-Kubernetes：声明意图，控制器维持世界）：K8s 解决了调度、自愈、滚动更新——但带来了 etcd、API server、scheduler、controller manager、CNI、CSI、CRI 的运维复杂性。“我只是想跑一个应用”的开发者面对的是数百个 YAML 字段。这就是 Platform Engineering 出现的根本原因。
  • 服务网格的延迟与资源税（07-服务网格：流量治理从应用代码中解脱）：Sidecar 模式给每个请求增加两次用户空间→内核往返（iptables redirect + Envoy 处理）；每个 pod 多一个容器占资源；mTLS 握手有 CPU 开销。收益是零代码侵入的可观测性和流量控制——是否值得，取决于团队规模和流量模式。
  • Serverless 的控制权交换（08-Serverless：无状态化的收益与代价）：你不管理任何基础设施，代价是你也无法控制运行时——冷启动延迟、并发限制、执行时长上限、网络拓扑约束。每一项”不用管”背后，是云厂商替你做了决定，你只是不知道。
  • Platform Engineering 的制度成本（05-平台工程：把开发者体验当产品来建）：IDP 降低了应用开发者的认知负担，但谁来维护 IDP？黄金路径降低了自由度——如果你的需求超出了路径的边界，你会撞上更高的墙。平台化是以制度成本换取规模效率的取舍。

这条线索的终点：选择云原生技术栈不是”用了就更好”，是在不同维度的复杂性之间做权衡——把复杂性从运行时转移到构建时，从应用代码转移到基础设施，从个人技能转移到平台制度。每一次转移都有它的隐性成本。

三、核心系列（01-04）

云原生的四块基石——理解它们不只是为了使用，是为了理解”不这样设计会怎样”。

起点：容器——隔离与交付

核心问题：容器和虚拟机的根本区别是什么？Docker 解决的到底是运行问题还是分发问题？ 读完之后：理解 namespace / cgroups / OCI 镜像格式，理解”隔离是手段，可重复交付才是目的”。

第一层：编排——Kubernetes 的设计哲学

核心问题：Kubernetes 的”声明式”和”控制循环”分别意味着什么？etcd 为什么是整个集群的单一真相？ 读完之后：理解 desired state / observed state / reconciliation，理解 K8s 为什么”最终一致”而不是”事务性”。

第二层：代码化——基础设施的版本控制

核心问题：IaC 解决的是”可重现”还是”可审计”？Terraform state 文件存在的意义是什么？幂等性为什么是 IaC 工具的核心要求？ 读完之后：理解声明式 IaC（Terraform）vs 命令式 IaC（Ansible）的根本差异，理解配置漂移的根因和防治。

第三层：声明式交付——GitOps

核心问题：GitOps 和”把部署脚本放在 Git 里”有什么区别？Pull 模型和 Push 模型分别在什么场景下更合适？ 读完之后：理解 Git 作为 desired state store 的语义，理解 operator 模式（watch → diff → act）与 CI/CD pipeline 的根本区别。

四、演进系列（05-08）

当云原生工具链本身变成了复杂度的来源，社区的下一步是什么。

平台层：开发者体验

核心问题：Platform Engineering 和 DevOps 的区别是什么？“黄金路径”（golden path）的边界在哪里？为什么说 IDP 是云原生复杂性税的解药？ 读完之后：理解 Internal Developer Platform 的设计原则，理解 Backstage / Crossplane 等工具在 IDP 里扮演什么角色，理解平台团队和应用团队的职责边界。

内核层：eBPF

核心问题：eBPF 和 kernel module 有什么区别？verifier 的本质是什么？为什么说 eBPF 统一了可观测性、网络、安全三个领域？ 读完之后：理解 eBPF 程序的生命周期（编译→验证→加载→挂载），理解 Maps 作为内核/用户空间通信机制，理解 Cilium / Tetragon 在 K8s 里解决了什么问题。

网格层：服务网格演进

核心问题：服务网格的本质是什么——是代理技术还是控制平面技术？Sidecar 模式和 Ambient 模式各自的哲学取舍是什么？mTLS 到底在解决哪个问题？ 读完之后：理解 service mesh 的控制平面 / 数据平面架构，理解 sidecar 模式的固有代价，理解 Ambient 模式如何用 eBPF + ztunnel 重新分层，理解为什么 WASM 是 Envoy 扩展的方向。

无服务层：Serverless 的哲学

核心问题：Serverless 和容器化的根本区别不是”不用管服务器”——而是什么？冷启动为什么是 Serverless 的架构约束，而不只是性能问题？Knative 和 AWS Lambda 的设计差异说明了什么？ 读完之后：理解 Serverless 的执行模型（event-driven、stateless、ephemeral），理解状态外置的必然性，理解边缘计算和 WASM 如何在 Serverless 的方向上继续演进。

五、按场景的阅读路径

不同目的的人，从不同的地方开始。

路径一：第一次系统学云原生

按核心系列的逻辑顺序，每篇建立在前一篇的基础上：

01（容器：为什么需要容器，它解决什么问题）
  → 02（Kubernetes：容器多了怎么编排）
  → 03（IaC：基础设施也要代码化）
  → 04（GitOps：代码化之后如何交付）
  → 05（Platform Engineering：工具链复杂了怎么办）

路径二：DevOps / SRE 工程师

关注声明式交付和可观测性：

01（容器打包机制，理解镜像层和运行时）
  → 02（K8s 控制循环，理解自愈和滚动更新）
  → 04（GitOps，建立声明式交付流水线）
  → 03（IaC，把基础设施变更也纳入 GitOps）
  → 06（eBPF，深入可观测性工具链）

路径三：平台工程师 / 架构师

关注平台设计和技术选型：

02（K8s 控制平面深入理解）
  → 05（Platform Engineering：IDP 设计原则）
  → 07（服务网格：流量治理方案选型）
  → 06（eBPF：数据平面的演进方向）
  → 08（Serverless：工作负载类型光谱）

路径四：应用开发者（理解底层）

关注”我的代码跑在什么上面”：

01（容器化：我的 Dockerfile 里发生了什么）
  → 02（K8s：我的 pod 是怎么被调度和管理的）
  → 08（Serverless：什么时候用，代价是什么）
  → 05（Platform Engineering：平台给我提供了什么，边界在哪里）

路径五：关注安全方向

01（容器安全基础：namespace 隔离的边界）
  → 06（eBPF：内核层安全策略，Tetragon）
  → 07（服务网格：mTLS 和零信任网络）
  → 02（K8s RBAC 和 Pod Security）

六、延伸方向

这个系列聚焦于云原生和平台工程的核心概念。以下方向与本系列相关，但各自构成独立的学习领域：

  • 可观测性工程：Prometheus、Grafana、OpenTelemetry 的完整栈——建立在第 06 篇（eBPF）的基础上，见 可观测性与运维工程 MOC。

  • 云安全与供应链：容器镜像签名（Cosign/Sigstore）、SBOM、策略即代码（OPA/Kyverno）——建立在第 01、02 篇的基础上，见 安全工程 MOC。

  • 分布式系统理论：一致性模型（etcd 背后的 Raft 协议）、CAP 定理在 K8s 里的体现——见 软件工程与架构 MOC。

  • 网络深入：CNI 插件原理、BGP 在 K8s 里的使用（Calico/Cilium BGP）、云厂商网络的底层——建立在第 06 篇（eBPF）和 计算机网络 MOC 的基础上。

  • 虚拟化基础：容器的 namespace/cgroups 来自 Linux 内核，更底层的 Hypervisor 隔离见 虚拟化系统 MOC。

  • 多集群与混合云：Cluster Federation、Karmada、多集群 GitOps——是第 02、04 篇的规模化延伸，但涉及大量工程权衡，独立成专题更合适。

关系图谱

反向链接