如何将我的节点的状态从 NotReady 或 Unknown 状态更改为 Ready 状态?

上次更新时间:2020 年 8 月 26 日

我的 Amazon Elastic Kubernetes Service (Amazon EKS) 工作线程节点处于 NotReady 或 Unknown 状态。我想使工作线程节点重新恢复为 Ready 状态。

简短描述

您不能在状态为 NotReadyUnknown 的节点上计划 Pod。您只能在处于 Ready 状态的节点上计划 Pod。

下面的解决方法适用于状态为 NotReadyUnknown 的节点。

如果您的节点处于 MemoryPressureDiskPressurePIDPressure 状态,则必须管理您的资源,以允许在该节点上计划额外的 Pod。如果您的节点处于 NetworkUnavailable 状态,则必须在该节点上正确地配置网络。有关详细信息,请参阅 Kubernetes 文档中的节点状态

注意:有关管理 Pod 移出和资源限制的信息,请参阅 Kubernetes 文档中的配置资源不足处理

解决方法

检查 aws-node 和 kube-proxy Pod 以了解节点处于 NotReady 状态的原因

NotReady 状态的节点不可用于在其上计划 Pod。

1.    要检查 aws-nodekube-proxy Pod 的状态,请运行以下命令:

$ kubectl get pods -n kube-system -o wide

2.    通过审核步骤 1 的输出来检查 aws-nodekube-proxy Pod 的状态。

注意:aws-nodekube-proxy Pod 由 DaemonSet 管理,因此集群中的每个节点上都必须有一个 aws-nodekube-proxy Pod 正在运行。如果未列出 aws-nodekube-proxy Pod,请跳至步骤 4。 有关详细信息,请参阅 Kubernetes 文档中的 DaemonSet

如果您的节点状态正常,则您的 aws-nodekube-proxy Pod 应为 Running 状态。例如:

$ kubectl get pods -n kube-system -o wide
NAME                             READY   STATUS    RESTARTS   AGE        IP              NODE
aws-node-qvqr2                   1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
kube-proxy-292b4                 1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal

如果任一 Pod 状态不为 Running,请运行以下命令:

$ kubectl describe pod yourPodName -n kube-system

3.    为了从 aws-nodekube-proxy Pod 日志中获取其他信息,请运行以下命令:

$ kubectl logs yourPodName -n kube-system

来自 describe 输出的日志和事件可以显示 Pod 不为 Running 状态的原因。为了将节点状态更改为 Ready,该节点上的 aws-nodekube-proxy Pod 都必须为 Running 状态。

注意:Pod 的名称可以与 aws-node-qvqr2kube-proxy-292b4 不同,如前面的示例中所示。

4.    如果运行步骤 1 中的命令后未列出 aws-nodekube-proxy Pod,则运行以下命令:

$ kubectl describe daemonset aws-node -n kube-system
$ kubectl describe daemonset kube-proxy -n kube-system

5.    搜索步骤 4 中的命令的输出以了解 Pod 无法启动的原因。

提示:您可以搜索 Amazon EKS 控制平面日志以了解无法计划 Pod 的原因。

6.    根据 AWS 指导原则,确认 aws-nodekube-proxy 的版本与集群版本兼容。例如,您可以运行以下命令以检查 Pod 版本:

$ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

注意:要更新 aws-node 版本,请参阅用于 Kubernetes 升级的 Amazon VPC CNI 插件。要更新 kube-proxy 版本,请按照更新现有群集中的步骤 4 操作。

在有些场景中,节点可能处于 Unknown 状态。这意味着,该节点上的 kubelet 无法与控制平面交流该节点的正确状态。

要对状态为 Unknown 的节点进行问题排查,请完成以下部分中的步骤:

  • 检查节点与控制平面之间的网络配置
  • 检查 kubelet 的状态
  • 检查 Amazon EC2 API 终端节点是否可访问

检查节点与控制平面之间的网络配置

1.    确认您的子网上没有阻挡 Amazon EKS 控制平面与工作线程节点之间的流量的网络访问控制列表 (ACL) 规则

2.    确认您的控制平面的节点的安全组符合最低入站和出站要求

3.    (可选)如果您的节点配置为使用代理,确认代理允许到 API 服务器终端节点的流量。

4.    要验证节点能够访问 API 服务器,请从工作线程节点内运行以下 netcat 命令:

$ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443
Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

重要提示:9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 替换为您的 API 服务器终端节点。

5.    验证路由表已正确配置为允许通过互联网网关或 NAT 网关与 API 服务器终端节点进行通信。如果集群使用 PrivateOnly 联网,请验证 VPC 终端节点配置正确。

检查 kubelet 的状态

1.    使用 SSH 连接到受影响的工作线程节点。

2.    要检查 kubelet 日志,请运行以下命令:

$ journalctl -u kubelet > kubelet.log

注意:kubelet.log 文件包含关于 kubelet 操作的信息,可以帮助您找出节点状态问题的根本原因。

如果日志未提供关于问题来源的原因,则运行以下命令以检查工作线程节点上的 kubelet 状态:

$ sudo systemctl status kubelet
  kubelet.service - Kubernetes Kubelet
   Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-eksclt.al2.conf
   Active: inactive (dead) since Wed 2019-12-04 08:57:33 UTC; 40s ago

如果 kubelet 不为 Running 状态,则运行以下命令以重新启动 kubelet

$ sudo systemctl restart kubelet

检查 Amazon EC2 API 终端节点是否可访问

1.    使用 SSH 连接到其中一个工作线程节点。

2.    要检查您所在 AWS 区域的 Amazon Elastic Compute Cloud (Amazon EC2) API 终端节点是否可访问,请运行以下命令:

$ nc -vz ec2.<region>.amazonaws.com 443
Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!

重要提示:us-east-1 替换为您的工作线程节点位于的 AWS 区域。

检查工作线程节点实例配置文件和 ConfigMap

1.    确认工作线程节点实例配置文件具有推荐的策略

2.    确认 aws-auth ConfigMap 中存在工作线程节点实例角色。要检查 ConfigMap,请运行以下命令:

$ kubectl get cm aws-auth -n kube-system -o yaml

ConfigMap 应具有适用于工作线程节点实例 AWS Identity and Access Management (IAM) 角色的条目。例如:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: <ARN of instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

这篇文章对您有帮助吗?


您是否需要账单或技术支持?