K8s 上的平台工程说人话：IDP 是什么、Golden Path 怎么搭、你到底需不需要
图：有无平台的两种开发者——左边自己搞定十二件套，右边只面对模板（图解：原文）
平台工程（platform engineering）是当下基础设施圈搜索量最高、也最被误解的词：厂商卖”盒装内部开发者平台”，大会演讲说它会取代 DevOps，而圈内一半人私下觉得它只是”换了个好看 logo 的 Kubernetes”。一篇来自一线平台工程师的 2026 长文把话说明白：不是。剥掉营销词，它是一个具体、有用的概念，而且在 Kubernetes 上有清晰的形状。
它到底是什么
平台工程 = 把自己的内部开发者平台（IDP）当产品来做，客户就是你自己的开发者。 平台团队按产品逻辑运营它：有用户、有反馈、有路线图，成功指标是开发者采用率，不是 Terraform 行数。
核心机制是 Golden Path（也叫 paved road，铺好的路）：给高频任务——新建服务、加数据库、上生产——修一条有主张的端到端通道，默认动作就是”正确动作”。让”顺手的方式”同时是”安全、合规、可观测的方式”。
它解决什么问题：认知负载
在现代云原生基础设施上发布一个服务，开发者被隐性要求懂：Kubernetes、Helm 或 Kustomize、Ingress 和网络模型、Terraform 之类的 IaC、CI/CD、密钥管理、一堆安全控制——这还没开始写业务代码。这就是认知负载，而且它不可扩展：每个新团队要么全部重学一遍，要么抄上一个团队半懂不懂的配置。平台把这份负载吸走，开发者面对一个干净的自助界面，下面十二件工具归平台管。
不是 DevOps 2.0，也不是换名的 SRE
| DevOps | SRE | 平台工程 | |
|---|---|---|---|
| 是什么 | 一种文化与实践 | 可靠性工程学科 | 把 IDP 当产品来建 |
| 核心思想 | 打破开发与运维的墙 | SLO 与错误预算 | Golden Path 与规模化自助 |
| 拥有 | 团队协作方式 | 可用性、救火、事故响应 | 开发者平台及其用户体验 |
| 何时失效 | 每个团队都得精通运维 | 被当成运维的别称 | 为建而建、没人采用 |
| 一句话 | 目标 | 保证可靠 | 让前两者规模化的产品 |
三者是互补层：DevOps 是目标，SRE 让它可靠，平台工程是让大组织不必每个团队重复造轮子的那件产品。三样都要。
Kubernetes 上的 IDP 长什么样
图：IDP 分层栈——从云基础设施到开发者门户（图解：原文）
从上到下五层：云基础设施（计算/网络/存储底座）→ 基础设施自动化（Terraform/OpenTofu 负责开资源，Ansible 配置 Pod 之外的世界，上面套一层带策略的编排）→ 编排与配置（Kubernetes 控制面，Crossplane 把基础设施做成 API，Helm/Kustomize 做模板）→ 持续交付（GitOps，Argo CD，以 Git 为事实源持续 reconcile）→ 自助界面（开发者真正碰到的部分：Backstage 门户、服务模板即 Golden Path、平台 CLI/API）。
两层横贯全部、不可选做：护栏（Kyverno/OPA Gatekeeper 策略即代码、RBAC、安全控制，让铺好的路自动合规）和可观测性（每个服务出生即带指标日志链路——OpenTelemetry 自动注入）。层次要紧的原则只有一条：开发者只看最顶层，下面全是平台的事。
集群之下的自动化层：最容易漏 toil 的地方
多数平台架构图从 Kubernetes 画起，真实平台不是：Argo CD 部署任何东西之前，得有人先把 VPC、IAM、托管数据库——包括集群本身——建出来；集群外围还有一堆永远不进 Pod 的东西：堡垒机、构建 VM、遗留服务、设备、OS 加固、监控 agent。2026 年这一层几乎总是两个工具：
- – Terraform 或 OpenTofu 负责开资源：声明式、有状态、先 plan 后 apply。OpenTofu 是 Linux 基金会旗下开源分支（2023 年 HashiCorp 转 BSL 之后分叉），基本 drop-in 兼容，还带来了客户端状态加密等自有特性——选谁主要是许可与治理问题，不是语法问题。
- – Ansible 负责配置：过程式、无 agent，管 VM、OS 加固、agent 下发、网络设备——一切”VM 启动之后、Kubernetes 之外”的东西。
- – Crossplane 的定位：适合运行中集群内的应用级资源（”给我的服务一个桶和一个数据库”），但它创建不了它所运行的那个集群——常规分工是 IaC 管地基，Crossplane 管开发者面资源。
两个工具都没错，错在接线方式：Terraform 跑在一条 CI 流水线，Ansible 在另一条（或 AWX、或某人的笔记本），inventory 靠脚本传——症状可预测：没有端到端视图（一个逻辑变更活在两个系统里，没人能说清是否整体成功）；两条审计线（安全团队在两处分别审 plan 和 run，审计员看到两个故事）；顺序靠约定（Ansible 在 provisioning 没完成时启动）；静默漂移（控制台热改后无人知晓，直到下次 apply 试图改回去）；自助退化成工单。作者称之为”平台工程失败的缩影：Golden Path 在上面，toil 在下面”。
解法不是换掉工具，而是在 Git 和两个工具之间放一层编排，让它们作为同一个受治理的工作流跑：
图：Terraform + Ansible 并进同一个受治理工作流（图解：原文）
要点：每个 PR 出 plan、只从主干 apply、危险变更走审批、加锁防撞；对 plan 做策略检查（比如拒绝 public bucket、要求标签、删库需要第二审批人）；上游输出自动喂给下游、顺序正确；定时 plan 查漂移；带 RBAC 的自助触发；一条审计线。落地选项四档（作者的中立对比）：小体量+CI 强，自建流水线加 conftest 就很好；PR 驱动且要自托管看 Atlantis；纯 Terraform 看 HCP Terraform；Terraform/OpenTofu 与 Ansible 混合、要在同一工作流里跑的，看 Spacelift（唯一原生双栈的，作者在文中有赞助段，结论仍给了”按栈数量、团队数量和工具数决定要不要上专用编排器”）。
你到底需不需要一个平台
图：”你到底需不需要平台”决策树（图解：原文）
作者在这节的标题是”诚实最重要”，因为建了平台没人用是基础设施里最贵的错误之一：小团队、几个服务？不需要——好模板+一份扎实的 README+一条干净的 CI，胜过你没人力维护的定制平台。多个团队反复重解同样的基础设施问题、认知负载确实在拖慢交付、且规模养得起平台团队？平台开始回本。
判断标准是被证明的、反复出现的痛点，不是潮流：说不出平台消除的具体 toil、说不出第一天就会采用的团队，你就是在为技术而技术。
小夏点评
- 1. 这篇的价值在”划界”：DevOps 是文化、SRE 是可靠性学科、平台工程是产品，三者占不同的坑，缺谁都不行——但国内很多团队的”搞平台工程”实际只等于部署了 Backstage，正好落进对照表里”为建而建、没人采用”那一格。
- 2. IaC 编排一节写的是真实生活：一次变更 Terraform 一半、Ansible 一半，两条审计线、顺序靠约定、静默漂移——这些症状在国内大厂内部平台上多数已经在发生，作者给的”一层编排+统一审计线”方向可以直接抄作业。
- 3. 对国内 IT 运维/开发者的启示：国内有个倒挂现象——团队规模不大、服务数量不多，却都在”搞平台工程”。这篇给的恰好是反方向的建议：服务不到十个、平台组就一两个人，好模板加 README 胜过定制平台；先说出要消除的重复 toil 和第一批采用团队，再谈预算。另外”小团队不需要平台”不是失败，是诚实的成本控制——这个判断框架本身比任何工具选型都值钱。
参考链接
- – 原文（Aleksei Leinikov，2026-10-03 更新）：https://www.alekseialeinikov.com/en/blog/topics/devops/platform-engineering-on-kubernetes-2026
- – 延伸阅读（原文推荐）：Argo CD GitOps 篇 https://www.alekseialeinikov.com/en/blog/topics/gitops/argocd-gitops-2026 ；OpenTofu vs Terraform 篇 https://www.alekseialeinikov.com/en/blog/topics/devops/opentofu-vs-terraform-2026
