Amazon EKS Anywhere 클러스터에 연결할 수 없는 노드 문제를 해결하려면 어떻게 해야 합니까?

6분 분량

Amazon Elastic Kubernetes Service(Amazon EKS) 노드가 Amazon EKS Anywhere 클러스터에 연결할 수 없습니다.

간략한 설명

문제 해결을 시작하기 전에 구성이 다음 요구 사항을 충족하는지 확인하십시오.

클러스터 수명 주기 작업을 실행할 관리 시스템이 있습니다.
관리 시스템, 컨트롤 플레인 및 워커 노드는 동일한 계층 2 네트워크에 있습니다.
네트워크가 DHCP를 지원합니다.
참고: 컨트롤 플레인 및 워커 노드의 특정 IP 주소를 제외하도록 네트워크를 구성하는 것이 좋습니다.
컨트롤 플레인 엔드포인트 및 기타 클러스터 노드에 대한 고정 IP 주소를 예약하고 DHCP 범위에서 고정 IP 주소를 제외했습니다.
서버에는 각 노드에 대해 최소 2개의 vCPU, 8GB RAM 및 25GB의 스토리지가 있습니다.
탄력적 네트워크 인터페이스는 PXE(Preboot eXecution Environment)를 지원합니다.
VMware vSphere 7 또는 8과 VMware vCenter Server가 있습니다.
가상 머신(VM)을 6~10대 배포할 수 있는 용량이 있습니다. 또한 워크로드 클러스터의 기본 VM 네트워크에서 DHCP 서비스를 실행하고 있습니다.
vSphere 네트워크에서는 vCenter Server에 대한 액세스를 허용하며 DHCP에서 필요한 IP 주소를 예약하고 제외했습니다.

해결 방법

노드 등록 오류

AWS IAM Authenticator for Kubernetes 구성 맵(aws-auth ConfigMap)을 클러스터에 적용하지 않으면 다음과 같은 오류 메시지가 표시됩니다.

"Unable to register node with API server err=Unauthorized."

참고: 구성 맵은 클러스터에 등록할 노드에 대한 system:bootstrappers 및 system:nodes 역할 기반 액세스 제어(RBAC) 권한을 제공합니다.

노드 등록 오류를 해결하려면 aws-auth ConfigMap에 AWS Identity and Access Management(IAM) 역할을 추가하십시오.

Unauthorized 오류

관리형 노드 그룹을 삭제하고 이후에 aws-auth ConfigMap에서 노드 역할 항목이 삭제되면 ‘unauthorized’ 오류 메시지를 받습니다. kubelet 로그에서 API 서버에 대한 kubelet API 요청을 검토할 때 이 오류를 식별할 수 있습니다.

승인되지 않은 오류를 해결하려면 다시 aws-auth ConfigMap에 IAM 역할을 추가하십시오.

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 웹 사이트에서 부트스트랩 클러스터의 시간이 워크로드 클러스터보다 충분히 늦으면 부트스트랩 토큰이 사용 전에 만료될 수 있음을 참조하십시오.

이 오류를 해결하려면 GitHub 웹 사이트에서 보안 암호 자체가 누락된 경우 부트스트랩 보안 암호 교체를 사용하도록 수정을 참조하십시오.

부트스트랩 토큰 보안 암호 누락 오류

eksctl anywhere upgrade cluster -f cluster.yaml 명령을 실행할 때 오류 메시지가 표시될 수 있습니다. 이 오류는 워크플로의 버그로 인해 부트스트랩 토큰 보안 암호가 누락되어 발생합니다. 해당 버그는 클러스터에 연결하려는 새 노드를 차단합니다.

이 오류를 해결하려면 다음 단계를 완료하십시오.

프로비저닝된 새 시스템을 수동으로 삭제하여 부트스트랩 토큰을 새로 고칩니다.
클러스터가 정상 상태이면 Kubernetes Cluster API(CAPI)를 백업하고 CAPI 구성 요소를 관리 클러스터로 이동합니다. 설명은 부트스트랩 클러스터의 관리 구성 요소로 인한 클러스터 업그레이드 실패를 참조하십시오.

내부 오류

웹후크 검증 서비스에 연결 문제가 있는 경우 다음과 같은 내부 오류 메시지가 표시됩니다.

"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 포드를 삭제하십시오. 교체 포드가 시작되고 실행 중 상태로 이동합니다.

참고: 내부 오류는 Amazon EKS Anywhere 클러스터 버전 1.21 이하에서 발생할 수 있습니다. 이 오류를 방지하려면 클러스터를 최신 Kubernetes 버전으로 업데이트하는 것이 좋습니다.

PLEG 오류

Pod Lifecycle Event Generator(PLEG)에 문제가 발생하면 다음과 같은 오류 메시지가 표시됩니다.

"PLEG is not healthy: pleg was last seen active."

PLEG 오류를 해결하려면 다음 작업을 수행하십시오.

원격 요청 중에 발생하는 컨테이너 런타임 지연 시간 또는 제한 시간(예: 성능 저하, 교착 상태 또는 버그)을 확인하고 해결합니다.
호스트 리소스에 너무 많은 포드를 실행하거나 고사양 호스트에서 너무 많은 포드를 실행하지 않도록 합니다.
노드의 리소스 문제를 해결합니다.

PLEG에 대한 자세한 내용은 Red Hat Developer 웹 사이트에서 Pod Lifecycle Event Generator: 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을 삭제하려는 노드의 이름으로 바꾸십시오.