云原生架构治理策略：让系统不再“失控”

想象一下，你家小区的水电网络突然没人管了——水管漏水没人修，电表乱跑没人查，住户自己接线拉管，最后整个系统变成一团乱麻。这就像没有治理的云原生系统：微服务越建越多，部署越来越快，但问题也越来越多。

为什么需要治理？

云原生不是一上就灵。Kubernetes 把部署变得简单，CI/CD 让更新像点外卖一样频繁。可当几十个团队各自为政，用不同的框架、配置方式、日志格式时，故障排查就成了侦探破案。某个接口突然变慢，可能要翻五六个系统的日志才能定位。

治理不是设卡拦人，而是建立共识。就像城市要有交通规则，云原生环境也需要统一的命名规范、资源配置标准、安全基线和监控接入方式。

从镜像管理开始

一个未经扫描的基础镜像可能埋着漏洞，上线就是定时炸弹。治理的第一步是管住镜像来源。比如规定所有镜像必须来自企业私有仓库，并通过安全扫描。

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: require-image-registry
spec:
  validationFailureAction: enforce
  rules:
  - name: validate-registry
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "使用非受信镜像仓库禁止部署"
      pattern:
        spec:
          containers:
          - image: "harbor.example.com/*"

上面这段 Kyverno 策略强制所有 Pod 只能使用指定仓库的镜像。类似规则还能用于限制特权容器、挂载敏感路径等高风险操作。

服务命名与标签规范

在 Kubernetes 中，标签（Label）是组织资源的核心。混乱的标签会让运维寸步难行。比如要求所有服务按 team、app、env 三个维度打标签：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-prod
  labels:
    team: auth-team
    app: user-service
    env: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
        env: production
    spec:
      containers:
      - name: app
        image: harbor.example.com/auth/user-service:v1.2

有了统一标签，就能快速筛选某个团队在生产环境的所有服务，出问题时也能精准通知责任人。

可观测性不是选配

日志、指标、链路追踪得提前规划。别等到半夜被报警吵醒才想起某服务没接 Prometheus。治理策略中应明确：所有新服务必须暴露 /metrics 接口，日志输出 JSON 格式并包含 trace_id。

可以用 OpenTelemetry 自动注入追踪代码，减少开发负担。平台层面通过 ServiceMesh（如 Istio）收集东西向流量，避免每个服务重复实现熔断、重试逻辑。

权限与生命周期控制

开发人员在测试环境有管理员权限没问题，但在生产集群必须收紧。通过 Namespace 隔离环境，配合 RBAC 控制操作范围。比如运维组只能查看日志和事件，不能直接修改 Deployment。

同时设定资源配额，防止单个服务吃光集群资源。还可以设置自动清理策略：超过30天未更新的测试环境自动回收，节省成本。