技能介绍

要解决什么问题

当团队从「能跑起来」走向多环境、多集群、合规与 SLA 并存时，常见问题不再是单个 Deployment 怎么写，而是：集群拓扑与网络边界怎么划、变更怎么进生产、金丝雀与回滚谁负责、租户隔离与准入策略如何落地。本技能把对话定位在平台架构师视角：在已有容器编排前提下，做 GitOps、安全、可观测性与成本之间的权衡，而不是替应用层 debug 业务代码。

技能如何协助你

它会按平台工程节奏推进，典型路径包括：

澄清需求：工作负载特征、合规约束、规模与 RTO/RPO 目标。
定架构：集群形态（托管 EKS/AKS/GKE、OpenShift/Rancher 或自管）、多集群/联邦、Ingress 与 Gateway API、是否引入 Istio/Linkerd/Cilium 等服务网格。
定交付：Argo CD、Flux v2 等 GitOps 仓库结构（app-of-apps、环境晋升）、渐进式交付（Argo Rollouts、Flagger）。
加固与验证：Pod 安全标准、网络策略、OPA/Gatekeeper/Kyverno、镜像扫描与供应链（Sigstore/SBOM）；在预发环境验证后再谈生产变更与回滚计划。
可运维：Prometheus/Grafana、OpenTelemetry 追踪、Velero 备份、HPA/VPA/KEDA 与 FinOps（KubeCost/OpenCost）等配套。

能力面覆盖 CNCF OpenGitOps 四原则（声明式、Git 版本化、自动拉取、持续协调），并强调纵深防御与渐进式发布默认优先。

适用边界

适合：设计 K8s 平台或多集群策略、实施 GitOps/渐进式交付、规划服务网格/安全/多租户、优化可靠性、成本或开发者自助体验。
不适合：仅需本地 minikube/单节点、只查应用 bug 且无需平台改动、或团队尚未采用 Kubernetes。
安全提醒：未经批准且未制定回滚方案，避免直接改生产；策略与准入变更应先在预发环境验证。

截图预览

使用场景

持牌或强合规业务要上线多集群 Kubernetes，需先定集群拓扑、网络边界，再用 Argo CD/Flux 设计 GitOps 与环境晋升。
生产发布要从「直接 apply」改为金丝雀或蓝绿，需在集群内落地 Argo Rollouts/Flagger，并配合 Ingress 或服务网格做流量拆分。
多团队共用同一套集群，需设计命名空间隔离、RBAC、ResourceQuota 与 NetworkPolicy，并用 OPA/Gatekeeper 或 Kyverno 做准入。
微服务 SLA 已承诺但成本超标，要在 Prometheus/OpenCost 数据基础上调 HPA、requests/limits 与节点装箱，同时保留 Velero 级备份与跨区恢复预案。

适合人员

公司内部 Kubernetes 平台负责人，要把 EKS/AKS/GKE 或多集群治理、开发者自助预置做成可重复的平台能力。
准备从传统 CI/CD 迁到 GitOps 的基础架构 Tech Lead，需要定 monorepo/polyrepo、app-of-apps 与回滚/漂移处理流程。
安全或合规对接人，要把 Pod 安全标准、镜像扫描、供应链签名（如 Sigstore）写进集群准入与发布流水线。
负责容器账单的 SRE 或 FinOps，要在观测与容量数据支撑下做成本分配，且不能牺牲已承诺的可用性目标。