从数据驻留（Data Residency）到数字主权（Digital Sovereignty）：云原生平台的架构模式

来源: Cloud Native Computing Foundation
作者: Hrittik Roy, CNCF Ambassador
发布时间: 2026/6/16 19:00:00
原文链接: https://www.cncf.io/blog/2026/06/16/from-data-residency-to-digital-sovereignty-architectural-patterns-for-cloud-native-platforms/

---

过去两年间，数字主权（digital sovereignty）已从政策讨论演变为实际的平台工程（platform engineering）议题。
《欧盟数据法案》（EU Data Act）自2025年1月11日起全面施行；
《NIS-2 指令》和《数字运营韧性法案》（DORA）已深刻影响受监管行业的日常平台决策；
英国《2025年数据使用与访问法案》（Data Use and Access Act 2025）正在2026年逐步落地，其中包含具有约束力的可移植性规则。

因此，平台团队越来越需要展示的不仅是工作负载运行的位置，还有基础设施的运营、安全与治理方式。
有关控制平面（control plane）、加密密钥、管理权限、审计能力以及工作负载可移植性的问题，如今已与传统的数据驻留（data residency）要求一同出现。

对于构建云原生平台的组织而言，这带来了一个重要的架构挑战。
虽然区域基础设施仍是重要考量，但许多主权要求最终取决于控制权、访问权和运营责任在平台栈（platform stack）中的分配方式。

本文探讨了基于 Kubernetes 的平台如何满足这些要求，以及为什么控制平面设计正成为主权讨论中日益关键的部分。

平台真正需要的“主权”是什么

当你拆解监管机构、审计方和采购团队反复提出的要求时，会发现以下四个特性反复出现：

• 司法管辖隔离（Jurisdictional containment）：所有能读取租户数据的组件（包括控制平面）都运行在组织可以指定并维护的法律管辖区内。
• 运营自主（Operational autonomy）：运行工作负载的团队能够在不依赖单一供应商托管服务的前提下，自行重建、迁移和审计工作负载。
• 加密与访问控制（Cryptographic and access control）：密钥、etcd 内容和管理员凭证不被所选管辖区之外的实体访问。
• 可移植性（Portability）：当底层硬件、供应商或国家需要变更时，工作负载无需重写即可迁移。

对于主权云构建者来说，这些不仅仅是合规复选框。
控制平面位置、元数据存储、管理访问权限、加密机制和密钥管理所有权都必须明确界定，同时还要制定备份策略和支持访问模型，以尊重管辖区边界。
“我们选了法兰克福区域”并不能满足这些要求。只有深入到控制平面的基础设施选择才能满足。

为什么单个 Kubernetes 集群不够用

在构建主权平台时，这些要求很快变得无法回避。Kubernetes 作为基石，将这些要求整合在一起，为平台提供了合适的基础。
CNCF 背书、声明式 API 和开放生态系统（Kyverno 用于策略、Argo CD 和 Flux 用于 GitOps、KubeVirt 用于虚拟机、Cilium 用于网络、SPIFFE/SPIRE 用于工作负载身份）正是本地受监管企业正在趋同的构建模块。
在 architecture.cncf.io 上发布的 Swisscom 主权 Kubernetes 参考架构 清晰地预示了行业的发展方向。

当你开始将实际的主权要求映射到单个集群上时，缺陷便显现出来：

• 一个控制平面服务所有租户。影响某一租户数据平面的司法事件，可能波及共享 API Server、etcd 和控制器的所有租户。
• 命名空间（namespace）并非隔离的。即使有强大的 RBAC，自定义资源定义（CRD）是共享的，准入 Webhook 是共享的，配置错误的控制器也会在整个集群中扩散。
• 集群扩张（cluster sprawl）成了常态。每个管辖区、每个环境、每个团队都部署一个完整的 Kubernetes 集群。运维负担重、成本高、变更慢。

在实际操作中，运营商往往运行着同时支持多个受监管环境的共享平台，每个环境都有自己独特的运营、合规和数据驻留要求。

例如，一家供应商可能分别运营着欧盟和英国的租户环境，每个环境都由自己的区域基础设施、存储和审计边界支撑，如下图所示：

图片：主权设计，但这并非真正的主权（来自 《主权：意味着什么》 )

上述问题的关键在于，仅靠工作负载放置（workload placement）并不能建立主权。即便租户工作负载运行在不同的区域，共享的 Kubernetes 控制平面仍然集中了管理权限、策略执行、API、控制器以及关键操作决策。无论该控制平面位于何处，由谁治理，最终都决定了平台真正的主权边界。

租户集群作为主权原语

