如何对无法加入 Amazon EKS Anywhere 集群的节点进行故障排除？

3 分钟阅读

我的 Amazon Elastic Kubernetes Service (Amazon EKS) 节点无法加入我的 Amazon EKS Anywhere 集群。

简短描述

在开始排除故障之前，请确认您的配置满足以下要求：

您有一台管理计算机来运行集群生命周期操作。
您的管理计算机、控制面板和 Worker 节点位于同一个第 2 层网络上。
您的网络支持 DHCP。
**注意：**最佳做法是将网络配置为排除控制平面和 Worker 节点的特定 IP 地址。
您为控制平面端点和其他集群节点保留了静态 IP 地址，而从 DHCP 范围中排除了静态 IP 地址。
您的服务器每个节点至少有两个 vCPU、8 GB RAM 和 25 GB 存储空间。
您的弹性网络接口支持预启动执行环境 (PXE)。
您拥有 VMware vSphere 7 或 8 以及 VMware vCenter Server。
您有能力部署 6-10 个虚拟机 (VM)。此外，您在工作负载集群的主虚拟机网络中运行 DHCP 服务。
您的 vSphere 网络允许访问 vCenter Server，并且您在 DHCP 中保留和排除了必要的 IP 地址。

解决方法

节点注册错误

当您未将适用于 Kubernetes 的 AWS IAM 身份验证器配置映射 (aws-auth ConfigMap) 应用于集群时，您会收到以下错误消息：

“Unable to register node with API server err=Unauthorized.”

**注意：**配置映射为节点注册到集群提供了 system:bootstrappers 和 system:nodes 基于角色的访问控制 (RBAC) 权限。

要解决节点注册错误，请将您的 AWS Identity and Access Management (IAM) 角色添加到 aws-auth ConfigMap 中。

Unauthorized 错误

当您删除托管节点组并且随后从 aws-auth ConfigMap 中删除节点角色条目时，您会收到“unauthorized”错误消息。当您在 kubelet 日志中查看向 API 服务器发送的 kubelet API 请求时，可以识别出这个错误。

要解决未经授权的错误，请再次将您的 IAM 角色添加到 aws-auth ConfigMap 中。

Kubelet 依赖项错误

CA 文件错误

当节点无法从集群检索证书颁发机构 (CA) 文件或 /etc/eks/bootstrap.sh 脚本运行时，您会收到以下错误消息：

“Failed to construct kubelet dependencies" err="unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory.”

要解决 Kubelet 依赖项错误，请完成以下步骤：

检查 cloud-init 日志中的 /var/log/cloud-init-output.log 流中是否有以下错误消息：
“Connect timeout on endpoint URL: https://eks.us-east-1.amazonaws.com/clusters/vg-xx-uat Exited with error on line 291”

运行以下 curl -vk 命令以验证您是否可以访问 Amazon EKS API 端点：

curl -vk https://eks.us-east-1.amazonaws.com/

删除 Amazon EKS 端点。

如果您无法访问端点，请执行以下操作：

对于私有端点，将该节点置于同一个虚拟私有云 (VPC) 或连接的网络中。私有端点不可公开访问。
为公共端点配置安全组、路由表和网络访问控制列表（网络 ACL）。安全组、路由表和网络 ACL 都必须允许流向 Amazon EKS 端点的出站 HTTPS (TCP 443) 流量。有关详细信息，请参阅 VPC 和子网注意事项。
对于私有子网中的节点，请确保您有用于出站互联网访问的 NAT 网关或 VPC 端点。
在您的 VPC 中将 enableDnsHostnames 和 enableDnsSupport 设置为 true。
确保 DHCP 选项集包含 AmazonProvidedDNS。

验证错误

当 Kubernetes 在工作负载集群中找不到控制平面资源“kubeadmcontrolplanes.controlplane.cluster.x-k8s.io”时，您会收到以下验证错误消息：

“Validation failed: kubeadmcontrolplanes.controlplane.cluster.x-k8s.io 'eksa-sit' not found; no CAPI cluster objects present on workload cluster 'eksa-sit'...”

要解决验证错误，请完成以下步骤：

访问运行 kubeadm 进程的控制平面节点。
运行以下 journalctl 命令以从 kubelet 服务日志中获取故障排除信息：
```
journalctl -u kubelet -f
```
在日志输出中，找出导致验证错误的集群组件。

