「服务都搬上 Kubernetes 了还有必要再上 DevOps 平台吗」——这句话几乎每个容器化团队都问过而它难答是因为一开始就被问错了方向。DevOps 平台和云原生以 Kubernetes 为代表根本不是同一层的东西谈不上二选一DevOps 平台管的是变更怎么被安全地送到集群——评审、构建、制品、审批、审计每一步都能对上账Kubernetes 管的是应用在集群里怎么跑——调度、弹性、自愈它从不回答「这次是谁改的、该不该上、出事了回滚到哪个版本」。真正容易漏的是夹在中间的第三层镜像与 manifest 怎么晋级进集群制品库 发布/GitOps 控制器。所以这篇文章不打算把 DevOps 平台、云原生、Kubernetes、GitOps 四个词各科普一遍——公开定义到处都是。它只回答一个具体问题已经上了 K8s 的团队到底还缺什么、按什么顺序补。路径很直接先认清三层再看三种集成模式最后用一张 K8s 场景 PoC 表收口。一、先分清两层问题外加一道「桥」1.1 云原生 ≠ 只有 Kubernetes云原生是一套架构与工程方法论容器化、微服务、声明式基础设施、持续交付与可观测等。中国信通院《云原生 新一代软件架构的变革》等公开材料中亦将持续交付、DevOps 实践纳入云原生技术谱系——因此「云原生 vs DevOps 平台」不是同一维度的对立而是层次回答什么典型对象缺失时常见症状交付管控层DevOps 平台变更如何从代码安全、可追溯地进入环境代码、MR、流水线、制品、发布审批、审计发布靠人、制品对不上、无法回滚到确定版本运行底座层云原生运行时工作负载在集群内如何调度、弹性、自愈Pod、Deployment、Service、HPA、网络与存储资源浪费、扩缩容慢、故障域不清晰衔接层制品 发布/GitOps构建产物如何晋级到测试/预发/生产集群镜像仓库、Helm Chart、GitOps 仓库、发布控制器测试与生产镜像不一致集群状态与审批脱节读法「两个都要」指的是交付层 运行层缺一不可若已有 K8s还要明确第三层由谁承担——是 DevOps 平台内置发布还是GitOpsArgo CD、Flux 等同步 manifest或二者组合。1.2 DevOps 平台与「纯运行时工具」边界维度DevOps 平台云原生运行时K8s 等核心问题变更如何评审、构建、纳管、审批上线应用如何在集群中运行与扩展管理对象代码、流水线、制品、发布记录容器、工作负载、集群资源典型组件托管/评审、CI/CD、制品库、门禁、效能数据Kubernetes、容器运行时、服务网格可选不负责的事不替代集群调度与节点资源规划不替代 MR 评审、制品晋级策略、跨环境审批二、上 K8s 之后为什么仍需要交付管控层微服务化后交付单元从1 个变成几十个镜像 tag、环境、Helm revision 组合爆炸。若出现下列信号说明容器化已完成交付链路仍断镜像构建完没有统一制品库测试与生产拉到的 digest 不一致。发布靠 kubectl / 脚本手工执行无审批、无记录、无法审计。回滚靠人工翻历史 tag对不上代码提交与需求单号。开发 / 测试 / 预发 / 生产没有统一流水线与质量门禁只有集群在跑。Google Cloud DORA 团队在其能力模型中将持续集成、持续交付、部署自动化等列为影响交付表现的核心能力——上了容器不等于这些能力自动具备仍需要平台化的链路承接。三、集成模式平台与 K8s 怎么「叠」在一起企业真正纠结的往往不是「要不要两个」而是变更如何进集群。常见三种模式可组合非互斥模式链路概要更常见团队注意点A. 平台驱动发布CI 构建镜像 → 写入制品库 →平台审批后调用 K8s API/Agent 部署希望发布与审计在同一系统须 PoC 多环境晋级与 RBACB. GitOps 声明式CI 构建镜像 → 更新 Git 中 manifest →Argo CD/Flux同步集群强 Git 治理、多集群审批可在 Git PR 或平台侧重C. 平台 GitOps 组合平台管构建、制品、门禁GitOps 管集群期望状态中大型、多集群需约定谁改镜像 tag、谁合并 manifest举例GitLab/GitHub Actions 常走 A 或 BGitFox等一体化平台可在 A/C 中承担构建、制品与审批再对接 K8s 或 GitOps仅有 Jenkins kubectl往往缺制品晋级与审计是第二节四类信号的温床。选型时先画清贵司走 A、B 还是 C再选具体产品——比先争论「要不要 DevOps 平台」更省时间。四、先做云原生还是先上 DevOps 平台按断点选路径没有固定先后顺序看断点在哪现状建议主线优先验证工具链割裂、发布靠人工、尚未容器化先统一交付链路代码→制品→发布一条流水线完成构建、扫描、制品、至少到测试环境已容器化、K8s 在跑、发布不受控先补衔接层 审批回滚制品库纳管镜像/Helm发布走审批选定 A/B/C 模式强合规、私有化、审计要求高交付平台私有化 全链路留痕审计导出、离线可用、与 PM/需求 ID 关联以 PoC 为准五、落地顺序四步 K8s 场景 PoC5.1 四步推进画现状链路代码仓库、CI、制品库、发布方式含是否 kubectl、K8s 集群——标出人肉环节。选一个可独立发布的微服务试点构建镜像 → 入库 → 部署到测试集群。固定集成模式第三节 A/B/C串起扫描、测试、制品晋级与上线审批再推广预发/生产。用 DORA 四类指标观察变化部署频率、变更前置时间、变更失败率、恢复时间——先统一口径再谈优化。5.2 PoC Pass / FailK8s 交付平台检查项PassFail制品关联镜像 digest 自动入库且关联 commit/MR及需求 ID若已集成 PM测试/生产镜像来源靠人工告知发布管控部署到 K8s非默认 kubectl 私活有审批或等价门禁任何人可 kubectl apply无记录回滚可回到指定历史制品版本并留痕回滚靠猜 tag 或手工改 YAML审计一次查询能看到「谁、何时、何版本、进哪环境」信息散落在 CI 日志与聊天试点未过Fail任一行不宜扩大集群内服务数量。六、常见问题FAQQ1上了 Kubernetes 还需要 DevOps 平台吗需要交付管控层K8s 不能替代。集群管运行与调度评审、构建、制品晋级、发布审批与审计属于交付链路。容器化程度越高越需要平台或规范化的 GitOps CI把变更如何进集群管起来。Q2DevOps 平台和云原生有什么区别云原生是架构与工程方法论含容器、微服务、持续交付、可观测等DevOps 平台是承载代码→制品→发布的工具体系。Kubernetes是云原生运行时底座的代表与 DevOps 平台不同层通过制品库与 GitOps/发布流程衔接。Q3GitOps 和 DevOps 平台是什么关系GitOps 是变更进入集群的一种实现方式声明式、以 Git 为真源常由 Argo CD/Flux 执行DevOps 平台通常负责构建镜像、质量门禁、制品库与审批。二者可组合平台产出制品并更新 manifestGitOps 负责集群同步——不是二选一。Q4落地顺序怎么排看断点不看口号。发布靠人、工具割裂 → 先统一交付链路K8s 已有但发布失控 → 先补制品、审批、回滚与集成模式第三节。均从小服务试点开始用第五节 PoC 表收口。选型收口DevOps 平台与云原生不是二选一运行底座K8s 等决定应用跑得多稳、扩得多快交付管控DevOps 平台 制品/GitOps 衔接决定每次变更能否可控、可追溯地到达集群。对企业而言更稳妥的路径是画清断点 → 选定集成模式 A/B/C → 小服务 PoC 通过 → 再扩面。是否引入具体产品以第五节 PoC 与团队现状为准而非「上了 K8s 就万事大吉」。功能、部署与集成范围以各产品官网及 PoC 结果为准。参考公开资料中国信通院云原生相关白皮书Google Cloud DORA 团队 《State of DevOps》 及能力模型公开材料。