云计算与数据中心

云原生平台主权始于多层架构,而非仅仅选择区域

CNCF的一篇文章分析了如何在独立的层级和集群中分离控制、工作负载运行、监控和工作流,以提高云主权可证明性。OpenChoreo展示了一个基于出站通信和声明式配置的实际模型,但法律和运营限制仍然存在。

2026-08-18
1 分钟阅读
29 浏览量
فريق تحرير certi.news
云原生平台主权始于多层架构,而非仅仅选择区域

云原生平台的主权并不只由工作负载运行或数据存储的位置决定。根据CNCF于2026年8月18日发布、由CNCF大使Chamod Perera和WSO2高级软件工程师Suvin Kodituwakku撰写的分析,主权证明还取决于控制状态所在的位置、日志和元数据的传输路径、能够访问密钥和凭据的实体,以及如果供应商的服务消失,团队能否继续运行。

该分析建议将主权视为平台拓扑的一项属性,而不仅仅是设置列表中的区域选择。文章以OpenChoreo为这一方法提供了一个可检验的实例。OpenChoreo是一个面向开发者的开源内部开发者平台,也是CNCF的Sandbox阶段项目,同时强调这些架构原则并不局限于OpenChoreo。

四个超越服务器位置的问题

文章指出,在EU Data Act、NIS-2、DORA和UK Data Use and Access Act等框架下,平台团队必须回答一些超越确定地理区域的实际问题。第一个问题是:每个能够接触租户数据的组件,包括控制层和日志层,受哪个法律管辖?第二个问题是:如果供应商托管的服务停止,团队能否运行、重建和迁移工作负载?

另外两个问题涉及:境外实体是否能够访问密钥、集群状态或管理凭据;以及更换供应商、硬件或国家是否需要重写工作负载。分析得出的结论是,这些问题主要聚焦于控制和状态所在的位置,以及谁拥有访问它们的能力。

多层架构如何工作?

OpenChoreo将平台划分为相互独立的集群,每个集群都有自己的生命周期、安全边界和扩展行为:

  • 控制层:通过声明式API保存期望状态并运行协调器,但不运行租户工作负载。
  • 数据层:运行工作负载的兼容Kubernetes集群,每个集群都有独立的API服务器和状态。
  • 监控层:收集并提供日志、指标和追踪数据。
  • 工作流层:执行CI和GitOps操作。
  • 体验层:提供开发者门户、CLI、API和MCP。

最重要的要素是通信模型。数据层、监控层和工作流层通过mTLS向控制层网关发起经相互认证的出站连接,而控制层不会主动向它们发起连接。因此,承载受监管工作负载的集群API服务器不会暴露在互联网中。此外,控制层保存的是期望状态,而不是租户的完整运行状态;因此,即使与控制层失去连接,数据层仍能继续处理请求。

对平台团队而言,实际发生了什么变化?

每个数据层都可以关联到一个特定的法律管辖区,从而使“一地一数据层”模型具备可审查性和可审计性。此外,每个数据层都会将其运行数据发送到区域监控层,而不是通过控制层传递日志和追踪数据。这样,租户工作负载及其遥测数据就能留在指定的区域边界内。

脱离供应商持续运行的能力,依赖于每个数据层都是完整且兼容的Kubernetes集群,而不是封闭的托管端点。分析提到,可以使用CNCF和云原生生态中的开源组件,例如Argo Workflows、Cloud Native Buildpacks、OpenSearch、Prometheus、OpenTelemetry、Flux、cert-manager和Cilium。模块化架构允许替换组件,或通过相同的查询接口连接现有监控体系。

至于机密和密钥保护,则交由兼容External Secrets Operator的存储库或运营方选择的保险库,而不是默认强制使用某一方拥有的密钥。还可以在命名空间、项目和组件层面实施细粒度权限,并将组连接到任何OAuth2/OIDC身份提供商,无论调用方是开发者、CLI工具还是人工智能代理。

虚拟集群与平台层的集成

这一模型并不会取消租户集群模式,而是对其进行补充。虚拟集群为每个租户提供一个虚拟控制层、API服务器和专属存储,它们位于共享主机集群内,从而以低于每个租户专属集群的成本隔离租户之间的控制状态。但虚拟集群本身并不能确定租户应部署在哪个管辖区、日志应发送到哪里,或谁有权将工作负载从一个环境或区域升级迁移到另一个环境或区域。

在这里,平台层增加了分布和运行控制。DataPlane资源可以携带法律管辖区标签,并通过observabilityPlaneRef资源关联到区域监控层,而升级路径则确定工作负载可以在哪些环境之间迁移。开发者门户还提供预置路径,减少了向用户授予敏感集群直接访问权限的需要。

但这种组合有一个明确的限制:位于同一主机上的租户共享节点和操作系统内核。如果威胁模型要求每个租户实现硬件级隔离,虚拟集群将不够用,此时需要实际独立的数据层。

将主权作为声明式且可审计的配置

该分析建议通过声明式Kubernetes资源表示拓扑,并将其保存在Git中:哪个区域使用哪个数据层、哪个目标接收监控数据,以及允许哪些升级路径。这样,创建一个新的管辖区就会变成一个可审查的合并请求(pull request),而回答某个租户的数据为何存在于特定区域,也将依据变更记录,而不是控制面板截图。

不过,多层架构不会改变运营基础设施实体的法律管辖地,也不会消除其受制于相关法律体系的风险。它能够划定边界,但不会单独强制执行边界内部发生的策略;供应链认证、SBOM、审计记录,以及通过SPIFFE/SPIRE等工具实现的工作负载身份,仍然是需要集成的独立控制措施。

运营成本是最后一个限制:每增加一个集群,就需要进行监控、升级和备份。因此,只有当划定的边界具有实际的法律或安全重要性时,这种架构才是合理的;在不需要这些边界的环境中,它可能会过度设计。总之,将租户集群用于资源隔离,将多层架构用于确定哪些内容可以跨越边界,再结合可进行版本管理的声明式配置,就能把主权从合同承诺转变为一种可以运行和审查的属性。

新闻来源
ف
作者

فريق تحرير certi.news

同一分类

你可能还喜欢

查看所有新闻