节点异常问题排查

CCE提供节点故障检测NPD插件，NPD插件从1.16.0版本开始增加了大量检查项，能对节点上各种资源和组件的状态检测，帮助发现节点故障。

强烈建议您安装该插件，如已安装请查看插件版本并升级到1.16.0及以上版本。

安装NPD插件后，当节点出现异常时，控制台上可以查看到指标异常。

您还可以在节点事件中查看到NPD上报的事件，根据事件信息可以定位故障。

图1 诊断流程图

1. 登录CCE控制台。
2. 单击集群名称进入集群，在左侧选择“节点管理”，切换至“节点”页签。
3. 单击节点操作栏中的“更多 > 查看YAML”，查看节点的Status字段。

   节点状态为NotReady状态

   • 查看节点的状态信息，是否存在PIDPressure、DiskPressure、MemoryPressure等节点状态是否为True。如果节点存在任一状态为True，则基于异常的关键词，查找相应的解决方案。
   • 检查节点上的关键组件，及关键组件上的日志。节点上的关键组件为Kubelet及其运行时组件（Docker/Containerd），详细操作请参见检查节点的关键组件。
     • Kubelet组件

       检查Kubelet的状态、日志等是否存在异常。若存在异常则参考Kubelet异常处理。

     • 运行时组件（Docker/Containerd）
       • 检查节点的运行时组件，若不确定节点的运行时组件具体是Docker还是Containerd，请登录CCE控制台，查看节点的运行时信息。
       • 如果存在异常，则参考节点运行时异常处理-RuntimeOffline。
     • NTP组件
       • 检查NTP服务的状态、日志、配置等是否存在异常。
       • 若NTP服务存在异常，则参考NTP异常处理-NTPProblem。
   • 检查节点的监控，查看节点的CPU、内存、网络等资源负载情况是否存在异常。如果节点负载情况存在异常，请参考节点MemoryPressure等进行解决。

   节点状态为Unknown状态

   • 登录ECS界面，查看节点是否存在。
   • 需确认节点是否处于运行中状态。
   • 检查节点上的关键组件，及关键组件上的日志。节点上的关键组件为Kubelet及其运行时组件（Docker/Containerd），详细操作请参见检查节点的关键组件。
     • Kubelet组件
       • 检查Kubelet的状态、日志等是否存在异常。若存在异常则参考Kubelet异常处理。
   • 检查节点的网络连通性。

1. 登录CCE服务控制台。
2. 在界面中选择需要检查节点所在的集群。
3. 在集群列表页面单击“节点管理”，切换到“节点”一栏，查看不可用节点的状态。（如果已安装NPD 1.6.10及以上的插件版本，则在不可用下面会展示指标异常提示，将鼠标光标移动至上方即可看到具体的问题项，若未安装请参考排查项继续排查）。

1. 登录CCE服务控制台。
2. 在界面中选择需要检查节点所在的集群。
3. 在集群列表页面单击“节点管理”，切换到“节点”一栏，在异常节点所在行单击“监控”。

   单击“监控”页签顶部的“更多监控数据”，前往运维管理页面查看历史监控记录。当节点CPU和内存负载过高时，会导致节点网络时延过高，或系统OOM，最终展示为不可用。

1. 登录CCE服务控制台。
2. 在界面中选择需要检查节点所在的集群。
3. 在集群列表页面单击“节点管理”，切换到“节点”一栏，在异常节点所在行单击“事件”。即可查看是否有节点异常的事件上报（需安装NPD插件）。

1. 登录CCE服务控制台，进入集群，查看不可用节点的名称。
2. 进入ECS控制台，搜索该节点，查看对应的云服务器状态。
   • 若弹性云服务器状态为“已删除”：请在CCE中删除对应节点，再重新创建节点。
   • 若弹性云服务器状态为“关机”或“冻结”：请先恢复弹性云服务器，约3分钟后集群节点可自行恢复。
   • 若弹性云服务器出现故障：请先重启弹性云服务器，恢复故障。
   • 若弹性云服务器状态为“可用”：请参考检查节点的关键组件进行排查。

