Kubernetes疑难问题总结一

• 分析ExitCode定位Pod异常退出原因

    查看ExitCode

    使用kubectl describe pod查看到pod对应退出状态码，如果不为0，表示异常退出

    退出状态码区间，0-255，0表示正常退出

    外界中断将程序退出的时候状态码区间是129-255

    程序自身原因导致的异常退出状态码区间在1-128

    常见异常状态码：

        137：被SIGKILL中断信号杀死，常为内存溢出，CPU达到限制，在describe pod中的表现就是OOMKilled

• 容器内抓包定位网络问题

    在kubernetes中运行容器应用，当容器应用中没有一些常见的问题盘查命令，出现问题后是很难定位的，这个时候，我们就能进入容器的网络命名空间netns，再使用宿主机上的命令进行问题排查。

    解决方法：

        1、kubectl get pod -o wide查看到应用所在主机节点

        2、在应用所在主机节点上docker ps | grep 应用名，定位到应用docker容器，获取docker id

        3、docker inspect -f {{.State.Pid}} docker-id获取到应用容器对应的进程pid

        4、nsenter -n -t pid进入容器网络命名空间，进行curl，tcpdump，ping等抓包排查操作

• PID耗尽

    检查当前PID限制

    [root@k8s-master1 ~]# cat /proc/sys/kernel/pid_max 

    32768

    [root@k8s-master1 ~]# cat /proc/sys/kernel/threads-max 

    14531

    检查系统当前进程数量，若超过内核限制则会导致进程无法启动，可以通过调整最大阈值解决

    ps aux | wc -l

    解决方法：

        echo "kernel.pid_mac=65535" >> /etc.sysctl.conf && sysctl -p

        echo "kernel.tjreads-max=65535" >> /etc/sysctl.conf && sysctl -p

• 内存碎片化

    内存分页失败，内核日志报错如下

    page allocate failure

    无法申请到内存，pod就会一直维持在ContainerCreating状态

    内存碎片化过多会导致，即便现在看上去系统内存很多，但是无法申请到大块的内存给进程使用，系统就会一直杀掉一些进程来释放内存，导致OOM

    解决方法：

        周期性进行drop cache操作

        echo 3 > /proc/sys/vm/drop_caches

• 磁盘爆满
  容器运行时的磁盘爆满会导致docker无响应，docker Hang住，kubelet日志也能看到PLEG unhealthy，因为CRI调用timeout，就无法创建或者销毁容器，一直处于ContainerCreating以及Terminating。如果kubelet所在目录磁盘空间不足，Sandbox也会创建失败。
  关注路径/var/lib/docker /var/lib/kubelet
  解决方法：
      手动删除docker log文件，不要将容器日志写在容器内，需要另外挂载数据盘
      清理docker无用数据docker system prune -a
      设置正确的kubelet gc机制
      给docker设置日志归档配置，只保留固定大小的日志内容
• Node NotReady
  kubelet，docker异常都会导致Node NotReady
  解决方法：
      查看docker响应速度是否正常，查看节点是否有大量日志写入，iotop，pidstat进行定位分析
      查看kubelet日志journalctl -u kubelet
• Pod一直处于Terminating，ContainerCreating，Error，ImagePullBackOff，Pending，Unknown状态
  Terminating
      进程通过bash -c启动导致kill信号无法传递给进程
      进程还存在挂载点，被其他进程占用或者写入，无法卸载
  解决方法：
      停止数据写入，释放挂载点
  ContainerCreating
      解决方法：
          检查镜像正确性
          挂载volume失败
          磁盘满了，容器创建失败
          节点内存碎片化
          拉取镜像失败
          CNI网络错误：检查运行节点网络组件是否正常
          查看controller-manager是否正常
  Error
      解决方法：
          说明Pod启动过程产生错误
          依赖的ConfigMap，Secret，Volume产生错误
          违反集群设置的安全策略，比如违反了PodSecurityPolicy等
  ImagePullBackOff
      解决方法：
          镜像拉取失败，认证失败，镜像不存在等
          docker默认以https类型的registry拉取。，如果不支持https则必须配置非安全认证docker，如果时https类型，则dockerd会校验registry的证书，在/etc/docker/cert.d/<registry:port>/ca.crt
          如果镜像需要认证，但是没有配置ImagePullSecret也会拉取失败
          镜像拉取超时中断管，查看镜像仓库前面的负载均衡保持长连接的超时时长，进行调整
  Pending
      解决方法：
          容器没有足够的CPU,内存资源进行调度
          nodeSelector，污点容忍，亲和性不匹配
          kube-scheduler异常导致
    Unknown
        通常时节点失联，没法与apiserver通信，到达阈值后，controller-manager认为节点失联，并将其状态置为Unknown
        解决方法：
            查看节点kubelet状态
