-
我的 Pod 部署上去就一直 CrashLoopBackOff 反复重启,我盯着它在不停重启这个现象查了半天毫无头绪,后来才知道要去看它崩溃那一刻的日志而不是它正在重启时的状态的深度复盘
我把新服务部署到 K8s,Pod 一直 CrashLoopBackOff:容器启动几秒就退出、被重启、又退出,反复循环,退避间隔越拉越长,服务始终起不来。我一开始盯着它在不停重启这个现象查:看事件、调重启策略、加资源、改健康检查,折腾半天毫无头绪。直到同事提醒:别盯着它正在重启看,要看它崩溃那一刻报了什么——用 kubectl logs --previous 看上一个已崩掉容器的日志。一看真相立刻…- 3
- 0
-
一个 liveness 探针配置得又急又严、还去查下游的服务,在启动慢或下游抖动时被 Kubernetes 反复 kill 重启,陷入 CrashLoopBackOff:一次健康检查配置不当的深度复盘
服务部署后反复重启、状态 CrashLoopBackOff,可进到容器里看进程其实是活的、并没崩。根因是 liveness 探针配错:一是 initialDelaySeconds 太短,服务启动慢、还没就绪就被探测失败、被反复 kill;二是 liveness 端点去查了数据库/下游,下游一抖动健康检查就失败、把本来好好的服务也 kill 了。本文讲透 liveness(要不要重启,轻量只看进程自…- 3
- 0
-
服务一直在 CrashLoopBackOff,可它根本没崩——是 k8s 的存活探针,在它启动还没完成时就把它"杀"了的复盘
服务部署到 k8s 上一直 CrashLoopBackOff,起一下就被杀、重启,永远起不来。可查应用日志根本没有崩溃报错——它只是在正常但缓慢地启动(要 40 多秒)。describe pod 才揪出真凶:是存活探针把它"杀"了。我把 initialDelaySeconds 设成了 10 秒,服务才启动 10 秒、端点还不通,探针就来探测、连续失败、判定"死亡&qu…- 4
- 0
CrashLoopBackOff
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×