Sebastien Rousseau
联系我 ›

Cloud Native Banking in 2026: Kubernetes, DORA, Sovereignty, and the End of the VM vs Container Divide

Cloud native for banks has matured from container adoption to regulated platform engineering: Kubernetes, VM coexistence, data portability, DORA supervision, cloud dependency reviews, and operational resilience now define the architecture.

1 min read

2026 年的云原生银行：Kubernetes、DORA、主权与 VM 和容器分界线的终结

云原生银行在 2026 年已不再是关于银行能否使用云的争论，而是一项受监管的平台工程学科：如何在容器、虚拟机、数据织网、人工智能（AI）工作负载与多家云服务提供商之间运行关键服务，同时在《数字运营韧性法案》（DORA, Digital Operational Resilience Act）及类似制度下证明自身的运营韧性。IBM 将 2026 年描述为 DORA 真正意义上的首次监管检验之年，涵盖云依赖审查、网络安全检查、威胁导向渗透测试以及对关键第三方提供商的直接监督（IBM）。

执行摘要 / 要点速览

  • DORA 已经改变了云端话语。 2026 年带来欧盟对关键第三方提供商的直接监管，以及对银行云服务提供商依赖关系的针对性审查（IBM）。
  • Kubernetes 是平台层，而非完整答案。 银行需要 Kubernetes 来获得弹性、自动化和 AI/ML（人工智能／机器学习）工作负载能力，但同时也需要虚拟机（VM）共存能力，因为核心银行、支付、交易和风险系统仍运行在加固的虚拟化资产之上（Red Hat）。
  • VM 与容器的分界线正在消融。 Red Hat 将 OpenShift 与 Portworx 定位为一种统一模型，使虚拟机与容器共享策略、数据、备份、灾难恢复和治理控制（Red Hat）。
  • 云主权已成为设计约束。 银行正利用主权来管理司法管辖控制、运营自主权、密钥控制、数据所在地以及云集中度风险（Red Hat）。
  • AI 让云原生具备了紧迫性。 欺诈检测、流动性分析、实时个性化与监管报送越来越要求弹性算力靠近敏感数据（Red Hat）。
  • 退出策略不是一份 PDF 文件。 在现代监管预期下，银行需要经过验证的可移植性、依赖关系图、合同证据、恢复程序，以及关键业务功能的现实迁移路径。
  • 架构目标是受控的云原生。 优胜的银行平台让开发者获得自助式交付能力，同时自动执行审计、加密、数据驻留、韧性测试、职责分离和第三方风险控制。

为何 2026 年是云原生监管之年 #

DORA 自 2025 年 1 月起适用，但 2026 年才是监管力度真正显现之年。IBM 指出，首批关键第三方提供商（Critical Third-Party Providers）名单已在 2025 年 11 月公布，2026 年将带来与欧洲监管机构（European Supervisory Agencies）的直接接触、合同审查、现场检查以及云依赖关系分析（IBM）。

这改变了举证责任的分配。银行不能再声称云端中断仅仅是供应商的问题。即便关键业务功能依赖于超大规模云厂商、SaaS（软件即服务）提供商、数据平台以及托管安全服务，金融机构仍需为这些功能的韧性承担责任。

2026 年云原生银行的基准 #

1. Kubernetes 作为运行层 #

Kubernetes 为银行提供部署自动化、弹性扩展、策略执行、容器编排，以及跨私有云、公有云与主权环境的通用抽象层。对于新的工作负载，特别是 AI 驱动的欺诈检测、实时个性化、流动性分析与监管报送，Kubernetes 已成为天然的控制面（Red Hat）。

常见的错误是把 Kubernetes 视作终点。对银行而言，它是治理化开发者平台之下的底层基座。

2. VM 与容器的融合 #

绝大多数银行无法迅速重写核心资产。支付引擎、交易系统、信用评分、风险模型与核心银行平台仍依赖经过加固的虚拟机（VM）资产。Red Hat 主张，银行需要一个统一的平台，让虚拟机与容器协同运行，从而减少重复架构，并对齐策略、存储、备份与恢复控制（Red Hat）。

这是连接传统韧性与云原生敏捷之间的务实桥梁。它使银行得以先迁移外围服务、就近承载依赖数据的 AI 工作负载，并避免对关键系统进行脆弱的强行重写。

3. 面向 DORA 的运营韧性 #

IBM 指出，2026 年的监管优先事项包括跟进信息通信技术（ICT, Information and Communications Technology）安全与外包方面的不足、网络安全与第三方风险现场检查、威胁导向渗透测试、ICT 变更管理审查以及云依赖关系分析（IBM）。

这意味着韧性必须可被测试。仅有架构图远远不够。银行需要来自故障切换演练、事件模拟、备份恢复、依赖关系图、恢复时间测试和治理工作流的证据。

4. 主权作为平台能力 #

云主权不仅仅是数据驻留。它涵盖法律控制、运营控制、加密密钥控制、支持人员所属司法管辖、工作负载部署位置，以及在全球提供商或地缘政治进程引发中断时维持关键服务运行的能力。Red Hat 将主权界定为面对《通用数据保护条例》（GDPR, General Data Protection Regulation）、DORA 及各国云端规则等多元化监管时，银行所需的司法管辖控制与运营自主权（Red Hat）。

