凌晨两点，容器又重启了：容器化部署技术里那些不体面的细节

凌晨两点，告警群里蹦出一行红字。某业务 Pod 重启次数：17。值班同事发了个问号，又补一句：“今晚没发版啊。”我盯着监控，脑子里先冒出来的不是 Kubernetes，是南京软件大道那栋楼里永远不关的灯。容器化部署技术平时像水电，一出事才发现，水管里全是细节。

容器化部署技术，说白了，把应用和依赖装进镜像，运行时切成隔离进程，再交给编排器排布。镜像像装箱单，容器像正在跑的进程。它不是缩小版虚拟机。它帮你解决环境一致性、弹性扩缩和发布节奏，不负责把烂代码变好。这个期待错位，很多故障都从这儿开始。

那个 OOM，真不一定是流量涨了

那个 Java 服务挂了。监控上容器内存一条直线顶到 512Mi，然后 Killed。日志里没堆栈，只有冷冰冰的退出码。有人问是不是流量涨了。我看了一眼 QPS，平稳得很。真正的原因在于 JVM 堆没设上限，容器 limits 又卡得紧，GC 还没喘完，内核先终止了进程。

requests 是调度依据，limits 是运行时上限。这两者并不相同。requests 写小了，节点塞太多 Pod，大家挤在一起；limits 写小了，应用一抖就 OOMKilled。Kubernetes 只告诉你它死了，像医生只说你病了，病因得自己翻。后来加 -XX:MaxRAMPercentage=75，把 limits 调到 1Gi，再把 JVM 指标接进监控，才消停。

内存账单这事，很多人只盯容器指标，不看进程内部。Java 堆、元空间、直接内存、线程栈，全在 limits 里算总账。你给 512Mi，堆设 480Mi，剩下的空间一挤就炸。Node 上的 kubelet 不管这些，它只看 cgroup。能怪谁？只能怪配置时太乐观。

镜像不是压缩包，Dockerfile 里藏着构建时间

镜像这事更让人头疼。南京有个团队，Java 服务镜像 1.4G，构建一次 8 分钟。Dockerfile 开头就是 COPY . .，然后 mvn package。改一行注释，缓存全废，依赖重新下。像出门先把整衣柜塞进行李箱，再找袜子。

镜像分层、联合文件系统、构建缓存，原理不玄。每条指令一层，层能复用就复用。把 pom.xml 先拷进去，跑依赖下载，再拷源码，改代码只重建后面几层。构建从 8 分钟掉到 90 秒。再配 .dockerignore，把 target、.git、日志踢出去。多阶段构建把编译环境和运行环境拆开，镜像能瘦一圈。

镜像分层缓存会因一条 COPY 顺序全部失效。还有 latest 标签，图省事，回滚时谁都说不清跑的是哪版。镜像扫描、非 root 用户、密钥别塞进镜像，这些看似苛刻，实际上是关键保障。镜像仓库像衣柜，塞太多不穿的衣服，找起来要命，传起来也慢。

探针配错，滚动发布就像开盲盒

滚动发布 502，查半天，是 readinessProbe 的 initialDelaySeconds 给了 5 秒。Spring 启动要 20 秒。流量提前打进来，当然接不住。后来加 startupProbe，给慢启动应用留缓冲。startupProbe 是给慢启动应用留的缓冲，别拿 livenessProbe 勉强应付。liveness 配太激进，应用还在初始化就被判死，重启循环，越重启越慢。

优雅停机也常被忽略。preStop 里 sleep 几秒，让负载均衡先把流量摘干净。不然 Pod 都退了，请求还在路上。配置变更更隐蔽：ConfigMap 改了，环境变量注入的容器不重启不生效。有人改完配置说没变化，其实 Pod 还是老样子。

存储这块，有状态服务容器化要谨慎。PVC 挂了，节点故障漂移，本地卷绑定原节点，新 Pod 直接 Pending。数据库不是不能跑容器，是得把备份、拓扑、故障转移想清楚。网络也是，Service DNS 方便，NetworkPolicy 不配，默认横向全通。安全组在集群里不是自动长出来的。

容器化部署技术的边界，别拿它当万能胶

容器化部署技术不是万能胶。共享内核，隔离没虚拟机那么硬。内核调优、GPU 直通、高 IO 密集场景，得看具体负载。资源 requests 写得太虚，节点看着有空，调度器不敢放，碎片一堆。成本不是只有账单，还有排障时间。

常见误解一抓一把。容器不是虚拟机；镜像小不等于启动快；无状态不是随便删；编排器不是魔法。它像地铁，准时靠调度、轨道和信号系统，不是把车刷成银色就完事。

凌晨那场故障收尾时，天已经蒙蒙亮。楼下早点摊开始冒热气。我把 Dockerfile、资源限制、探针配置挨个过了一遍，心里清楚，容器化部署技术的体面，不在发布会 PPT 里，在这些不体面的细节里。