2. 医疗容器平台架构解析

医疗容器平台不是把 Kubernetes 直接搬进医院机房那么简单。它要在同一套底座上同时承载 HIS、LIS、PACS、EMR、互联网医院、医保结算等业务，既要满足临床 7×24 小时不间断，又要满足等保三级、数据不出院、患者隐私保护等合规要求。理解平台架构，关键是看清"分层职责、节点分工、网络与存储、高可用边界"这四件事。

一、典型分层架构

医疗容器平台通常划分为五层，自下而上依次是基础设施层、资源与编排层、平台服务层、业务应用层和统一运维层。

• 基础设施层：物理服务器、集中式存储（如 SAN）、分布式存储（如 Ceph）、负载均衡、防火墙与院内核心交换机。这一层决定平台的性能上限与故障域边界。
• 资源与编排层：Kubernetes 控制面、容器运行时（containerd）、CNI 网络插件、CSI 存储插件。它负责把物理资源抽象成可调度的 Pod 与 PVC。
• 平台服务层：镜像仓库 Harbor、日志采集、监控告警、服务网格、配置中心、CI/CD 流水线。这一层是运维工程师日常打交道最多的地方。
• 业务应用层：以命名空间隔离的各业务系统，如 ns-his、ns-pacs、ns-emr，每个命名空间绑定独立的资源配额与网络策略。
• 统一运维层：面向运维人员的门户，提供集群巡检、容量分析、变更审批与应急切换入口。

分层的意义在于故障隔离与责任划分：基础设施故障由机房与网络团队处理，编排层故障由容器平台团队处理，业务层故障由应用团队处理。若不分层，一次 PACS 影像调阅卡顿就可能被误判为"容器平台问题"，排查方向会完全跑偏。

二、管理节点与工作节点

管理节点（Control Plane）运行 kube-apiserver、etcd、kube-scheduler、kube-controller-manager。医疗场景下建议至少 3 台管理节点，etcd 独立部署在低延迟 SSD 上，避免与业务 Pod 混部。管理节点不承载业务负载，只负责"决策"。

工作节点（Worker Node）运行 kubelet、kube-proxy 和业务 Pod。医疗平台的工作节点通常按业务类型打标签，例如 node-type=pacs 的节点配置大容量本地盘与高带宽网卡，node-type=his 的节点则更强调低延迟与稳定性。通过 nodeSelector 与污点容忍，把影像类、数据库类、普通 Web 类负载分开调度，避免互相争抢资源。

一个常见的教学示例参数：某三甲医院平台配置 3 台管理节点（16C/32G/500G SSD）、12 台工作节点（其中 4 台 32C/128G 用于 PACS，8 台 16C/64G 用于 HIS 与 EMR），etcd 数据盘 IOPS 要求不低于 3000。这些数值属于合理假设，实际应以业务压测结果为准。

三、网络与存储组件

网络方面，医疗容器平台普遍采用 Calico 或 Cilium 作为 CNI。Calico 的 BGP 模式在院内扁平网络中性能好、排障直观；Cilium 基于 eBPF，适合需要细粒度网络策略与可观测性的场景。无论选哪种，都必须明确三点：Pod CIDR 不能与院内现有网段冲突；Service CIDR 要预留足够地址；跨节点通信要保证 MTU 一致，否则会出现"小包通、大包断"的典型故障。

存储方面，医疗业务对存储的需求差异极大。HIS 数据库要求低延迟块存储，通常通过 CSI 对接集中式 SAN；PACS 影像要求大容量、高吞吐，常用 Ceph RBD 或对象存储；配置文件与密钥则用 ConfigMap、Secret 管理。关键原则是：有状态业务必须使用 PVC，禁止把数据写在容器可写层。容器重启后可写层数据丢失，这在医疗场景中是不可接受的。

四、高可用设计要点

医疗平台的高可用不是"多副本"三个字能概括的，需要从四个层面分别设计。

控制面高可用：管理节点至少 3 台，etcd 集群奇数节点，跨机架或跨可用区部署。etcd 对磁盘延迟极其敏感，若与业务 Pod 混部，一次影像写入高峰就可能拖慢整个控制面，导致调度延迟甚至 apiserver 超时。

数据面高可用：无状态服务通过 Deployment 多副本 + 反亲和性分散到不同节点；有状态服务使用 StatefulSet，配合存储层的双活或异步复制。HIS 数据库若采用主从架构，需明确切换阈值与脑裂防护策略。

网络高可用：核心交换机与上行链路做冗余，CNI 层面避免单点。若使用 Calico BGP 模式，建议配置路由反射器，避免全互联带来的会话风暴。

存储高可用：集中式存储做双控双活，分布式存储设置合理的副本数（通常 3 副本）与故障域。PACS 影像若使用纠删码，需权衡空间利用率与重建时间。

五、某三甲医院平台架构案例拆解

以下案例为教学示例，用于说明架构决策思路，具体参数为合理假设。

该院原有 40 余套业务系统分散在 60 台虚拟机上，资源利用率不足 30%，扩容周期长，故障定位困难。平台改造后采用"两地三中心"思路：主数据中心承载 HIS、EMR、LIS 等核心业务，同城灾备中心承载 PACS 影像与互联网医院，异地中心仅做数据备份。

主数据中心部署 3 台管理节点、12 台工作节点，网络采用 Calico BGP 模式，Pod CIDR 规划为 10.244.0.0/16，Service CIDR 为 10.96.0.0/12，与院内原有 10.10.0.0/16 网段无冲突。存储方面，HIS 数据库通过 CSI 对接集中式 SAN，PACS 影像使用 Ceph RBD 池，配置 3 副本。

关键决策点有三个：第一，PACS 工作节点使用本地 SSD 做缓存，减少影像调阅时的网络往返；第二，HIS 命名空间设置资源配额上限，防止单个业务突发占用全部节点资源；第三，所有对外暴露的服务统一走 Ingress + 院内负载均衡，不直接使用 NodePort，便于审计与访问控制。

改造后，资源利用率提升至 65% 左右，新业务上线周期从两周缩短到两天，故障定位从"逐台登录排查"变为"看监控面板定位到 Pod 与节点"。这个案例说明：医疗容器平台的价值不在于用了多少新技术，而在于把资源、网络、存储、高可用这些基础能力标准化，让业务团队能安全、快速地交付。