这在云原生层面的含义是：工作负载路由、密钥管理、密钥控制、数据分级与策略执行必须是可编程的。

银行平台技术栈 #

开发者体验层 #

银行级的云原生平台应当提供铺好的快速路径：黄金路径、模板、服务目录、自动化部署流水线、默认可观测性、策略即代码（policy-as-code）、标准化密钥集成以及经批准的数据通道。开发者不应在每次发布时都被迫与每位控制责任方逐一协商。

平台应让合规之路成为最快之路。这是唯一能够在数千项服务规模上奏效的模式。

控制层 #

控制层涵盖身份、访问管理、职责分离、加密、密钥托管、网络策略、镜像签名、软件物料清单（SBOM）、漏洞门禁、运行时安全、日志与证据生成。它正是 DORA、《网络与信息系统安全指令 2》（NIS2, Network and Information Security Directive 2）、GDPR、外包规则与内部模型风险政策被转化为可执行控制之处。

许多银行正是在此环节失利。它们采用了容器，却将控制留作平台之外的人工审批。

数据层 #

有状态工作负载是云原生银行最艰难的部分。Red Hat 关于 VM 与容器融合的论点在很大程度上依赖于一个统一的数据织网，以及覆盖虚拟机与容器的策略驱动备份、复制、故障切换与恢复（Red Hat）。

对银行而言，数据层必须回答三个问题：数据在何处、密钥由谁掌握、若基础设施失效服务如何恢复。

架构对照表：面向银行的云原生 #

能力 云原生模式 银行控制要求 失败模式
应用交付 Kubernetes、GitOps、模板 职责分离、变更证据、回滚 发布迅速却无法审计
遗留共存 VM/容器统一平台 策略一致性与迁移控制 双重资产、风险重复
数据服务 有状态算子与数据织网 数据驻留、备份、不可篡改、经测试的还原 无状态平台与有状态脆弱性并存
韧性 多可用区、多区域、故障切换 DORA 证据与关键业务功能映射 将云端中断作为供应商借口
主权 基于策略的工作负载部署 司法管辖与密钥控制证据 仅有数据驻留而无运营自主权
AI 工作负载 弹性算力靠近数据 模型治理、数据最小化、审计 敏感数据流向未经批准的 AI 服务

不同机构类型的含义 #

一级综合性银行 #

一级银行应在多家云之上构建受控的内部平台，并执行严格的策略即代码、数据分级与工作负载部署。它们具备足以支撑平台工程的规模，监管机构也会对其证据深度提出更高要求。

中型银行 #

中型银行应当标准化而非定制化。一个强大的托管 Kubernetes 平台、有纪律的云服务提供商遴选、清晰的退出策略以及自动化的证据生成，远比机构难以驾驭的庞大多云愿景更有价值。

金融市场基础设施 #

金融市场基础设施（FMI, Financial Market Infrastructures）首要追求的是韧性证明。它们应将云原生视为改进恢复能力、可观测性与受控变更的方式，而非纯粹的提速手段。

金融科技与支付服务商 #

金融科技公司与支付服务提供商（PSP, Payment Service Providers）可以快速行进，但必须避免成长出其控制模型所能承载之外。当它们具备系统重要性时，同样的韧性、第三方风险、事件报告与数据主权要求将随之而至。

结语 #

2026 年的云原生银行是一种治理架构。Kubernetes 不可或缺，但仅有 Kubernetes 还远远不够。胜出的机构将在必要之处融合虚拟机与容器，在新工作负载上采用云原生模式，按照 DORA 证明韧性，在平台层管控数据主权，并让合规自动化到足以使开发者得以快速行动而不致产生失控风险的程度。

旧的辩题是银行能否上云。新的辩题是银行能否让云原生足够安全、足够可移植、足够可被佐证，以承载真正重要的服务。

常见问题 #

DORA 是否阻止银行使用云？

并非如此。DORA 并不禁止使用云。它要求金融机构对依赖云及其他 ICT 提供商的关键服务，承担 ICT 风险、第三方依赖、事件报告、韧性测试与治理方面的责任（IBM）。

既然 Kubernetes 是未来，银行为何仍需要虚拟机？

银行仍在基于虚拟机的资产上运行关键系统，包括支付引擎、核心银行系统、交易应用与风险平台。统一的 VM／容器模型可减少重复，同时支持渐进式迁移（Red Hat）。

什么才是真正的云退出策略？

真正的退出策略包含依赖清单、数据导出流程、备选运行时方案、合同权利、恢复测试、密钥控制计划，以及关键服务迁移或恢复的现实时间表。

银行在云原生方面最大的错误是什么？

最大的错误是采用容器却未建立平台控制。如果 Kubernetes 提升了部署速度，却未强制执行身份、策略、审计、数据驻留、恢复与漏洞控制，那么它将放大风险，而非降低风险。

参考资料 #

最近审阅 。

最近审阅 .