• 容器进程主动退出
      容器进程主动退出，不是被外界中断杀死的话，退出码一般在0-128，一般都是业务程序的bug
      容器启动强依赖于第三方应用以及coredns解析失败，导致的应用重启
• Apiserver响应慢
      查看apiserver日志具体问题具体分析
      通过VIP访问缓慢，有可能时VIP对应的nginx，LVS异常，可以通过kubectl get pod -s apiserver:8080绕过负载均衡进行验证
• Namespace Terminating
      解决方法：
          Namespace上存在Finalizers，将其清理后就可以正常删除
          高版本的k8s集群不支持在线修改finalizers删除ns，要使用如下方法
         curl -H "Content-Type: application/json" -XPUT -d '{"apiVersion":"v1","kind":"Namespace","metadata":{"name":"delete-me"},"spec":{"finalizers":[]}}' http://localhost:8001/api/v1/namespaces/delete-me/finalize
• cgroup泄露

        在低版本内核（3.10）中，一旦开启了cgroup，就可能会导致不能彻底清理memcg和对应的cssid，也就是说应用即使删除了cgroup（/sys/fs/cgroup/memory下对应的cgroup目录）但在内核中没有释放cssid，导致内核认为的从group实际数量不一致。这个问题会导致容器创建失败，因为创建容器会为其创建cgroup进行隔离，而低版本内核中有个限制：允许创建的cgroup最大数量写死为65535，如果节点上经常创建销毁容器导致创建很多cgroup造成泄露，创建容器的时候就会导致cgroup创建失败并报错“no space left on device”

        解决方法：

             升级内核到3.10.1064以上版本并且关闭kernel，kmem特性，重启主机

• arp缓存爆满导致健康检查失败

        某集群节点数 1200+，用户监控方案是 daemonset 部署 node-exporter 暴露节点监控指标，使用 hostNework 方式，statefulset 部署 promethues 且仅有一个实例，落在了一个节点上，promethues 请求所有节点 node-exporter 获取节点监控指标，也就是或扫描所有节点，导致 arp cache 需要存所有 node 的记录，而节点数 1200+，大于了 net.ipv4.neigh.default.gc_thresh3 的默认值 1024，这个值是个硬限制，arp cache记录数大于这个就会强制触发 gc，所以会造成频繁gc，当有数据包发送会查本地 arp，如果本地没找到 arp 记录就会判断当前 arp cache 记录数+1是否大于 gc_thresh3，如果没有就会广播 arp 查询 mac 地址，如果大于了就直接报 arp_cache: neighbor table overflow!，并且放弃 arp 请求，无法获取 mac 地址也就无法知道探测报文该往哪儿发(即便就在本机某个 veth pair)，kubelet 对本机 pod 做存活检查发 arp 查 mac 地址，在 arp cahce 找不到，由于这时 arp cache已经满了，刚要 gc 但还没做所以就只有报错丢包，导致存活检查失败重启 pod

         解决方法：

             调整gc_thresh阈值           

            net.ipv4.neigh.default.gc_thresh1 = 128

            net.ipv4.neigh.default.gc_thresh2 = 512

            net.ipv4.neigh.default.gc_thresh3 = 4096

• DNS解析异常
  ​   如果DNS解析经常延时5s才返回，可能时conntrack冲突导致的丢包

         解析超时，查看coredns服务是否正常

         解析外部域名超时，若容器应用使用的dnspolicy时clusterfirst，则需要查看coredns所在节点的dns解析是否能够解析到外部域名，若dnspolicy为default，则需要查看容器所在主机的dns是否能够解析到外部域名，确认上游dns状态，是否有ACL限制