v1.10版本kube-controller-manager内存OOM及配置后无法启动求助

碰到这种情况确实闹心，尤其是v1.10这种已经停止维护的老版本，先给你梳理几个可行的排查和解决方向：

一、先解决Pod无法重启的问题 #

你设置resource.limits.memory=1Gi后Pod起不来，大概率是资源配置不合理或者启动时的依赖问题，先做这几步：

• 先查Pod启动失败的具体原因：执行kubectl describe pod kube-controller-manager-<你的节点名> -n kube-system，看Events栏的报错信息，比如是不是内存限制设置得太低，导致进程启动时就内存不足；或者有没有配置语法错误（比如yaml缩进错了）。
• 调整资源配置：如果是内存限制过低，先临时调高到2Gi，同时一定要设置resource.requests.memory（比如512Mi），因为kube-scheduler需要requests来分配节点资源，而且没有requests的话，OOM Killer可能会优先干掉它。修改后的resources段大概是：

  resources:
    requests:
      memory: "512Mi"
      cpu: "200m"
    limits:
      memory: "2Gi"
      cpu: "1"
  

• 检查yaml文件的其他配置：比如command参数有没有被误改，或者volume挂载是否正常，这些都可能导致Pod启动失败。

二、排查内存持续飙升的根本原因 #

解决Pod启动问题后，得搞定内存泄漏的核心问题，针对v1.10版本，常见的诱因和解决方法：

• 清理集群内的冗余资源：大量过期的资源对象会让controller-manager持续同步状态，占用内存。比如：
  • 清理终止态Pod：kubectl get pods --all-namespaces --field-selector=status.phase=Terminated | awk '{print $1,$2}' | tail -n +2 | xargs kubectl delete pod -n
  • 清理无效的Ingress、ConfigMap、Secret：比如很久没使用的资源，用kubectl get ingress --all-namespaces排查后删除。
• 调整controller的并发同步参数：v1.10默认的并发同步数可能太高，导致同时处理大量任务内存暴涨。可以在kube-controller-manager的command里添加以下参数，调低并发数：

  --concurrent-service-syncs=5
  --concurrent-endpoint-syncs=5
  --concurrent-pod-syncs=5
  

  具体数值可以根据你的集群规模调整，比如小型集群调到3-5就行。
• 关闭不必要的controller：如果你的集群不需要某些controller（比如云厂商相关的cloud-node-controller，或者ttl-after-finished这类），可以用--controllers参数指定只启用需要的controller，减少内存占用。比如：

  --controllers=namespace,node,pod,service,endpoint,configmap,secret,statefulset
  

• 检查日志找泄漏点：执行kubectl logs kube-controller-manager-<你的节点名> -n kube-system --tail=200，看有没有重复出现的同步报错、资源循环创建的日志，v1.10版本的endpoint、service controller存在已知的内存泄漏问题，这类日志能帮你定位具体是哪个controller在搞事情。
• 临时兜底方案：如果暂时没法彻底解决，可以给Pod加个存活探针，当内存占用接近阈值时自动重启，避免OOM导致系统卡顿。比如在yaml里添加：

  livenessProbe:
    exec:
      command:
      - sh
      - -c
      - 'test $(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) -lt 1800000000'
    initialDelaySeconds: 60
    periodSeconds: 30
  

  这个探针会每隔30秒检查内存，超过1.8Gi就重启Pod，给系统留缓冲空间。

三、长期建议 #

v1.10版本已经是非常老的版本了（2018年发布），官方早就停止维护，很多内存泄漏、稳定性问题在后续版本都已经修复。如果条件允许，尽快升级到v1.21+的稳定版本，这才是解决这类问题的根本办法。

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