云原生混合架构 K8s 自动化部署平台先说结论这套平台解决的是业务既要跑在自有机房又要弹性扩展上公有云时的部署一致性问题。混合架构听起来高大上落到实际就是两套集群、一套流水线、统一的应用编排标准。我在接手这个项目前团队每次发版要手动改十几个配置文件跨环境迁移全靠复制粘贴出过不止一次测试没问题、生产一跑就挂的事故。这篇文章把我从零搭建这套云原生自动部署平台的完整过程、设计思路、踩过的坑都写下来希望能给正在做类似改造的团队一些参考。整个平台的核心是 K8s 加自动化部署但真正的难点不在会用 kubectl而在怎么让开发、测试、运维三方用同一套机制把应用安全、可控、可回滚地发布到不同环境。适合正在规划或正在实施容器化改造的运维、DevOps 工程师阅读也适合想了解企业级 K8s 平台落地全貌的技术负责人参考。1. 为什么做混合架构背景与核心痛点拆解1.1 混合架构到底解决什么问题所谓混合架构在我的项目里指的是自有物理机或虚拟化机房 公有云容器集群并存。之所以要这么搞不是跟风是业务场景倒逼的——核心交易类应用有合规要求必须留在自建机房而营销活动、大数据离线任务这类弹性波动大的负载放在公有云上可以按需扩容避免为峰值流量常年养着一批闲置机器。但混合架构带来一个直接的连锁反应环境变多了。原来一套测试、一套生产现在加上云上的一套甚至两套环境数量翻倍如果还靠人工去维护部署脚本那出错的概率也翻倍。我最开始接手时光部署脚本就散落在五六个 Git 仓库里有的是 Shell、有的是 Jenkinsfile、有的干脆是一段没人能说清来源的 Python 脚本。这种局面下K8s 的价值不只是容器编排它最大的贡献是抹平环境差异。不管底层是物理机还是云主机不管网络插件是 Calico 还是 CiliumK8s 提供的 API 是一致的。应用只需要面向 K8s 声明我要什么至于底下怎么调度、怎么分配资源那是集群的事。这正好是自动化部署平台能成立的根基——我只需要写一套部署模板用参数区分环境就能同时管好几套集群。1.2 原部署方式的问题清单改造前我梳理过现状问题非常典型列出来给大家对照看看自己团队有没有类似情况第一配置漂移严重。同一套应用测试环境用 docker-compose生产环境用手工写的 Deployment YAML两边资源配置、启动参数都不一样出现了测试环境好好的生产环境起不来的经典问题。第二发布过程不可审计。谁能发布、什么时候发布的、发布了哪个版本全靠聊天记录和口头沟通。第三回滚靠运气。出了线上问题最常见的操作是重新部署上一个镜像 Tag但上一个 Tag 在哪、对应哪次构建没人能立刻答上来。第四资源利用率低。自有机房的 GPU 和 CPU 资源分散在各项目组手里有的项目组配额用不完有的项目组在等机器审批缺一个统一的资源池管理机制。1.3 平台目标定义所以在动工之前我就把目标写得很清楚不是上一个 K8s 集群而是三条硬指标一套部署模板能同时应用于自建机房集群和公有云集群差异只体现在环境配置上。从代码提交到生产发布全流程无人干预但关键节点有人工审批审批要留痕。任何一次发布都能在 5 分钟内完整回滚到上一个稳定版本回滚过程同样自动执行。这三条目标看起来简单实际环环相扣第一条决定了平台的技术选型方向第二条决定了流水线工具链的集成深度第三条则直接逼着你把镜像版本管理和部署流程做规范。后续所有设计都是围绕这三条展开的。2. 整体设计与技术选型从工具到架构的取舍逻辑2.1 平台总体架构分层平台整体分成四层我分别说一下每层的职责和选型思路。第一层是基础设施层就是两套 K8s 集群。自有机房一套用的是裸金属服务器加 Ubuntu 系统公有云一套直接用云托管的 K8s 服务。这里有个关键决策没有自己再从零搭建云上集群因为托管服务把 etcd、控制面高可用、节点自动修复这些底层运维都包了能省下大量精力这些精力应该投入到业务交付上。第二层是部署编排层核心是 Helm 加 Kustomize。有人可能会问这俩不是重复的吗其实各有侧重。Helm 负责应用打包和版本管理把一套应用的 Deployment、Service、ConfigMap、Ingress 打成一个 Chart通过 values.yaml 区分环境Kustomize 负责对基础 YAML 做环境差异化覆盖适合处理那种不想引入 Chart 模板复杂度的场景。我在实践中的分工是标准化的业务应用走 Helm平台自身的组件和一次性任务走 Kustomize各用其所长。第三层是流水线层用 Jenkins 加 Argo CD。Jenkins 负责构建镜像、跑单元测试、生成制品清单Argo CD 负责把应用同步到 K8s 集群。这里我特意采用了CI 与 CD 分离的模式而不是让 Jenkins 一把梭直接执行 kubectl apply目的是把构建和发布两个操作彻底隔离。构建失败不影响线上发布动作由 Argo CD 声明式接管集群里的实际状态和 Git 仓库里的期望状态永远保持对比这叫 GitOps。第四层是入口与观测层。流量入口用 Ingress-Nginx 加 Metallb 分配外部 IP观测用 Prometheus 加 Grafana日志用 Loki 加 Promtail。这一层不直接参与部署但它决定了每次发布后你能不能第一时间发现问题。我见过太多平台部署挺顺利上线后靠用户投诉才发现服务挂了根因就是观测没跟上。2.2 CI/CD 工具链选型对比工具选型我做过一轮认真对比直接说结论和理由。Jenkins vs GitLab CI vs GitHub Actions团队代码托管在自建的 GitLabGitLab CI 其实也能做构建但我们的构建任务里有一些需要操作宿主机 Docker Socket 的场景Jenkins 的节点管理机制更成熟而且团队对 Jenkins 的插件生态更熟。GitHub Actions 不考虑因为代码不在 GitHub 上没必要为了 CI 把代码迁过去。Argo CD vs FluxCD两个都是 GitOps 工具我选了 Argo CD。原因有两点一是 Argo CD 的 UI 和 CLI 对手动触发同步这个操作的支持更直观团队在从手动部署到自动部署的过渡期需要这种半自动模式二是 Argo CD 的 Application 资源模型更适合管理多集群一套 Argo CD 实例可以同时对接自有机房和云上的两套集群这正好契合混合架构需求。Helm vs 裸 YAML这个没什么悬念必须用 Helm。裸 YAML 没法做模板化和版本管理一套应用在不同环境改几个参数就得复制一份文件维护成本直接爆炸。Helm Chart 的 values.yaml 机制天然支持环境差异化一条命令就能完成环境切换。2.3 声明式部署与 GitOps 到底是怎么运作的GitOps 的核心思想只一句话Git 仓库是集群状态的唯一事实来源。所有期望状态——应用版本、副本数、配置项——都以 YAML 文件形式存放在 Git 仓库里Argo CD 持续监听仓库变化一旦发现集群实际状态与仓库声明不一致就自动执行同步。这个机制天然带来了三个好处。第一回滚变得极其简单因为每一次变更都是 Git 的一次提交回滚就是把 Git 的 HEAD 指到上一次提交Argo CD 会自动把集群拉回旧状态第二权限管理可以直接复用 Git 的权限体系谁能改部署配置取决于谁有仓库的写权限不需要单独维护一套发布权限系统第三审计有迹可循任何一次变更都能查到提交人、提交时间和变更内容。但 GitOps 也有一个要提前想清楚的边界哪些配置属于应用期望状态哪些属于集群运行细节。比如副本数、镜像版本、环境变量这些属于前者必须进 Git而节点调度结果、Pod 实际 IP 这些属于后者不能进 Git否则 Argo CD 会一直认为集群处于漂移状态反复尝试修正造成无意义的同步操作。这个认知是团队在用了两周后才彻底理顺的一开始总有人把 kubectl get 的输出贴到仓库里。2.4 多集群管理的实践方案很多团队做混合架构时栽在两套集群各管各的上。我这边用 Argo CD 的多集群能力做了统一管理方案是这样的在自有机房部署一个 Argo CD 控制实例通过 kubeconfig 文件分别连接两套集群。在 Argo CD 里为每个集群创建一个 ApplicationSet用集群名称作为参数区分。同一个 Helm Chart在渲染 values.yaml 时注入不同的集群标识从而生成不同的副本数、存储类、Ingress 地址。这么做有个容易忽略的细节两套集群的 kubeconfig 权限范围要尽量收窄。Argo CD 用的 kubeconfig 只需要目标命名空间下的读写权限不要给 cluster-admin不然 Argo CD 的密钥泄露等于两套集群全都暴露。我这边遇到过公有云集群的临时凭证过期导致同步失败的问题后来改成使用长期有效的专用 ServiceAccount Token这个问题才彻底解决。3. 核心细节解析高可用、资源配额、GPU 调度这些硬骨头3.1 三台 Master 的高可用到底怎么搭自有机房这套集群我用 Kuboard 提供的 Kubekey 工具安装了标准的三 Master 高可用架构。三台 Master、三台 Worker控制面组件全部多副本etcd 集群由三节点组成。这里说一下为什么必须是三台而不是两台etcd 做分布式共识时两节点容错数为零任何一台挂了集群就失去法定人数三节点容错数是一可以允许一台宕机而不影响读写这是实际生产环境的最少节点数。安装时的关键参数主要是 API Server 的负载均衡地址。我选用了 Keepalived 加 HAProxy 来暴露 Kubernetes API虚拟 IP 绑在 HAProxy 上HAProxy 后挂三个 Master 的 6443 端口。这里有个经验Kubekey 安装时填的 apiserver 地址必须是这个虚拟 IP而不是其中一个 Master 的 IP否则 Worker 节点连接 API 时会绕过负载均衡某个 Master 挂了就会导致一部分节点失联。安装完成后我做了破坏性测试直接 shutdown 一台 Master验证了集群依然可以正常调度、etcd 数据不丢再把节点拉起来自动加入集群整个过程业务无感知。这个测试很值得做它能提前暴露很多高可用配置上的隐藏问题比如证书 SAN 里没包含虚拟 IP 导致 kubelet 无法认证这类只能在故障时暴露的坑。3.2 资源配额与 GPU 调度机制项目里涉及大量 AI 推理和训练任务GPU 管理是刚性需求。团队最初是手工排 GPU 卡的使用时段后来人数多了根本排不过来经常出现卡闲着一大半、人在群里抢进度的怪现象。我把 GPU 管理纳入了 K8s 的调度体系节点上的 GPU 由设备插件注册成可分配资源配合节点级资源配额和命名空间级 ResourceQuota 做双重控制。命名空间配额设置的思路是每个业务团队一个命名空间给它设定 CPU、内存、GPU 卡的硬上限。比如算法团队分配 8 张 GPU 卡一旦提交的任务累计申请超过 8 张新的 Pod 就会处于 Pending 状态直到有任务释放资源。配合 nodeSelector 把 GPU 任务调度到带 GPU 的节点池普通业务不会被挤到 GPU 节点上浪费资源。这里面有个容易踩的坑K8s 早期版本对 GPU 设备插件支持不完善nvidia-device-plugin 与容器运行时版本不匹配会导致 GPU 无法被发现。我这边排查过一起节点显示有 GPU但 Pod 里 nvidia-smi 找不到卡的问题最后定位是 DaemonSet 的 Pod 没跑在新的 GPU 节点上原因居然是用来给 DaemonSet 打标签的 nodeAffinity 表达式写错了。所以在规划 GPU 调度时设备和节点标签的一致性检查一定要纳入自动化流程不能靠人工核。3.3 镜像仓库与制品管理的关键决策自动化部署平台有个不成文的规矩镜像 Tag 必须是不可变的。最简单可靠的做法是用 Git 提交哈希作为镜像 Tag。每次代码合并到主干CI 流水线自动构建镜像Tag 就是 commit SHA例如 registry.internal/app-service:7f3a2b9c。这样任何一次发布都能精确追溯到对应的代码版本回滚时只需把 Tag 切回上一个 commit SHA 对应的镜像。镜像仓库我选用了 Harbor它对多租户和镜像清理的支持比裸 Docker Registry 强太多。一开始图省事用 Docker Registry结果镜像越堆越多磁盘很快被打满删除镜像还要手动调 API。Harbor 有配额管理和定时清理策略按保留最近 N 个版本自动清掉旧的一个月能省下不少存储成本。这里还要提一个和自动化部署平台强相关的小设计镜像拉取凭证。K8s 里拉私有仓库镜像需要配置 imagePullSecret最省事的办法是在每个命名空间默认创建一个 Secret再用 admission webhook 自动注入到新 Pod 里。但要注意镜像仓库的凭证是长期有效的高敏感信息我这边已经切换到用短期 Token 加定期轮换的方案配合 Vault 做凭证管理虽然初期接入麻烦一些但安全收益是实打实的。3.4 监控告警选型与配置要点Prometheus 加 Grafana 是当前 K8s 监控的事实标准我用 kube-prometheus-stack Helm Chart 一次性部署了 Prometheus、Alertmanager、Grafana 以及各类 exporter。部署流程很简单但监控真正值钱的部分是告警规则。我梳理了几条最核心的告警规则按优先级排是Pod 反复重启重启次数超过阈值、节点 NotReady、PVC 使用率超过 85%、API Server 延迟异常、镜像仓库磁盘空间不足。每条规则都配置了对应的告警渠道通过 Alertmanager 路由到企业微信机器人。这里有个细节告警一定要配置 grouping 和 inhibition不然某个节点挂了会导致上面几十个 Pod 同时触发告警告警轰炸会把真正的问题淹没。我刚开始没做分组节点宕机那晚收到了两百多条消息第二天起来光是排查告警就把人累垮了。另外在部署 Prometheus 监控线上应用时注意每个命名空间的 ServiceMonitor 标签选择器要写准确我遇到过因为写错 namespaceSelector 导致整个集群所有 Service 都被抓取Prometheus 内存直接被打爆的惨案。4. 实操过程与核心环节实现4.1 环境准备与版本选型明细在开始之前先把版本确定下来这是很多团队忽略的一开始省事、后期加倍还债的环节。我这边统一采用 K8s 1.29 系列Docker 使用 24.0 版本容器运行时用 ContainerdK8s 从 1.24 起默认不再直接支持 Docker 作为运行时但镜像还是 Docker 格式通过 Containerd 的 cri 插件对接。操作系统统一用 Ubuntu 22.04 LTS内核 5.15这套组合在稳定性上有充分验证。网络组件选 Calico两个原因一是它支持 BGP 模式适合自建机房对接现有物理网络二是它的网络策略能力成熟可以为不同命名空间设置精细的访问控制。云上集群用云厂商默认的 VPC-CNI网络插件不同没关系因为我们不在集群间做直接网络互通跨集群通信统一走 Ingress 或消息队列这有效避免了混合架构里最头疼的网络打通问题。4.2 流水线的完整配置与实现Jenkins 流水线我用 Jenkinsfile 声明式写法阶段划分是Checkout、单元测试、镜像构建与推送、生成部署清单、触发 Argo CD 同步。其中最核心的一段构建逻辑是动态生成 Helm values 文件核心思路是按环境读取不同配置stage(Render Helm Values) { steps { script { def envConfig ${WORKSPACE}/deploy/values-${TARGET_ENV}.yaml sh helm template app-service \ --namespace ${NAMESPACE} \ --values ${envConfig} \ --set image.tag${GIT_COMMIT} \ --set replicaCount${REPLICAS} /tmp/rendered.yaml } } }这段脚本表达的思想是环境差异全部收敛在 values 文件里流水线本身不关心环境是什么。TARGET_ENV 参数区分 test、staging、productionREPLICAS 参数在 Jenkins 构建参数里配置这样同一个 job 可以服务所有环境。Argo CD 侧的配置也很关键。每个应用对应一个 Application 资源spec.source.path 指向 Git 仓库里的 Helm Chart 目录spec.destination 指向目标集群和目标命名空间spec.syncPolicy 设置为 automated 加 selfHeal。但我不建议纯 automated 模式因为一旦 Git 仓库被误提交集群立刻就会跟着变更比较危险。我的做法是 automated 加 prune 但关闭 selfHeal发布动作由 CI 流水线最后一步显式调用 argocd app sync而不是依赖 Argo CD 自动检测。4.3 灰度发布与流量切分灰度发布是自动化部署平台能安全上线的重要保障。我用 Argo Rollouts 实现了金丝雀发布它和 Argo CD 同属 Argo 生态集成起来很顺。Argo Rollouts 通过 Rollout 资源替代 Deployment 管理 Pod 副本配合 Service 的 stable 和 canary 两个版本权重动态调整流量比例。发布新版本时先创建一个 canary 副本数为 1 的版本然后通过分析器检查新版本的 HTTP 错误率和响应延迟指标正常就把 canary 权重从 5% 逐步升到 50% 再到 100%全程自动无需人工干预。这套机制要生效前置条件是应用本身必须支持多版本同时运行。所以灰度发布不只是配置的事它倒逼应用改造数据库迁移要兼容新旧版本共存缓存 key 要避免不同版本互相污染消息队列消费逻辑要保证两个版本同时消费时不会重复处理。我跟开发团队强调过多次灰度发布工具是放大器应用不支持灰度工具再好也白搭。4.4 Ingress 和外部 IP 的配置实践自有机房集群没有云厂商的负载均衡器需要自己解决外部流量入口。我用 Metallb 提供 LoadBalancer 类型的 Service 支持把一段物理网络 IP 段交给 Metallb 管理Ingress-Nginx 的 Service 声明为 LoadBalancer 类型后Metallb 会自动分配一个外部 IP。这里有一个当时卡了很久的细节Ingress-Nginx 默认情况下会监听所有网络接口拿到外部 IP 后需要确认转发规则正确。我在配置 externalIPs 或者使用 Metallb 分配的 IP 时遇到过一次外部访问通、集群内部访问不通的问题定位后发现是 CoreDNS 的域名解析里设置了强制走 Ingress 外部 IP而 Ingress 本身又是通过集群内 Service 访问的形成了解析环路。解决思路是区分外部域名和内部域名内部服务之间直接通过 Service 名称访问不要绕 Ingress。5. 常见问题与排查技巧实录5.1 高频问题速查表这一节我把平台落地过程中最常遇到的问题整理成表都是真实踩过的按出现频率排序问题现象可能原因排查与解决Pod 一直 Pending资源配额不足或节点亲和性不满足kubectl describe pod 看 Events确认是 CPU 还是 GPU 不足镜像拉取失败 ImagePullBackOffimagePullSecret 缺失或镜像仓库凭证过期检查 Secret 是否存在手动 docker login 测试凭证有效性Argo CD 同步超时集群 kubeconfig 指向错误或网络不通在 Argo CD 容器里手动执行 kubectl get nodes 验证连通性Helm 渲染时报错找不到 values流水线的工作目录不对确认构建产物路径使用 workspace 的绝对路径引用发布后服务 503新版本启动失败或就绪探针配置过严查看滚动更新事件调整 initialDelaySeconds节点 NotReady 但机器正常kubelet 证书过期或负载过高检查 kubelet 日志重启 kubelet 并确认证书轮换磁盘空间持续增长镜像和日志堆积未清理配置 Harbor 清理策略容器日志限制 max-size这个表建议直接贴到团队的运维手册里它节省的排查时间远比想象的多。5.2 典型案例复盘一次错误的镜像 Tag 引发的线上故障有一次生产发布出了严重事故新版本上线后业务报错率飙升我立即触发回滚结果回滚后还是报错。后来排查发现回滚时指向的镜像 Tag 是 latest而这个 latest 已经被刚才那次错误的构建覆盖了也就是说回滚实际上是重新部署了同一个坏版本。这就是我前面强调镜像 Tag 必须用 commit SHA 的原因。换成 commit SHA 后回滚就是把 values 里的 image.tag 改回上一个 commit SHA镜像在仓库里是不可变的永远不可能被覆盖。我还额外加了一层保护通过 Harbor 的镜像不可变规则对 production 命名空间下的镜像禁止覆盖同一个 Tag从仓库层面就杜绝了这类问题。这次事故给我最大的教训是自动化部署平台把发布变快了同时也把错误变快了。因此所有防呆设计必须前置在平台层面而不是依赖人的细心。5.3 关于稳定性的三条独家建议第一个建议控制面组件和业务负载分开部署在节点池。通过 taint 和 toleration让控制面组件只跑在 Master 节点业务 Pod 只跑在 Worker 节点。这样即使某个业务 Pod 占满节点资源也不会影响 API Server 和 etcd 的稳定性。第二个建议etcd 一定要定期做备份并把备份文件放到集群之外的存储。etcd 是 K8s 集群的数据库一旦数据损坏整个集群的期望状态全部丢失所有 Deployment、Service、ConfigMap 都可能无法恢复。我这边用 etcd-backup CronJob 每小时备份一次保留最近 24 小时恢复演练也做过确认备份可以直接拉起一个新集群。第三个建议变更运维操作时要先评审、后执行、留快照。尤其是升级 K8s 版本、修改 Calico 配置这类操作影响范围是全局性的。我每次做这类操作前都会给关键资源打一份 YAML 快照存到 Git 仓库里即使升级失败也能快速把配置还原到操作前的状态。这个小习惯已经帮我至少避免了两次大事故。说实话搭建这套自动化部署平台的过程远没有想象中顺利。中间经历了 GPU 设备插件识别不到、Argo CD 同步风暴、灰度发布时旧版本连接池不释放导致新版本流量被拖垮等一系列问题。但正是这些问题的解决过程让平台从能跑变成了稳。我个人最深的体会是自动化部署平台的成功标准不是上线速度有多快而是出问题时恢复的速度有多快、出问题的概率有多低。把防呆机制、可观测性、回滚能力这三件事做扎实平台就是成功的这三件事没做再快的流水线也只是在加速制造事故。