这里值得学习的模式是租户集群（tenant cluster）：为单个隔离边界（isolation boundary）划分出的一个 Kubernetes 控制平面，运行在共享底层集群之上。每个租户集群拥有自己的 API 服务器（API server）、自己的 controller manager、自己的调度器（scheduler）以及自己的数据存储（data store）。从工作负载的角度看，它正在与一个真正的、符合规范的 Kubernetes 集群通信；从平台的角度看，租户集群的控制平面作为一组 Pod 运行在共享的控制平面集群（Control Plane Cluster）上。

实现这种模式的一种流行方式是 vCluster——一个开源项目，它将租户集群作为 Pod 预置在现有 Kubernetes 集群中。本文后续将以此为例进行说明，因为它易于在本地尝试，但其所蕴含的架构思想适用于任何为每个隔离边界提供独立控制平面的方案。

以下是租户集群与主权直接相关的几个属性。

独立的控制平面。 每个租户集群拥有自己的 API 服务器和自己的后端存储（嵌入式 etcd、外部 etcd 或 SQL 数据库）。一个租户的 CRD、准入 webhook 和审计日志不会泄漏到另一个租户。独立的控制平面还意味着每个租户可以拥有独立的 Kubernetes 版本、独立的升级周期和平台栈差异——租户数量越多，这一点就越重要。集群级别的管辖区边界（jurisdictional boundary）因而具有实际意义。

可插拔的后端存储。 租户集群的状态可以保存在您自有硬件上的加密卷中，并由您选择的运维人员管理。这样一来，不仅工作负载可以实现驻留（residency），状态驻留也成为您可以设计的一部分。

租户隔离，而非多租户命名空间。 租户集群内部的工作负载无法回溯到底层集群的 API。为了在容器层实现更强的运行时隔离，常见的做法是将租户集群与基于用户命名空间（user-namespace）的运行时（例如 vNode）配对，或者与 gVisor 或 Kata Containers 配对（后者在需要 VM 边界时使用）。这对 AI 云运营商尤其重要，因为其威胁模型通常既包含容器逃逸（container-escape）风险，又需要防止租户在共享硬件上相互观察工作负载。

工作负载可移植性。 租户集群暴露的是符合规范的 Kubernetes API。其内部的工作负载可以移植到任何符合规范的 Kubernetes 集群上，无论是托管的还是自管理的。从由超大规模云提供商支撑的底层集群迁移到主权提供商，或迁移到裸金属，都无需重写工作负载。

这种模式非常直接：平台团队运行少量底层 Kubernetes 集群，而租户、管辖区或受监管的工作负载各自获得自己的租户集群。主权边界成为一等对象，您可以像使用 vCluster 那样声明、审计和移动它们。

从架构角度看，这通常意味着每个主权管辖范围或数据中心有一个底层控制平面集群，在该边界内为客户提供隔离的租户集群。

例如，一个欧盟控制平面集群可能专门服务于欧盟居民租户，而另一个独立的英国控制平面集群独立服务英国客户。这种模型允许每个租户运行自己的 Kubernetes 控制平面，而无需为每个客户提供完整的物理集群。

一个实用的模式：将管辖范围视为一个集群

假设一家 SaaS 公司同时服务欧盟和英国客户。根据《欧盟数据法案》，欧盟居民租户的客户数据、审计日志和元数据必须保留在欧盟管辖范围内，并且必须可移植。英国客户受《2025年数据使用与访问法案》管辖，这是一个类似但不完全相同的制度。同一款产品，两个主权边界。

一种清晰的表达方式是：每个管辖范围一个租户集群，声明为 Kubernetes 资源并通过 GitOps 管理。无论你使用什么工具，形态都是相同的：一个自定义资源描述租户集群的位置、后端存储和策略姿态，并由一个控制器进行调和。

必须在该资源中落地的约束包括：

• 一个节点选择器或拓扑约束，将租户集群中的每个 Pod 固定到标记有正确管辖范围的节点上，在租户控制平面级别作为硬约束强制执行，而不是依赖主观行为。
• 租户集群自身状态（其 etcd 或等效 SQL）的后端存储，位于所选管辖范围内。控制平面的数据、API 对象、机密信息，绝不能经过非管辖范围的管理服务。
• 一个位于管辖范围本地的审计日志接收端，确保租户集群的审计流永远不会跨越监管机构所关注的边界。
• 加载到租户集群中的策略包（Kyverno 或 OPA Gatekeeper），从内部强制实施数据驻留、镜像来源和 SBOM 要求。

英国租户集群在结构上看起来相同，只是标签不同、后端存储不同、审计目标不同。添加一个新的管辖范围只需一个拉取请求（Pull Request），而不需要构建一个新集群。

整个定义都保存在 Git 中。“为什么租户 X 的数据在管辖范围 Y 中”的审计追踪是一段提交历史，而不是控制台截图。

缩小主权事件的爆炸半径

关于主权的讨论通常集中在数据驻留上。更难处理的是当出现问题时会发生什么：传票、配置错误的控制器、凭据泄露。