1. 登录ECS控制台。
2. 确认ECS界面显示的节点名称与虚机内的名称是否一致，并且密码或者密钥能否登录。

   如果节点名称不一致，且密码和密钥均不能登录，说明ECS创建虚机时的cloudinit初始化问题，临时规避可以尝试重启节点，之后再向ECS服务提交工单确认根因。

• 节点的安全组被修改导致异常
  1. 登录VPC控制台，在左侧栏目树中单击“访问控制 > 安全组”，找到集群控制节点的安全组。
  2. 控制节点安全组名称为：集群名称-cce-control-编号。您可以通过集群名称查找安全组，再进一步在名称中区分“-cce-control-”字样，即为本集群安全组。
  3. 排查安全组中规则是否被修改，关于安全组的详细说明请参见集群安全组规则配置。
• 检查安全组规则中是否包含Master和Node互通的安全组策略
  • 请检查安全组规则中是否包含Master和Node互通的安全组策略。
  • 已有集群添加节点时，如果子网对应的VPC新增了扩展网段且子网是扩展网段，要在控制节点安全组（即集群名称-cce-control-随机数）中添加如下三条安全组规则（参考表2），以保证集群添加的节点功能可用（新建集群时如果VPC已经新增了扩展网段则不涉及此场景）。
  • 关于安全组的详细说明请参见集群安全组规则配置。

    表2 需新增的安全组规则

    协议端口	类型	源地址
    TCP：8445	IPv4	新增的子网扩展网段
    TCP：9443	IPv4	新增的子网扩展网段
    TCP：5444	IPv4	新增的子网扩展网段

• 新建节点会默认给节点绑定一个100G的运行时专用数据盘（您可以自己选择是否增加）。若数据盘卸载或损坏，会导致运行时异常，最终导致节点不可用。

• 检查节点挂载的数据盘是否已被卸载。若已卸载建议重新创建一个节点，并将不可用节点删除。（不建议您在ECS侧对CCE管理的节点进行操作，以避免出现意外的风险）

Kubelet

• 查看Kubelet状态

  登录对应的异常节点，在节点上执行如下命令，查看Kubelet进程状态。

  systemctl status kubelet

  预期输出：

  

• 查看Kubelet日志

  登录对应的异常节点，在节点上执行如下命令，查看Kubelet进程状态。

  journalctl -u kubelet

运行时

• Docker
  • 查看Docker状态

    登录对应的异常节点，在节点上执行如下命令，查看docker的进程状态。

    systemctl status docker

    预期输出：

    

  • 查看Docker日志

    登录对应的异常节点，在节点上执行如下命令，可查看Docker的日志信息。

    journalctl -u docker

• Containerd
  • 查看Containerd状态

    登录对应的异常节点，在节点上执行如下命令，查看Containerd进程状态。

    systemctl status containerd

    预期输出：

    

  • 查看Containerd日志

    登录对应的异常节点，在节点上执行如下命令，查看Containerd的日志。

    journalctl -u containerd

• NTP组件
  • 查看NTP服务状态是否正常

    登录对应的异常节点，在节点上执行如下命令，查看Chronyd进程的状态。

    systemctl status chronyd

    预期输出：

    

  • 查看NTP服务日志

    登录对应的异常节点，在节点上执行如下命令，查看NTP日志信息。

    journalctl -u chronyd

• 登录节点，在日志/var/log/cloud-init-output.log中查看是否有域名解析失败相关的报错。可以执行如下指令：

  cat /var/log/cloud-init-output.log | grep resolv

  如果回显结果包含如下类似内容则说明无法解析该域名。

  Could not resolve host: xxx ; Unknown error

• 在节点上ping无法解析的域名，例如：

  ping xxx

  如果不能，则说明DNS无法解析该地址。请确认/etc/resolv.conf文件中的DNS地址与配置在VPC的子网上的DNS地址是否一致，通常是因为DNS地址配置错误导致无法正常解析域名。

