Pgpool Pod运行1天后进入CrashLoopBackOff状态求助

问题概述 #

• 部署架构：1副本pgpool搭配1副本postgresql
• 故障现象：正常运行1天后进入CrashLoopBackOff状态，容器启动时触发OOM-killed错误
• 矛盾点：容器内存限制为500Mi，实际运行仅占用约150MB，节点内存利用率仅20%

关键报错信息 #

failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: container init was OOM-killed (memory limit too low?): unknown

排查方向与解决方案 #

1. 初始化阶段内存峰值 #

容器运行时内存稳定，但初始化过程（脚本执行、依赖加载、配置处理）可能出现短暂内存峰值，超过500Mi限制：

• 临时解决：上调pgpool容器内存限制至768Mi或1Gi，观察是否正常启动
• 验证：启动后通过kubectl top pod查看内存使用曲线，确认初始化阶段峰值

2. Kubernetes内存分配与QoS影响 #

当前Pod为Burstable QoS（内存请求300Mi、限制500Mi），节点内存分配策略可能导致容器实际可用内存低于配置值：

• 尝试将内存请求与限制设为相同值（如500Mi），消除Burstable模式的内存波动
• 检查节点kubelet配置，确认是否存在--reserved-memory等参数占用节点内存，挤压容器可用空间

3. Bitnami镜像初始化脚本消耗 #

Bitnami pgpool镜像启动时会执行初始化脚本，处理配置、连接后端库时可能出现内存突增：

• 开启调试模式：将环境变量BITNAMI_DEBUG设为true，重启容器查看初始化日志，定位高内存步骤
• 临时调整子进程配置：将PGPOOL_NUM_INIT_CHILDREN临时调低至1，启动后再恢复原配置

4. Runtime或镜像版本问题 #

• 升级pgpool镜像至最新版本（当前为4.5.0-debian-11-r8），修复潜在的初始化内存泄漏或峰值bug
• 检查节点上containerd/runc版本，排查是否存在已知的内存计算或OOM误报问题，必要时升级runtime组件

5. 探针配置触发提前OOM #

就绪探针delay=5s可能在容器未完成初始化时就执行，探针内存消耗叠加初始化内存触发OOM：

• 临时调整就绪探针initialDelaySeconds至60s，给容器充足初始化时间
• 先禁用就绪探针，启动成功后再恢复配置

快速验证步骤 #

1. 临时上调内存限制：

kubectl patch deployment pgha-pgpool --set "spec.template.spec.containers[0].resources.limits.memory=768Mi"

2. 查看启动日志：

kubectl logs -f pgha-pgpool-cf54985bb-lbxns -c pgpool

3. 启动成功后观察内存使用：

kubectl top pod pgha-pgpool-cf54985bb-lbxns

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