租户集群以具体方式缩小了爆炸半径。

如果租户集群的后端存储位于管辖范围本地的运营商处，那么针对底层集群运营商的《云法案》式请求并不会自动获取租户集群的 etcd 内容。法律目标和技术目标在设计上是解耦的。

欧盟租户集群中受损的准入 Webhook 无法触及英国租户集群，因为它们不共享同一个控制平面。Webhook 完全位于一个租户集群的 API 服务器内部。

平台范围的 CRD 升级可以按每个租户集群分批进行。你可以在一个管辖范围内运行 Kubernetes 1.34，在另一个管辖范围内运行 1.33，同时等待监管机构完成对某个 CVE 的审查。版本差异变成了一种特性，而不是问题。

这些特性并非魔法。它们源于为每个主权边界提供其自己的控制平面，并且很难在单个共享集群上进行改造。

裸金属、AI 云以及未来走向

同样的模式可以向下组合。如果要求是硬件主权而不仅仅是运营商主权，那么底层集群本身可以运行在使用 Metal3 和 Ironic（或更高级的工具如 Tinkerbell 或 vMetal 等层）配置的裸金属上。租户集群则通过构造继承该硬件边界。堆栈的任何部分都不会在所选管辖范围之外的基础设施上运行。裸金属 GPU 上的主权 AI 云指南详细介绍了 GPU 密集型构建的端到端实现。

这对于 AI 云浪潮尤其重要。GPU 密集型工作负载一直是依赖超大规模云提供商的最强烈理由，同时也是在 《欧盟 AI 法案》第 12 条的日志记录和治理要求下暴露最多的负载。在主权裸金属上运行 GPU 承载的底层集群，并通过动态资源分配为每个客户或每个管辖范围的租户集群提供 GPU 访问权限，这种模式能为 AI 平台团队提供一个可信的回答，既回答了“训练在哪里运行？”，也回答了“谁可以传唤权重？”

这并非假设。Polarise 是一家德国主权 AI 云提供商（sovereign AI cloud provider），它是一个在实际生产中运行这种确切模式的运营商实例：底层是共享 GPU 容量，上层是每个客户一个租户集群（tenant cluster），所有这一切都在欧盟管辖范围内。运营商可以不同，但模式相同。

这不能解决的问题

有必要坦诚地说明边界。

租户集群模式并不改变运行底层集群的运营商的法律管辖权。如果一家总部位于美国的公司运营着底层的 Kubernetes，那么该运营商依然面临《云法案》（CLOUD Act）的风险暴露。这种模式减少了并分割了风险暴露面，但并未消除它。对于运营商管辖权本身就是威胁模型的工作负载，你仍然需要在主权硬件上运行主权运营商（sovereign operator），并在其之上采用租户集群模式。

这种模式也不能取代 CNCF 主权栈（sovereign stack）的其他部分。你仍然需要一个策略引擎（如 Kyverno 或 OPA Gatekeeper）、一个 SBOM 流水线（《网络弹性法案》不会等待）、一个审计日志流水线、一个工作负载身份层（如 SPIFFE/SPIRE）以及一个 GitOps 控制器。租户集群是一个原语（primitive），而非一个平台。像 DORA 和 SecNumCloud 3.2 这样的框架明确指出：租户集群边界是运营弹性与主权控制（operational resilience and sovereignty controls）的一个输入，而非全部答案。

参考：vCluster DORA 信息图

此外，每个租户集群都有运维成本。每个集群都是一个真实的控制面，需要监控、升级和备份。只有在所划定的边界背后具有实际法律或风险权重时，其收益才能证明成本合理。对免费层级而言，为每个客户分配一个租户集群属于过度设计。而在每个管辖区内为少数受监管客户各设一个租户集群，正是这种模式的适用场景。

2026年主权平台的形态

将上述线索串联起来，那些能通过2026年审计的平台大致呈现如下形态：

底层运行少量 Kubernetes 集群（当威胁模型要求时，部署在主权的（sovereign）基础设施上）。每个管辖区、每个受监管工作负载或每个受监管客户，各自拥有独立的租户集群，每个集群拥有自己的控制面，在 Git 中声明，通过 Argo CD 或 Flux 部署。策略由 Kyverno 或 Gatekeeper 在底层集群执行，并在每个租户集群内部按租户实施。审计日志流式传输至管辖区本地的存储（sink），绝不跨越监管机构关心的边界。工作负载基于普通 Kubernetes API 编写，随着采购、地缘政治和硬件可用性的变化，可在不同底层集群间移植。

在此模型中，主权（sovereignty）并非采购条款，而是集群中的一个对象——拥有名称、模板和提交历史。这正是监管机构开始期望的形态，也是平台团队能够实际运维的形态。