3. 云原生基础设施选型
医疗云原生平台的底座选型，决定了后续所有工作负载的隔离强度、性能上限、合规边界与运维成本。这一节不讨论“哪个最好”，而是围绕医疗行业的真实约束——等保三级/四级、数据不出院、PACS 影像高吞吐、HIS 事务低延迟、7×24 可用——把四类选型决策拆开讲清楚：容器运行时怎么选、Kubernetes 发行版怎么选、裸金属与虚拟化怎么权衡、私有云与混合云如何划分边界。
一、容器运行时：从 Docker 到 containerd 与 gVisor/Kata
Kubernetes 自 1.24 起移除了 dockershim，运行时接口统一为 CRI。当前主流选择是 containerd 与 CRI-O：前者生态成熟、与 Docker 镜像格式完全兼容，是大多数发行版的默认；后者更轻量、更贴近 OCI 标准，常见于 OpenShift。两者在医疗场景下都属于“常规隔离”，共享宿主机内核。
当工作负载涉及多租户科研计算、第三方厂商提供的影像 AI 推理容器时，共享内核的隔离强度可能不足。此时可引入沙箱运行时：gVisor 通过用户态内核拦截系统调用，Kata Containers 则为每个 Pod 启动轻量虚拟机。代价是启动延迟与 I/O 性能下降，因此通常只对特定命名空间启用，而非全局替换。
一个可落地的做法是：默认 RuntimeClass 用 runc（containerd 内置），为 AI 推理与外部厂商镜像单独定义 kata 或 gvisor RuntimeClass，在 Pod spec 中通过 runtimeClassName 指定。这样既保留常规服务的性能，又对高风险负载加一层隔离。
二、Kubernetes 发行版：自建、托管与行业发行版
发行版选择的核心问题是：谁负责控制面生命周期。医疗私有云通常不允许控制面托管到公有云，因此常见三类：
- 上游 kubeadm 自建：控制面完全自控，适合已有较强 K8s 运维团队的医院信息中心。需要自行处理证书轮换、etcd 备份、版本升级。优点是零厂商锁定，缺点是运维负担重。
- Rancher RKE2 / K3s：RKE2 面向安全合规场景，默认启用 CIS 加固、支持 FIPS 模式，适合等保要求较高的私有云；K3s 精简，适合边缘节点（如影像科室前置机）。
- OpenShift / 华为 CCE / 浪潮云海等商业发行版：提供一体化安装、内置监控日志、合规基线，适合运维人力有限但预算充足的机构。代价是许可成本与一定程度的厂商绑定。
选型时可参考一个简单判据：若团队能独立完成 etcd 恢复演练与跨版本升级，自建或 RKE2 更划算；若更看重开箱即用的合规与可观测性，商业发行版更稳妥。医疗场景下，控制面高可用（至少 3 节点）与 etcd 定期快照是硬性要求，与发行版无关。
三、裸金属与虚拟化：性能、隔离与弹性的三角
裸金属直接运行操作系统与容器运行时，没有 Hypervisor 层，因此 CPU 指令、GPU 直通、NVMe 吞吐几乎无损耗。PACS 影像重建、AI 训练、高并发数据库这类负载，裸金属优势明显。虚拟化则在资源池化、快照回滚、故障迁移上更成熟，适合 HIS 这类需要快速恢复的事务系统。
实际医疗私有云往往是混合形态：核心数据库与 GPU 节点用裸金属，普通微服务与中间件跑在虚拟化集群上，再由同一套 Kubernetes 统一编排。Kubernetes 通过 nodeSelector、taint/toleration 把负载调度到对应节点池。例如给 GPU 裸金属节点打 node-role.kubernetes.io/gpu=true，AI 推理 Pod 通过 nodeSelector 绑定。
| 维度 | 裸金属 | 虚拟化 |
|---|---|---|
| 性能损耗 | 接近零，GPU/NVMe 直通友好 | 有 Hypervisor 开销，GPU 需 vGPU 或直通 |
| 隔离强度 | 物理隔离，最强 | 虚拟机级隔离，较强 |
| 弹性与迁移 | 扩容慢，需人工上架 | 快照、热迁移、快速扩缩容 |
| 典型医疗负载 | PACS 重建、AI 训练、核心数据库 | HIS 微服务、中间件、测试环境 |
四、医疗私有云与混合云架构边界
医疗数据分级是划分边界的依据。患者身份信息、诊断记录、原始影像属于敏感数据，必须留在院内私有云；脱敏后的统计、科研训练、非敏感运维监控可以放到公有云或专区。混合云的关键不是“连起来”，而是明确哪些数据可以出、以什么形态出、由谁审批。
典型架构是：院内私有云承载 HIS/PACS/EMR 与核心数据库，通过专线或 VPN 与云端 VPC 打通；云端只部署脱敏后的数据湖、模型训练与灾备副本。跨云网络建议使用独立的安全域，东西向流量做微隔离，南北向统一经 API 网关与审计。Kubernetes 层面可用多集群管理（如 Rancher Fleet、Karmada）统一策略下发，但数据面必须物理或逻辑隔离，不能为了管理方便把敏感命名空间调度到云端节点。
综合来看，医疗云原生的基础设施选型没有单一最优解：运行时按隔离需求分层，发行版按运维能力与合规要求取舍，裸金属与虚拟化按负载特征混布，私有云与混合云按数据分级划界。把这四条线对齐到同一张架构图上，后续的平台工程才有稳定的地基。