问题根因

节点上的容器占用PID过多导致节点的PID不足。CCE默认留给分配Pod使用的可用PID数的百分比为10%。

问题现象

当节点的可用PID低于pid.available配置项时，则节点状态中PIDPressure为True，同时该节点上的容器被驱逐。关于节点驱逐，可参考社区文档节点压力驱逐。

解决方案

1. 执行如下命令，查看节点的最大PID数和拥有最多PID的进程。

   sysctl kernel.pid_max  #查看最大PID数
   ps -eLf|awk '{print $2}' | sort -rn| head -n 1   #查看拥有最多PID的进程

2. 执行如下命令，查看占用PID最多的前5个进程。

   ps -elT | awk '{print $4}' | sort | uniq -c | sort -k1 -g | tail -5

   预期输出结果：

   17 1211619
   18 3739112
   18 5299
   24 964
   25 3739756

   第一列为进程占用的PID数，第二列为当前进程号，根据进程号找到对应进程和所属Pod，分析占用PID过多的原因并优化对应的代码。

3. 降低节点的负载。
4. 如需重启节点，可在ECS界面尝试重启异常节点。（注意：重启节点可能会导致您的业务中断，请谨慎操作。）

问题根因

节点上的容器占用内存过多导致节点的内存不足。CCE默认节点可用内存值为100 Mi。

问题现象

• 当节点的可用内存低于memory.available配置项时，则节点状态中MemoryPressure为True，同时该节点上的容器被驱逐。关于节点驱逐，可参考社区文档节点压力驱逐。
• 当节点内存不足时，会有以下常见错误信息：
  • 节点状态中MemoryPressure为True。
  • 当节点上的容器被驱逐时：
    • 在被驱逐的容器事件中可看到关键字The node was low on resource: memory。
    • 在节点事件中可看到关键字attempting to reclaim memory。
  • 可能会导致系统OOM异常，当出现系统OOM异常时，节点事件中可看到关键字System OOM。

解决方案

• 通过节点的监控查看内存增长曲线，确认异常出现时间点，检查节点上的进程是否存在内存泄露现象。具体操作请参见检查节点监控。
• 降低节点上的负载。
• 如需重启节点，可在ECS界面尝试重启异常节点。（注意：重启节点可能会导致您的业务中断，请谨慎操作。）

问题根因

问题现象

• 当节点的可用磁盘空间低于imagefs.available配置项时，则节点状态中DiskPressure为True。
• 当可用磁盘空间低于nodefs.available配置项时，则该节点上的容器全部被驱逐。关于节点驱逐，可参考社区文档节点压力驱逐。
• 当磁盘空间不足时，通常会有以下常见错误信息：
  • 节点状态中DiskPressure为True。
  • 当触发镜像回收策略后，磁盘空间仍然不足以达到健康阈值（默认为80%），在节点事件中可看到关键字failed to garbage collect required amount of images。
  • 当节点上的容器被驱逐时：
    • 被驱逐的容器事件中可看到关键字The node was low on resource: [DiskPressure]。
    • 节点事件中可看到关键字attempting to reclaim ephemeral-storage或attempting to reclaim nodefs。

解决方案

• 通过节点的监控查看磁盘增长曲线，确认异常出现时间点，检查节点上的进程是否存在占用磁盘空间过多的现象。具体操作请参见检查节点监控。
• 若有大量文件在磁盘上未清理，请清理文件。
• 根据自身业务情况，限制Pod的ephemeral-storage资源配置。
• 建议使用云存储产品，避免使用HostPath数据卷。
• 扩容节点的磁盘。
• 降低节点的负载。

问题根因

通常是kubelet进程异常、kubelet配置有误导致。通常情况下，CCE已默认为kubelet配置了健康检查，因此配置有误导致起不来的可能性更大。

问题现象

