容器化部署过程中服务中断了怎么办？如何进行有效分析？
容器化部署中的服务中断，多数不是容器“自己不稳”，而是发布变更、探针配置、资源调度和监控告警链路没有形成闭环；按发布层、Pod层、节点层、依赖层拆开排查，再用自动化回滚和复盘闭环，才能把影响压到最小。 下面按SRE值班时的顺序展开，命令可以先在测试环境验证，再用于生产。
容器化部署服务中断原因分析：先确认故障发生在哪一层
服务中断时最怕一上来就重启。先看变更和事件，能少走很多弯路。容器化把故障边界打碎了，一个镜像标签、一个探针参数、一个节点磁盘满，都可能表现成“服务挂了”。
发布层：滚动更新最容易“看起来没事”
滚动更新默认逐步替换Pod，旧Pod还没摘干净，新Pod可能已经接流量。常见坑是readinessProbe配得太松或太紧。太松，坏Pod被加入Endpoints；太紧，健康Pod被反复摘除。preStop和terminationGracePeriodSeconds不匹配，也会让连接被硬断。
- 01看发布状态
kubectl rollout status deployment/业务名 -n prod，
- 02看事件
kubectl get events -n prod –sort-by=.las
- 03看上一轮日志
kubectl logs Pod名 -n prod –previous，容器重启
- 04查探针
livenessProbe失败会触发重启，startupProbe缺失会让慢启动服务被误杀。
- 05查中断预算
PDB、maxUnavailable、maxSurge要和业务副本数匹配。单副本业务做滚动更
生产环境容器化滚动更新中断怎么排查
值班时按“止血—定位—验证”走，不要边猜边改。
- 先暂停发布：kubectl rollout pause deployment/业务名 -n prod。如果新版本明显异常，直接kubectl rollout undo deployment/业务名 -n prod。
- 看Pod是否Ready、重启次数、所在节点：kubectl get pods -n prod -o wide。再看Endpoints/EndpointSlice是否有健康实例。
- 查资源与调度：kubectl describe pod Pod名 -n prod，重点看OOMKilled、Evicted、FailedScheduling、镜像拉取失败。
- 查节点：kubectl get nodes，节点NotReady、磁盘压力、PID压力都会放大中断。节点上可用crictl ps和dmesg -T | grep -i oom辅助确认。
- 查依赖：DNS、Service、Ingress、数据库连接池、消息队列。容器重启不一定根因在容器里。
- 验证恢复：看SLO错误率、P99延迟、5xx、Pod Ready数、重启次数是否回落，再结束故障。
监控告警要覆盖“变更后信号”。只盯容器CPU不够。把Pod Ready数、重启次数、Endpoints数量、5xx比例、P99延迟、OOMKilled、节点NotReady放进同一看板，告警按影响分级。发布窗口内对已知抖动做抑制，但要保留升级路径。
容器化部署与虚拟机部署服务中断对比：SRE更该盯什么
容器化没有消灭中断，只是把中断从“机器坏了”更多转移到“变更和配置”。行业共识认为，容器环境的故障传播更快，因为副本、服务发现和发布动作都高度自动化。自动化越快，错误配置的扩散也越快。
| 维度 | 容器化部署 | 虚拟机部署 | 对中断的影响 |
|---|---|---|---|
| 故障边界 | Pod、节点、控制器、服务发现多层联动 | 以主机和进程为主 | 容器问题更容易跨层传播 |
| 发布方式 | 滚动更新、金丝雀、蓝绿 | 停机替换或负载均衡切换 | 容器发布快，回滚也要快 |
| 健康检查 | readiness/liveness/startup探针 | 脚本或负载均衡探测 | 探针错配会直接摘流或重启 |
| 资源隔离 | requests/limits、cgroup | 主机规格和进程限制 | 资源不足会引发OOM和驱逐 |
| 监控重点 | Pod状态、端点、重启、SLO | 主机指标、进程、端口 | 容器要更关注“服务可用”而非只看机器 |
对比之后，SRE的动作要变：发布前检查资源请求、探针、PDB和回滚路径；发布中看端点和错误率；发布后做短窗口观察。别把虚拟机时代的“登录机器看进程”直接搬到容器里。
华东地区容器化监控告警方案怎么落地
华东地区不少团队是多集群、混合云、跨可用区部署，值班和合规要求更细。落地时别先堆工具。先把指标、日志、链路和事件四类数据打通，再按业务SLO配告警。指标用Prometheus系采集，日志