容器运维代码评审该盯住哪些细节
容器里的程序最终要面对的是调度、网络、资源限制和终止信号。一次业务功能改动，可能因为探针写法、连接关闭顺序或配置默认值，在滚动发布时放大成可用性问题。评审不能只读业务函数，还要沿着进程从启动到退出的路径检查。
启动与健康状态要分开
启动探针解决“应用还在初始化，暂时不要判死”的问题；就绪探针表示“现在可以接新流量”；存活探针用于判断进程是否卡死。它们不应互相替代。就绪检查最好快速、稳定，避免每次都做昂贵的全量依赖检查。是否把数据库等依赖纳入就绪条件，要按服务在依赖不可用时是否仍能安全接流量决定。
var accepting atomic.Bool func ready(w http.ResponseWriter, _ *http.Request) { if !accepting.Load() { http.Error(w, "draining", http.StatusServiceUnavailable); return } w.WriteHeader(http.StatusOK) }这只表示服务自己的接流量状态。外部依赖故障应通过独立指标和请求错误来观测，不能轻易让所有副本同时被摘除。探针路径也应避免认证重定向、缓存污染和大量日志。
终止时先停止接入，再处理在途请求
收到SIGTERM后，应用应立刻把就绪状态切换为失败，停止消费新任务或接收新连接，再在 Kubernetes 的宽限期内完成已有请求。HTTP 服务器需要设置读取、写入和关闭超时；后台 goroutine 要监听 context 取消并退出。不要只捕捉信号然后无限等待，也不要假设 Endpoint 更新会在同一时刻完成。
队列消费者还要考虑消息确认顺序：任务真正成功后才确认；退出时停止拉取新消息，并把来不及处理的工作交还队列或记录为可恢复状态。用一次真实的滚动升级演练来验证，而不是仅依赖单元测试。
资源限制和配置需要可解释
为 CPU 和内存设置 requests 与 limits，并根据运行时语言选择合适的并发、堆内存和连接池配置。Go 运行时版本不同，对 cgroup 的识别与内存行为也不同；不要把某个环境变量当成所有镜像通用的修复。监控 OOM、GC、线程数、文件描述符、连接池等待和 throttling，才能判断限制是不是合理。
评审时还要检查镜像是否以非 root 用户运行、临时目录是否可写、配置和密钥是否从受控来源读取、日志是否包含敏感信息。最后把失败路径列出来：探针失败、优雅退出超时、依赖变慢、节点驱逐时系统分别怎样表现。容器化不替应用处理这些边界，代码必须自己说清楚。
对于多副本服务，评审还应看会话、定时任务和缓存是否依赖单实例假设。滚动更新时，旧新版本会短暂共存；任何共享锁、leader 选举或后台清理逻辑都要能安全度过这段时间。把验证场景写进自动化测试或演练脚本，才能避免经验只留在某个人脑中。
