IBM Cloud Docs
使用 Kubernetes API 调试工作程序节点

使用 Kubernetes API 调试工作程序节点

如果您有权访问集群,那么可以在 Node 资源上使用 Kubernetes API 来调试工作程序节点。

开始之前,请确保您在集群的所有名称空间中都具有 Manager 服务访问角色,该角色对应于 cluster-admin RBAC 角色。

  1. 登录您的账户。 如果适用,请将相应的资源组设定为目标。 设置集群的上下文。

  2. 列出集群中的工作程序节点,并记下不在 Ready STATUS 中的工作程序节点的 NAME。 请注意,NAME 是工作程序节点的专用 IP 地址。

    kubectl get nodes
    
  3. 描述每个工作程序节点,并查看输出中的 Conditions 部分。

    • Type: 可能影响工作程序节点的条件类型,例如内存或磁盘压力。
    • LastTransitionTime: 最近一次更新状态的时间。 使用此时间来确定工作程序节点问题的开始时间,这可帮助您进一步对问题进行故障诊断。
    kubectl describe node <name>
    
  4. 检查工作节点的使用情况

    1. 在先前命令的 Allocated resources 输出中,查看使用工作程序节点的 CPU 和内存资源的工作负载。 您可能会注意到某些 pod 未设置资源限制,并且耗用的资源超出预期。 如果是这样,请调整 pod 的资源使用情况。
    2. 查看集群中各个工作程序节点的 CPU 和内存使用率百分比。 如果使用率始终超过 80%,请向集群添加更多工作程序节点以支持工作负载。
  5. 检查集群中安装的定制许可控制器。 许可控制器通常会阻止必需的 pod 运行,这可能会使工作程序节点进入临界状态。 如果您有定制许可控制器,请尝试使用 kubectl delete 将其移除。 然后,检查工作程序节点问题是否已解决。

    kubectl get mutatingwebhookconfigurations --all-namespaces
    
    kubectl get validatingwebhookconfigurations --all-namespaces
    
  6. 如果配置了 日志转发,请从以下路径查看与节点相关的日志。

    /var/log/containerd.log
    /var/log/kube-proxy.log
    /var/log/kubelet.log
    /var/log/syslog
    
    
  7. 检查工作负载部署是否不会导致工作程序节点问题。

    1. 使用问题污染工作程序节点。
      kubectl taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
      
    2. 请确保已删除任何定制许可控制器,如步骤 5 中所述。
    3. 重新启动工作程序节点。
      • 经典:重新加载工作节点
        ibmcloud ks worker reload -c <cluster_name_or_ID> --worker <worker_ID>
        
      • VPC:更换工作节点。
        ibmcloud ks worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
        
    4. 等待工作程序节点完成重新启动。 如果工作程序节点进入正常状态,那么问题可能是由工作负载引起的。
    5. 将一个工作负载一次调度到工作程序节点上,以查看导致该问题的工作负载。 要调度工作负载,请添加以下容错。
      tolerations:
      - effect: NoExecute
        key: ibm-cloud-debug-isolate-customer-workload
        operator: Exists
      
    6. 确定导致问题的工作负载后,继续 调试应用程序部署