引导令牌错误

由于 Amazon EKS Anywhere 集群 1.0.2 版中的错误，您会遇到引导令牌错误。有关详细信息，请参阅 GitHub 网站上的 bootstrap tokens can expire before they can be used if the bootstrap cluster's time is sufficiently behind the workload cluster（如果引导集群的时间明显落后于工作负载集群，引导令牌可能在尚未使用前就已过期。）。

要解决此错误，请参阅 GitHub 网站上的 Fix to enable bootstrap secret rotation if the secret itself missing（修复缺失密钥本身时启用引导密钥轮换）。

缺失引导令牌密钥错误

当运行 eksctl anywhere upgrade cluster -f cluster.yaml 命令时，您可能会收到错误消息。之所以出现错误，是因为工作流程中的错误导致引导令牌密钥缺失。该错误会阻止尝试加入您的集群的新节点。

要解决此错误，请完成以下步骤：

手动删除新配置的计算机以刷新引导令牌。
当集群处于运行状况良好状态时，备份 Kubernetes 集群 API (CAPI) 并将 CAPI 组件移至管理集群。有关说明，请参阅 Cluster upgrade fails with management components on bootstrap cluster（引导集群上的管理组件导致集群升级失败）。

内部错误

当 Webhook 验证服务出现连接问题时，您会收到以下内部错误消息：

“Error from server (InternalError): Internal error occurred: failed calling webhook...”

要解决内部错误，请完成以下步骤：

运行以下 kubectl get pods 命令来查找您的 eks-controller-manager 容器组：

kubectl get pods -n kube-system | grep eks-controller-manager

运行以下 kubectl logs 命令来查看容器组的日志：

kubectl logs eksa-controller-manager-pod-name -n kube-system

**注意：**将 eksa-controller-manager-pod-name 替换为您的 eksa-controller-manager 容器组的名称。

使用日志输出中的信息对问题进行故障排除。

当 Kubernetes 控制面板中的领导者选举过程超时时，您将收到以下内部错误消息：

“Failed to update lock: etcdserver: request timed out failed to renew lease eksa-system/f64ae69e.eks.amazonaws.com: timed out waiting for the condition Error setup problem running manager {'error': 'leader election lost'}...”

当领导者选举过程无法续订 etcd 中的资源锁定租约时，您也可能会收到此错误消息。

错误的根本原因包括网络延迟、etcd 不可用或资源争用问题。

要解决此内部错误，请删除 eksa-controller-manager 容器组。替换容器组将启动并移至 Running（正在运行）状态。

**注意：**在 Amazon EKS Anywhere 集群的 1.21 版或更早版本中可能会出现内部错误。为避免此错误，最佳做法是将您的集群更新到最新的 Kubernetes 版本。

PLEG 错误

当容器组生命周期事件生成器 (PLEG) 出现问题时，您会收到以下错误消息：

“PLEG is not healthy: pleg was last seen active.”

要解决 PLEG 错误，请执行以下操作：

检查并解决远程请求期间发生的容器运行时延迟或超时，例如性能下降、死锁或错误。
避免使用太多正在运行的容器组来存放主机资源，或者避免在高规格主机上运行太多的容器组。
对节点中的资源问题进行故障排除。

有关 PLEG 的详细信息，请参阅 Red Hat Developer 网站上的 Pod Lifecycle Event Generator: Understanding the "PLEG is not healthy" issue in Kubernetes（容器组生命周期事件生成器：了解 Kubernetes 中的“PLEG is not healthy”问题）。

NotReady,SchedulingDisabled 错误

当 Amazon EKS Anywhere 集群中的一个节点处于 NotReady,SchedulingDisabled 状态时，您会遇到错误。这是因为运行 vSphere VM 的物理机器已不存在。您的集群卡滞在扩展阶段，您的新节点无法启动。

要解决 NotReady,SchedulingDisabled 状态错误，请完成以下步骤：

移除机器的终结器。
运行以下 kubectl delete node 命令来删除待处理的 Amazon EKS 节点，让新节点启动：
```
kubectl delete node your_node_name
```
**注意：**将 your_node_name 替换为要删除的节点的名称。