-
每次滚动发布都有几分钟大量 502、半夜还莫名其妙被重启,我查到底才发现是 K8s 的就绪探针没配、存活探针又配得太敏感:一次健康检查探针配置失当、把自愈机制配成故障源的深度复盘
我们的服务跑在 K8s 上,出了两个看似不相关的问题:每次滚动发布都有几分钟接口大量报 502/连接被拒,以及有些 Pod 半夜莫名被 Killed 重启(没崩溃没 OOM)。查到底发现根因都在健康检查探针,且是两个相反方向的错:一是没配 readiness 探针,K8s 不知道 Pod 何时就绪、容器一启动就把流量打进来而应用还没就绪所以 502;二是 liveness 探针配得太敏感(time…- 0
- 0
-
一个 liveness 探针配置得又急又严、还去查下游的服务,在启动慢或下游抖动时被 Kubernetes 反复 kill 重启,陷入 CrashLoopBackOff:一次健康检查配置不当的深度复盘
服务部署后反复重启、状态 CrashLoopBackOff,可进到容器里看进程其实是活的、并没崩。根因是 liveness 探针配错:一是 initialDelaySeconds 太短,服务启动慢、还没就绪就被探测失败、被反复 kill;二是 liveness 端点去查了数据库/下游,下游一抖动健康检查就失败、把本来好好的服务也 kill 了。本文讲透 liveness(要不要重启,轻量只看进程自…- 3
- 0
-
我每次发布服务都有一两分钟大量 502、用户骂声一片,可实例明明都起来了,我对着 K8s 健康检查探针的配置排查了大半天的复盘
负责的一个跑在 K8s 上的服务,功能没问题,可每次滚动发布都有一两分钟大量 502/503,用户骂声一片,过一两分钟又恢复。一开始以为是发布的必然抖动,越想越不对:滚动发布不就是为了不中断吗?新实例起来才切流量啊怎么还502?排查大半天才理解 K8s 健康检查探针的门道和我没配 readiness 探针的致命疏忽:没配 readiness 时,K8s 只看进程起没起来判断就绪,进程一启动就切流量…- 0
- 0
-
Kubernetes 探针完全指南:从一次"健康的 Pod 被反复重启"看懂 liveness 与 readiness
2023 年初我们把核心订单服务迁上 Kubernetes,照教程给每个服务都配了 liveness probe——"探活嘛,容器死了 K8s 帮你重启"。大促那天流量上来,服务明明还在正常成交订单,Pod 却开始成片 CrashLoopBackOff:被反复 kill、反复重启,重启中的 Pod 不接流量,活着的扛更多压力变得更慢,它们的探针也开始超时被 kill,十分钟内整…- 0
- 0
readiness
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×