部署72个PCG副本时KubeAPI服务崩溃问题排查求助

一、故障原因排查方向 #

• KubeAPI资源瓶颈
  • 部署副本过程中，通过kubectl top nodes（集群需启用metrics-server）或直接查看节点上kube-apiserver容器的监控数据，确认是否出现CPU打满、内存耗尽触发OOM被系统终止的情况。
  • 查看KubeAPI日志：执行journalctl -u kube-apiserver -f（systemd环境）或kubectl logs -n kube-system kube-apiserver-<节点名称>，聚焦崩溃前的报错信息，重点排查OOM提示、请求过载、连接超时等内容。
• PCG Pod资源配置缺失
  • 检查PCG的Deployment YAML文件，确认是否未设置resources.requests和resources.limits：无资源限制的72个副本可能无节制抢占节点资源，导致KubeAPI所在节点的网络、计算资源耗尽。
  • 统计单个PCG Pod的实际资源占用，判断72个副本的总资源需求是否超出集群承载阈值。
• 集群网络栈过载
  • 检查CNI插件状态：大规模Pod创建时，CNI若无法快速完成网络接口配置，会导致节点网络栈拥堵，中断KubeAPI与集群组件的通信。
  • 查看节点连接数：执行ss -s统计TCP/UDP连接总量，确认是否因大量Pod启动导致连接数耗尽，使KubeAPI无法处理新请求。
• ETCD存储压力过载
  • 检查ETCD状态：执行etcdctl endpoint status查看集群健康度，同时查看ETCD日志，排查是否存在磁盘IO超时、慢查询、存储配额不足等问题——大量副本创建会产生密集的API请求，若ETCD性能不足会阻塞KubeAPI，最终引发崩溃。

二、对应解决方案 #

• 优化KubeAPI资源与限流配置
  • 调整kube-apiserver静态Pod的资源配额：在/etc/kubernetes/manifests/kube-apiserver.yaml中，增加resources.requests和resources.limits的CPU、内存配置，例如：

    resources:
      requests:
        cpu: "2"
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "8Gi"
    

  • 启用请求限流：添加--max-requests-inflight=1000、--max-mutating-requests-inflight=200、--request-timeout=60s等参数，限制并发请求数，避免瞬间过载。
• 规范PCG Pod资源管理
  • 为PCG Pod设置合理的资源请求与限制：根据单个Pod的实际占用，配置如下示例（需根据业务调整）：

    resources:
      requests:
        cpu: "100m"
        memory: "256Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"
    

  • 采用分批部署策略：通过kubectl scale deployment <pcg-deployment-name> --replicas=20逐步提升副本数，每次扩容后观察集群状态，避免瞬间压力冲击。
• 优化ETCD与集群网络
  • 升级ETCD存储介质至SSD，调整--quota-backend-bytes扩大存储配额，定期执行etcdctl compact $(etcdctl endpoint status --write-out="json" | jq -r '.[0].revision')压缩历史数据，降低存储压力。
  • 优化CNI配置：若使用Calico，调整IP池规划减少路由冲突；若使用Flannel，优化VNI与转发规则，提升大规模Pod创建时的网络处理效率。
• 集群节点扩容
  • 若集群总资源无法支撑72个PCG副本的运行，新增工作节点分散资源负载，避免单个节点资源耗尽影响KubeAPI的正常运行。

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