Kubelet状态为inactive。

解决方案

1. 登录出现异常的节点，执行如下命令重启Kubelet。重启Kubelet不会影响运行中的容器。

   systemctl restart kubelet

2. 输入以下指令查看Kubelet状态是否恢复正常。

   systemctl status kubelet

3. 若kubelet重启后状态仍异常，请登录节点执行以下命令查看kubelet的日志。

   journalctl -u kubelet

   • 若日志中有明确的错误信息，请根据发生错误时的关键字进行排查。
   • 若确认是kubelet配置异常，请在节点所属的节点池，单击“配置管理”，在kubelet组件配置栏，对kubelet配置进行修改。

问题根因

通常Docker/Containerd的配置、进程异常等原因导致。

问题现象

• Docker组件
  • Docker的状态为inactive。
  • Docker的状态为active(running)，但是节点未正常工作，导致节点异常。此时通过docker ps 或者 docker exec等命令出现执行失败的现象。
  • 节点状态中的RuntimeOffline为True。
• Containerd组件
  • Containerd的状态为inactive。
  • 节点状态中的RuntimeOffline为True。

解决方案

1. 登录异常的节点。
2. 执行如下命令重启运行时。

   # Docker
   systemctl restart docker
   # Containerd
   systemctl restart containerd

3. 待命令执行完毕之后，查看运行时状态是否正常。

   # Docker
   systemctl status docker
   # Containerd
   systemctl status containerd

4. 若重启运行时，组件的状态仍然异常，请执行如下命令查看组件日志。

   # Docker
   journalctl -u docker
   # containerd
   journalctl -u containerd

问题根因

NTP进程状态异常导致。

问题现象

• Chronyd状态为inactive。
• 节点状态中NTPProblem为True。

解决方案

1. 登录异常节点，执行如下命令重启Chronyd。

   systemctl restart chronyd

2. Chronyd重启之后，执行以下命令，查看Chronyd的状态是否恢复正常。

   systemctl status chronyd

3. 若Chronyd重启之后状态仍然异常，请登录节点执行以下命令查看Chronyd日志。

   journalctl -u chronyd

问题根因

通常是节点负载异常等原因导致。

问题现象

节点重启的过程中，节点状态为NotReady。

解决方案

1. 执行如下命令，查看节点重启时间。

   last reboot

   预期输出：

   

2. 查看节点的监控，根据节点重启时间排查出现异常的资源。具体操作请参见检查节点监控。
3. 查看节点的内核日志，根据重启时间排查异常日志。

问题根因

通常是节点运行状态异常、安全组配置有误或网络负载过高导致。

问题现象

• 节点无法登录。
• 节点状态Unknown。

解决方案

• 若节点无法登录，请参考以下步骤排查：
  • 在ECS侧检查节点实例状态是否为运行中。
  • 参考是否为ECS的cloud-init执行失败导致。具体操作，可参考弹性云服务是否能够登录。
  • 检查节点的安全组配置。具体操作，可参考节点的安全组检查。
• 若节点的网络负载过高，请参考以下步骤进行排查：
  • 通过节点的监控查节点网络增长曲线，检查节点上的Pod是否存在占用网络带宽过多的现象。
  • 使用网络策略控制Pod的网络流量。

问题根因

Pod生命周期事件生成器PLEG（Pod Lifecycle Event Generator）会记录Pod生命周期中的各种事件，如容器的启动、终止等。PLEG is not healthy异常通常是由于节点上的运行时进程异常或者节点Systemd版本缺陷导致。

问题现象

• 节点状态NotReady
• 在Kubelet日志中，可看到如下日志。

  skipping pod synchronization - PLEG is not healthy: pleg was last seen active 3m17.028393648s ago; threshold is 3m0s.

解决方案

• 依次重启节点关键组件Docker、Containerd、Kubelet，待完成重启之后查看节点是否恢复正常。
• 若节点关键组件重启后节点仍未恢复正常，可尝试重启异常节点。（重启节点可能会导致您的业务中断，请谨慎操作）

