一句话简介：医疗系统迁上信创底座，K8s 在国产 OS 上最易踩架构、驱动、镜像、审计这几类坑，这篇复盘 4 个取舍。

最近在给一家区域医院做影像云的信创底座迁移，作为医疗云原生架构师，K8s 一上国产 OS（麒麟/统信＋鲲鹏/飞腾）就状况不断。这次复盘让我把“能不能跑”和“跑得稳不稳”分开看清楚了，也踩出了几条可以复用的取舍。

一、先看清“能装”不等于“能跑”：镜像架构是第一道坎

1. ARM 平台最典型的就是 exec format error。官方镜像多只带 amd64，Pod 起不来先查镜像 manifest，确认有没有 arm64 版本，别急着怀疑代码。

1. 一个坑：鲲鹏 920 和飞腾 2500 都叫 aarch64，但部分内核特性和微码有差异，排查时先记下具体型号（lscpu、cat /etc/os-release），对外求助时才说得清。

1. 取舍：信创底座要早定多架构镜像策略，Dockerfile 用 buildx 做 multi-arch 推到私有仓库，避免上线后逐台补镜像。

二、cgroup 驱动要统一，别让 kubelet 反复重启

1. 麒麟 V10 的 systemd 版本较新，containerd 和 kubelet 的 cgroup 驱动宜统一用 systemd；用 cgroupfs 会出现 kubelet 反复重启、Pod 不断重建。

1. 同时确认 swapoff 已关闭、内核模块 overlay 和 br_netfilter 已加载（lsmod、modprobe），这些缺失会让节点 NotReady。

1. 取舍：把驱动统一和内核模块清单写进交付 checklist，作为信创节点入集群的准入项，而不是出问题再救火。

三、安全组件是隐形杀手：审计日志与国密仓库

1. 麒麟自带 audit 审计会大量记录 K8s 进程访问，/var/log/audit 容易爆满导致节点异常；要在审计规则里放行 K8s 相关目录，或定期清理。

1. systemd 的 StartLimitInterval 默认限制服务重启频率，kubelet 初始化失败会进 failed 状态并被限频，先排查再重试，别连着点重启。

1. 最隐蔽的一坑：国产 OS 常默认启国密 TLS 栈（SM2/SM3/SM4），标准 kubelet 可能握不上国密镜像仓库（Harbor/SWR 国密实例），报 ImagePullBackOff 或 x509 签名失败，最容易被误判成网络故障。

四、别把兼容性坑甩给版本问题：用准入清单把风险前置

1. 经验：信创 K8s 部署宜先单节点跑通核心链路（拉镜像、起 Pod、过 Service）再做多节点，别一上来就铺全量集群。

1. 落地取舍：把上面几类坑固化成信创节点准入清单（架构、驱动、内核模块、审计、国密仓库）加冒烟脚本，每次新环境先跑一遍。

1. 运维价值：这套清单既能服务影像云，也能复用到 HIS/EMR 的信创化，是可复用资产，比个人救火经验更值钱。

亮点/结论（可操作建议）

信创 K8s 的坑集中在平台层而非应用层：镜像架构、cgroup 驱动、审计与国密策略、国密镜像仓库四条主线。把单节点跑通、准入清单、冒烟脚本固化成流程，比靠个人救火靠谱得多，也更容易复制到下一个医院项目。面向 2027《数智医院建设与应用评价标准》把信创纳入评级红线，底座能否跑得稳会直接影响评级，这笔投入值得前置。