1. 医疗容器平台运维工程导论

医疗行业的 IT 系统长期处于一种“高约束、低容错”的运行环境：门诊挂号、医嘱下达、检验检查、影像调阅、医保结算等业务链路彼此耦合，任何一次服务中断都可能直接影响患者诊疗。容器化之所以在医疗行业快速落地，并不是因为技术潮流，而是因为它能在资源利用率、交付一致性、弹性扩缩和灰度发布上提供可量化的收益。但医疗场景又给容器平台叠加了额外约束：数据必须可追溯、变更必须可审计、患者隐私必须可控、关键业务必须可回退。理解这些约束，是理解“医疗容器平台运维”与通用容器运维差异的起点。

一、医疗行业容器化的背景与驱动力

传统医疗信息系统多采用“一业务一虚拟机”的部署方式。以一家三级医院为例，HIS、LIS、PACS、EMR、集成平台、医保接口等系统往往各自占用独立虚拟机，CPU 平均利用率长期低于 15%，而影像类业务在高峰期又会出现内存与存储 IO 瓶颈。容器化带来的第一个直接变化是资源池化：通过 Kubernetes 的 requests/limits 与调度策略，把多个无状态服务（如前置机、接口适配、报表服务）合并到同一节点池，典型可将节点数量压缩 30%～50%。

第二个驱动力是交付一致性。医疗软件供应商众多，同一套应用在不同医院、不同版本的操作系统与中间件上经常出现“环境差异型故障”。容器镜像把运行时、依赖库、配置基线固化下来，使“开发—测试—生产”三套环境的差异收敛到镜像标签与配置项两个维度。第三个驱动力是灰度与回滚能力：医保政策调整、电子病历评级改造等场景要求快速上线并可控回退，Kubernetes 的 Deployment 滚动更新与 ReplicaSet 历史版本，使回滚从“重新部署虚拟机”缩短到“切换镜像标签”。

二、平台运维的核心职责

医疗容器平台运维不是“会敲 kubectl”即可胜任，它的职责可以拆成四个层面。第一层是平台可用性：保障 API Server、etcd、调度器、网络插件、存储插件、Ingress 等基础组件稳定，明确各组件的高可用拓扑与故障域。第二层是业务交付：把医院信息科与供应商的应用需求翻译成 Namespace、Deployment、Service、ConfigMap、PVC、HPA 等对象，并保证资源配额、亲和性、探针、优雅停机等配置符合业务等级。第三层是可观测与应急：建立指标、日志、链路、事件四类数据的采集与告警，形成“发现—定位—止损—复盘”的闭环。第四层是合规与安全：镜像来源可信、密钥不落盘明文、审计日志留存、网络策略最小化、患者数据访问可追溯。

三、与通用容器运维的关键差异

通用互联网场景强调弹性与吞吐，医疗场景强调确定性与可追溯。差异主要体现在五个方面：

• 变更窗口：互联网可随时灰度，医疗核心业务通常只能在夜间或指定维护窗口变更，且需提前报备。
• 数据敏感性：患者信息属于敏感数据，日志中不得出现明文身份证号、手机号、诊断信息，采集链路需脱敏。
• 可用性等级：挂号、医嘱、收费等属于关键业务，通常要求多副本、跨节点反亲和、PodDisruptionBudget 保护。
• 依赖复杂性：医疗系统常依赖专用硬件接口、加密狗、老版本中间件，容器化时需要额外适配。
• 审计要求：谁在什么时间改了什么配置、发布了哪个镜像，都必须可查，RBAC 与审计日志是硬性要求。

下面这张图把医疗容器平台从底层基础设施到业务负载的分层关系，以及运维关注点与合规约束的对应位置做了结构化表达，便于建立整体认知。

四、课程学习路径与实战环境

本课程围绕“认知—搭建—交付—观测—应急—合规”的主线展开，共 30 章。前段建立医疗容器平台的整体模型与差异认知；中段进入集群搭建、命名空间规划、工作负载交付、存储与网络配置；后段聚焦监控告警、日志审计、故障排查、灰度回滚与安全合规。每一章都尽量给出可复现的对象、参数与判断依据，而不是停留在概念描述。

实战环境建议采用一套最小可用但贴近生产的拓扑：3 台控制平面节点（4C8G，etcd 独立数据盘）、3 台工作节点（8C16G，其中 1 台带 SSD 用于影像类 IO 密集负载）、1 台镜像仓库与 1 台跳板机。操作系统统一为 Rocky Linux 9 或 Ubuntu 22.04，容器运行时使用 containerd，Kubernetes 版本建议 1.28 及以上。网络插件可选 Calico 以支持 NetworkPolicy，存储可先用 local-path 或 NFS 做教学验证，再过渡到 Ceph 或商业存储。

# 示例：查看节点与命名空间规划（教学环境）
kubectl get nodes -o wide
kubectl get ns
kubectl describe node worker-01 | grep -A5 "Allocated resources"

# 示例：为关键业务设置多副本与反亲和
kubectl -n his get deploy his-register -o yaml | grep -E "replicas|podAntiAffinity"

需要强调的是，以上参数属于教学示例，真实医院环境应根据业务等级、预算与现有基础设施调整。学习过程中建议每章都保留一份“变更记录”，记录改了什么对象、关键参数、观察到的现象与结论，这本身就是医疗运维可审计习惯的训练。