问题根因

节点调度资源不足导致。

问题现象

其中调度器判定节点资源不足的计算方式为：

• 集群节点CPU资源不足的判定方式：当前Pod请求的CPU资源总量>（节点可分配的CPU资源总量-节点已分配的CPU资源总量）
• 集群节点内存资源不足的判定方式：当前Pod请求的内存资源总量>（节点可分配的内存资源总量-节点已分配的内存资源总量）
• 集群节点临时存储不足的判定方式：当前Pod请求的临时存储总量>（节点可分配的临时存储总量-节点已分配的临时存储总量）

如果当前Pod请求的资源总量大于节点可分配的资源总量减去节点已分配的资源总量，Pod就不会调度到当前节点。

执行以下命令，查看节点的资源分配信息：

kubectl describe node $nodeName

关注输出中，关于资源分配的部分：

Allocatable:
  cpu:                1930m
  ephemeral-storage:  94576560382
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  localssd:           0
  localvolume:        0
  memory:             2511096Ki
pods:               20
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests      Limits
  --------           --------      ------
  cpu                1255m (65%)   4600m (238%)
  memory             1945Mi (79%)  3876Mi (158%)
  ephemeral-storage  0 (0%)        0 (0%)
  hugepages-1Gi      0 (0%)        0 (0%)
  hugepages-2Mi      0 (0%)        0 (0%)
  localssd           0             0
  localvolume        0             0

其中：

• Allocatable：表示本节点可分配的（CPU/内存/临时存储）资源总量。
• Allocated resources：表示本节点已经分配的（CPU/内存/临时存储）资源总量。

解决方案

问题根因

VPC路由网络模式集群依赖网络基础设施的路由表打通容器网络，新创建的CCE节点支持网络隔离，网络未生效系统会自动添加node.kubernetes.io/route-unreachable污点，并在网络就绪后移除该污点。若遇到节点node.kubernetes.io/route-unreachable污点长时间未移除，说明节点存在网络连通性问题。

问题现象

新建节点长时间处于“受限调度”状态。

解决方案

1. 若集群内存在其他正常节点，可通过ping命令检查跨节点容器之间的网络连通性。

   创建一个测试容器，示例如下，其中{node_ip}为该异常节点的IP。

   kind: Pod
   apiVersion: v1
   metadata:
     name: nginx
     namespace: default
   spec:
     containers:
       - name: container-1
         image: nginx:latest
         imagePullPolicy: IfNotPresent
     imagePullSecrets:
       - name: default-secret
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
             - matchExpressions:
                 - key: kubernetes.io/hostname
                   operator: In
                   values:
                     - {node_ip}
     schedulerName: default-scheduler
     tolerations:
       - key: node.kubernetes.io/route-unreachabe
         operator: Exists
         effect: NoSchedule

   待容器启动后，登录另一正常节点，ping此容器的IP。若通信异常，进行下面第二步。

2. 到VPC路由表界面查看该节点路由是否已经添加成功，其中下一跳类型为“云容器引擎”，下一跳为该节点名称。如果路由表中存在该节点的路由仍无法连通网络，则可能是底层网络故障，请提网络工单处理。
3. 若通过上述检查都无法解决问题，请提交CCE工单进行排查。

问题根因

节点上调度容器较多，资源耗尽导致节点OOM，主要发生在Docker容器引擎节点上。

问题现象

当集群中大量的容器调度到节点上，可能会导致节点OS的panic，节点显示为不可用。通过VNC登录节点可看到如下信息：

执行以下命令，查看节点的事件：

kubectl describe node {nodeName}

关注输出中关于节点的异常事件：

解决方案

当节点资源不足时，需降低节点负载，方法如下：

• 故障节点通过节点重置恢复。
• 删除或减少不必要的Pod，降低节点的负载。
• 根据自身业务情况，限制Pod的资源配置。
• 在集群中添加新的节点。