先看全局。整套平台部署在公有云 VPC 内承载 500 个线上项目的构建和部署核心组件分布在三条逻辑链路上外部集群侧配置侧代码与制品侧推送镜像 Chart更新环境配置轮询 同步部署 健康检查管控对外暴露部署事件同步状态GitLab代码仓库 CI RunnerHarbor镜像仓库 OCI Chart 制品库GitOps 配置仓库应用定义 环境 ValuesArgoCD集群内同步 AgentArgo Rollouts渐进式交付Kubernetes 集群3 节点池 / 4 命名空间DNS / CDN飞书通知设计核心CI 系统不接触集群。这条约束是整个架构的安全基石。CI 只管产出制品镜像和 Chart、更新 GitOps 配置仓库不持有任何集群凭据。集群内的 ArgoCD 自主拉取配置并同步。安全边界清晰——即使 CI 系统被攻破攻击者也拿不到集群控制权。二、网络拓扑四条隔离边界网络设计是云上安全的第一道防线事后改的成本极高。我们划了四条隔离边界VPC公网基础服务K8s 节点池公网接入层内网拉镜像内网拉镜像出公网出公网用户流量开发者SLB 负载均衡NAT 网关生产节点池测试节点池HarborGitLab边界一Worker 节点不绑公网 IP。出网走 NAT 统一出口入网只走 SLB。节点对公网完全不可见。边界二镜像仓库和 GitLab 在同一 VPC。Runner 也在 VPC 内。构建、推送、拉取全链路走内网不产生公网流量费用。边界三SLB 是唯一的公网入口。SSL 终结在 SLB 层SLB 做七层转发到 Ingress。不把证书分散到各个应用上管理。边界四凭据不出集群。这是个容易被忽略但极其重要的设计点。Harbor 密码、GitOps 仓库 Token、飞书 Webhook Secret全部通过 GitLab CI 变量注入CI 运行时以环境变量形式存在于 Runner Pod 内不写入配置文件、不进入 Git 历史。ArgoCD 侧的集群凭据由 Kubernetes Secret 管理通过 Sealed Secrets 加密后存入 GitOps 仓库——Git 里的密文是可版本化的但只有集群内的 controller 能解密。镜像仓库的拉取凭据同理通过imagePullSecrets注入应用开发者不需要知道 Harbor 密码。不展开讲工具细节核心原则一句话凭据的明文只存在于运行时内存和集群内部 Secret 中任何持久化存储Git、日志、制品里只允许出现密文或引用。三、交付链路为什么拆成两条流水线这是全文最重要的架构决策值得单独一节。K8s 集群ArgoCDGitOps 配置仓库HarborGitLab CI开发者K8s 集群ArgoCDGitOps 配置仓库HarborGitLab CI开发者ArgoCD 每 3 分钟轮询git push编译 测试 镜像构建推送镜像 Helm Chart渲染环境 Valuesgit commit push通知构建完成git pulldiff 期望状态 vs 实际状态同步差异通知部署完成如果把镜像推送和集群部署写在同一个 pipeline 里构建完直接kubectl apply等于把集群写权限捆绑在 CI 系统上。一旦 CI 被攻破——Runner 镜像有漏洞、开发者脚本注入了恶意命令、某个 CI 变量泄露——攻击者就能直接操控集群。拆成两条线之后构建线左侧CI 只做编译、镜像打包、Values 渲染、Git push。这条线不需要任何集群凭据甚至不知道集群地址。同步线右侧ArgoCD 在集群内部持续对比 Git 仓库和实际状态有集群写权限但完全不暴露给外部系统。额外收益部署和构建解耦后回滚变得极其简单。回滚就是git revert推送到 GitOps 仓库ArgoCD 自动同步回集群。运维不需要 kubectl 权限在 GitLab 界面点一下 rollback pipeline 按钮就完成。从半夜爬起来敲命令变成了手机上点个按钮。代价3 分钟的轮询延迟。ArgoCD 默认每 3 分钟拉一次 Git这意味着从 CI 推送配置到集群实际变更最多有 3 分钟的空白期。对于绝大多数业务场景这个延迟可以接受。如果对延迟敏感可以缩短轮询间隔或者用 webhook 触发——两者都支持我们保守地用轮询先稳再快。四、平台自举ArgoCD 自己怎么部署GitOps 架构中有一个经典问题ArgoCD 管理所有业务应用那 ArgoCD 自己怎么管理我们的做法分两层集群基础组件ArgoCD、Traefik、Prometheus、Sealed Secrets Controller 等不走 GitOps 自举循环——它们由 Helm 手动安装到kube-system和专用命名空间配置通过values.yaml保存在 Git 仓库中但安装动作是手动的。这不是技术做不到而是刻意为之基础组件是平台的底座底座不应该依赖平台自己。如果用 ArgoCD 管理 ArgoCD那就成了一个死结——ArgoCD 挂了谁去执行 GitOps 同步来恢复它答案是没人你得手动介入。那还不如一开始就老老实实手动装别假装能自动恢复。业务应用和 Addon由 ArgoCD 通过 ApplicationSet 管理。新增一个项目时只需要在 GitOps 仓库中新增一个 Application 定义文件ArgoCD 自动同步。这部分完全 GitOps 化。这个分层自举的设计不是一个优雅的方案但它是一个诚实的方案。很多文章会声称一切皆 GitOps但底座组件的手动安装是工程现实。我们宁可在架构文档里承认这一点而不是假装 pipeline 里一个terraform apply就能解决一切。五、分支即环境单集群多命名空间的路由设计不做一个环境一个集群的奢侈方案。500 个项目跑在集群上通过命名空间做逻辑隔离K8s 集群Git 仓库自动手动手动自动创建previewfeature-x-项目Afeature-y-项目Bprod项目 A项目 Buat项目 A项目 Bfat项目 A项目 B项目 Cdevelophotfix-uatmasterfeature/xxx为什么还是单集群500 个项目的体量下这个选择看起来有些反直觉很多人第一反应是肯定得拆。我们的理由不是单集群有多好而是多集群在这个场景下带来的额外复杂度——多套监控、多套日志、多个 Ingress 入口、跨集群服务发现、多版本的 API 兼容——在当前阶段大于单集群的风险。命名空间级别的隔离加上 RBAC 和资源配额已经做到了一个环境的故障不波及其他环境一个团队的 Pod 不抢占另一个团队的资源。什么时候拆当出现以下信号之一某个业务方要求生产环境物理隔离合规要求而非技术需求、集群规模接近单集群的节点上限、或者控制面压力大量 ArgoCD Application 导致 API Server 负载过高开始影响调度性能。当前架构的一个重要设计是环境配置和集群目标是解耦的——同一个 GitOps 仓库、同一套 Chart 模板拆集群时只需要将 prod 命名空间的 ArgoCD Application 指向新集群即可不需要重新生成任何制品。生产部署必须手动触发。fat 可以自动但 uat 和 prod 在 pipeline 里需要人点按钮。这不是技术限制是流程设计——通往生产的每一步都要有人对它负责。Feature 预览环境的生命周期管理。feature 分支在合入或删除后对应的命名空间、Ingress 域名、ArgoCD Application 一并自动回收。不留僵尸资源是云成本控制的底线。六、集群内流量拓扑南北向和东西向分开看集群内集群外部域名路由域名路由iptablesiptablesiptables东西向直连DNSCDNSLB七层转发 / TLS 终结Traefik Ingress限流 / 域名路由Service AService BPod A-1Pod A-2Pod B-1南北向CDN → SLB七层转发 TLS 终结→ Ingress → Service → Pod。SSL 终结在 SLB 层证书统一管理。Ingress 层专注于域名路由和限流策略各司其职。东西向集群内服务间直连不绕 Ingress。减少一跳延迟也避免内部流量被限流策略误伤。为什么选 Traefik 而不是 K8s 原生 Ingress ControllerTraefik 的中间件机制限流、重定向、路径替换、IP 白名单可以按 IngressRoute 粒度绑定不需要在每个应用的 Chart 里重复实现这些横切逻辑。代价是它的 CRD 和原生 Ingress 资源不通用团队需要额外学习。如果你已经在用原生 Ingress 且没有中间件需求没必要换。多租户的网络隔离500 个项目跑在一个集群里不同命名空间之间的 Pod 默认可以互访K8s 的默认行为。当前没有上全量 NetworkPolicy——不是不需要而是 500 个项目的 NetworkPolicy 规则维护成本太高且大部分项目之间没有调用关系默认策略就是全通。对于有明确隔离需求的业务比如涉及支付或用户数据的服务单独配白名单策略而不是一刀切。如果后续监管要求升级模板层可以自动为每个项目生成默认拒绝 显式放行的 NetworkPolicy。这个决策是权衡过的——不被还没发生的合规需求拖着走但也留好了升级路径。七、渐进式交付灰度的真正价值是反悔权标准发布停旧启新中间有短暂不可用。K8s 滚动更新能解决这个问题先启新 Pod健康检查通过再停旧 Pod但如果新版本有 bug滚动更新会把 bug 逐步扩散到所有 Pod等你发现已经全量了。灰度的真正价值不是平滑切换而是在错误扩散之前拦住它。蓝绿发布确认异常创建完整绿色环境切换 Ingress 权重观察窗口回收蓝色环境切回蓝色金丝雀发布通过失败创建 Canary Pod切 10% 流量自动分析Prometheus 指标逐步提升至 100%自动回滚标准发布Rollout 更新新 Pod 启动健康检查通过旧 Pod 终止