仅使用Readiness Probe的弊端及Pod持续重启的影响咨询

• 资源无效消耗：kubelet会反复执行容器启动、初始化、销毁流程，持续占用节点的CPU、内存；如果容器镜像体积大，每次重启拉取镜像还会消耗网络带宽和节点存储资源。
• 局部服务不可用：若该Pod是服务的唯一实例，对应流量会持续报错；即使有其他实例，也可能因负载不均导致部分请求超时或失败。
• 监控告警过载：频繁的重启事件会触发大量重复告警，掩盖真正关键的告警信息，干扰运维人员对核心问题的判断。
• 日志排查难度提升：每次重启都会生成新的启动日志、错误日志，大量日志堆积后，很难快速筛选出有效信息定位根因；若未配置日志轮转，还可能占满节点磁盘。
• 状态数据丢失风险：使用emptyDir临时存储的Pod，重启会丢失存储内的所有数据；即便用了持久化存储，频繁重启也可能引发未完成事务回滚失败、数据读写异常等问题。

• 服务大面积瘫痪：如果Deployment/StatefulSet的多数或全部Pod同时重启，服务的处理容量会急剧下降，甚至完全无法响应请求，进而触发服务熔断或上下游链路雪崩。
• 集群资源耗尽：大量Pod同时启动、拉取镜像、执行初始化操作，会瞬间占满节点的CPU、内存、网络带宽，严重时会导致节点无响应，甚至影响集群内其他正常运行的服务。
• 服务发现与路由震荡：Pod频繁上下线会导致K8s Endpoints频繁更新，下游服务的负载均衡策略反复调整，可能出现请求路由到已下线Pod、流量分发不均等异常情况。
• 依赖服务压力骤增：Pod重启后通常会重新建立与数据库、缓存等依赖服务的连接，多个Pod同时重启会瞬间产生大量连接请求，可能压垮依赖服务，形成“Pod重启→依赖服务崩溃→更多Pod重启”的恶性循环。
• 根因排查效率低下：多个Pod同时报错会产生海量日志和事件，运维人员很难快速梳理出问题的核心触发点，大幅延长故障修复时间。

内容的提问来源于stack exchange，提问作者Hayi