云原生平台主权：用多平面架构拆解控制权、数据与运营边界

谈到云主权，很多团队会先问两个问题：工作负载运行在哪个区域，数据存储在哪个区域。这两个问题很重要，但它们只覆盖了主权的一部分。一个云原生平台还包含集群控制面、身份与密钥管理、镜像与软件供应链、日志审计、运维入口以及故障处理流程。只要其中一部分仍由区域之外的组织、服务或凭证控制，合规边界就可能并不完整。

多平面架构提供了一种更清晰的分析方法：把平台拆成不同职责和信任边界，分别判断谁能访问、谁能修改、数据在哪里流动，以及发生故障时谁拥有最终操作权。

“运行在哪里”不等于“谁拥有控制权”

选择本地云区域，通常可以解决工作负载和业务数据的地理位置问题，但不能自动解决以下问题：

• Kubernetes API 是否由外部团队管理。
• 集群管理员凭证是否由境外身份系统签发或托管。
• 容器镜像是否必须从境外镜像仓库拉取。
• 日志、指标和审计事件是否被发送到区域外的平台。
• 加密密钥是否由区域外的密钥管理服务控制。
• 发生安全事件时，谁有权限暂停工作负载或导出数据。

因此，主权评估不能只看 region 字段，还要追踪完整的控制链路和数据链路。一个业务服务可能运行在本地节点上，却依赖外部控制面、外部 DNS、外部镜像仓库和外部监控平台。此时，数据位置看似符合要求，平台控制权却仍然分散在边界之外。

用多平面架构划分责任

“多平面”不是固定的产品名，而是一种架构拆分方式。具体划分可以根据组织和监管要求调整。下面是一种可实践的模型：

工作负载平面

工作负载平面承载业务 Pod、数据库、消息队列和其他运行时组件。重点关注：

• 节点和持久化卷所在的地理位置。
• 网络流量是否会跨越主权边界。
• 备份、快照和灾备副本是否仍在规定区域内。
• 租户之间是否有明确的网络和身份隔离。

控制平面

控制平面负责 Kubernetes API、调度、集群配置和资源编排。这里要明确谁能修改部署、读取 Secret、创建管理员账号以及变更网络策略。

如果控制平面由外部平台托管，团队需要确认它的 API、管理员访问、控制器日志和故障处理流程是否满足本地要求。对于高主权要求的场景，可以考虑在目标司法辖区内运行独立控制平面，并将管理员身份、审计和升级流程纳入本地运营体系。

数据与安全平面

数据平面不只包括业务数据库，还包括 Secret、密钥、证书、镜像、备份、日志和指标。实际设计时，可以逐项建立数据清单：

管理与运营平面

主权还取决于“谁在什么时候可以做什么”。运营平面包括管理员登录、工单审批、远程运维、补丁升级、供应商支持和紧急响应。

一个可审计的平台应当能回答：某次变更由谁批准、谁执行、使用了哪个身份、访问了哪些资源、凭证何时失效，以及平台在紧急情况下是否仍然需要外部人员介入。技术组件部署在本地，并不代表运营权已经本地化。

可以怎样落地：从边界清单开始

下面的示例使用 Kubernetes 的命名空间、节点标签、污点和网络策略，表达一个“主权工作负载平面”的基本约束。它不是完整的合规方案，假设集群已经部署在目标区域，并且集群管理员能够创建策略资源。

运行前请将 sovereign.example 替换为实际域名，并确认集群已安装支持 NetworkPolicy 的 CNI 插件。把以下内容保存为 sovereign-workload.yaml，再执行 kubectl apply -f sovereign-workload.yaml。

apiVersion: v1
kind: Namespace
metadata:
  name: sovereign-app
  labels:
    data-classification: restricted
    residency: local
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
  namespace: sovereign-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: order-api
  template:
    metadata:
      labels:
        app: order-api
    spec:
      nodeSelector:
        sovereignty.example/region: local
      tolerations:
        - key: sovereignty.example/region
          operator: Equal
          value: local
          effect: NoSchedule
      containers:
        - name: order-api
          image: registry.sovereign.example/order-api:1.4.2
          ports:
            - name: http
              containerPort: 8080
          env:
            - name: DATA_RESIDENCY
              value: local
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: order-api-egress
  namespace: sovereign-app
spec:
  podSelector:
    matchLabels:
      app: order-api
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: sovereign-app
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

可以用下面的命令检查工作负载是否被调度到正确节点，并查看策略对象是否已经生效：

kubectl get nodes -L sovereignty.example/region
kubectl -n sovereign-app get pods -o wide
kubectl -n sovereign-app describe networkpolicy order-api-egress
kubectl -n sovereign-app get deployment order-api -o jsonpath='{.spec.template.spec.nodeSelector}'

这段配置只解决了运行时的一小部分问题。生产环境还应配合以下机制：

• 使用区域内的镜像仓库，并在部署前验证镜像签名和软件物料清单。
• 将 Secret 对接到满足边界要求的密钥系统，避免把长期凭证直接写入 YAML。
• 禁止日志和指标默认发送到未经审核的外部 SaaS 平台。
• 通过短期凭证、最小权限和多方审批管理集群管理员访问。
• 为备份、快照和灾备演练设置与主数据相同的地域和访问约束。
• 记录供应商支持、平台升级和紧急远程访问的审计证据。

设计中的取舍

更强的主权边界通常意味着更高的运营成本。团队可能需要维护本地控制平面、镜像仓库、密钥系统和监控组件，还要自行承担补丁、容量、灾备和故障响应责任。完全隔离也可能减少可用的托管服务和全球化运维能力。

因此，平台不一定要追求“所有组件都自建”，而应对每个平面分别评估风险。低敏感度的公共前端可以采用更灵活的托管方式；包含敏感数据的核心服务，则需要更严格的本地控制、审计和故障处理边界。关键是让例外变得明确、可批准、可监控，而不是把所有依赖隐藏在“区域内运行”这个表述之后。

发布前检查清单

• [ ] 工作负载、持久化数据、备份和灾备副本都已标注地域。
• [ ] 控制平面的管理员、控制器和升级流程已明确归属。
• [ ] 身份、密钥、证书和 Secret 的持有者已完成审查。
• [ ] 镜像构建、签名、仓库和拉取链路符合供应链要求。
• [ ] 日志、指标、审计事件和告警没有未经批准的跨境传输。
• [ ] 紧急运维不依赖无法审计或无法撤销的长期凭证。
• [ ] 已通过故障演练验证：外部依赖不可用时，核心业务和本地运维仍能工作。

云主权的核心不是在架构图上画出一个本地区域，而是逐个平面确认控制权、数据权和运营权。多平面架构的价值，在于把这些问题从宽泛的合规口号变成可以盘点、配置、测试和审计的工程对象。