Amazon EKS 노드 그룹 업데이트 실패와 관련된 일반 문제를 해결하려면 어떻게 해야 하나요?

간략한 설명

관리형 노드 그룹 업데이트를 시작하면 Amazon EKS가 노드를 자동으로 업데이트합니다. Amazon EKS에 최적화된 AMI를 사용하는 경우 Amazon EKS가 노드에 최신 보안 패치 및 운영 체제 업데이트를 자동으로 적용합니다.

이 업데이트 프로세스 중에 다음과 같은 오류가 표시될 수 있습니다. 발생한 오류에 대한 관련 문제 해결 단계를 따르세요. 업데이트 오류에 대해 자세히 알아보려면 관리형 노드 업데이트 동작을 참조하세요.

해결 방법

PodEvictionFailure로 인한 업데이트 실패

다음 오류는 PodEvictionFailure로 인해 업그레이드가 차단됨을 나타냅니다.

"Error message : Reached max retries while trying to evict pods from nodes in node group."

포드가 15분 이내에 노드를 떠나지 않으며 강제 플래그가 없는 경우, PodEvictionFailure 오류와 함께 업그레이드 단계에 실패합니다.

PodEvictionFailure 오류는 다음과 같은 이유로 발생할 수 있습니다.

과도한 PDB(포드 중단 예산)

동일한 포드를 가리키는 PDB가 여러 개 있는 경우 해당 포드는 과도한 PDB로 정의됩니다.

PDB는 특정 시간에 포드 클래스가 감당할 수 있는 중단의 수(또는 "장애 예산")를 나타냅니다. 자발적 중단으로 인해 서비스의 포드가 예산 미만으로 떨어질 경우, 예산을 유지할 수 있게 될 때까지 작업이 일시 중지됩니다. 노드 고갈 이벤트는 더 많은 포드를 사용할 수 있게 될 때까지 일시 중지됩니다. 이렇게 하면 포드를 제거하여 예산이 초과되지 않도록 할 수 있습니다. 자세한 내용을 알아보려면 Kubernetes 웹사이트의 중단(disruption)을 참조하세요.

원활한 관리형 노드 그룹 업데이트를 확인하려면 포드 중단 예산을 일시적으로 제거하거나 강제 옵션을 통해 업데이트하세요. 이 옵션은 포드 중단 예산을 고려하지 않습니다. 대신 노드를 강제로 다시 시작하여 업데이트를 구현합니다.

**참고:**앱이 Quorum 기반 애플리케이션인 경우 강제 옵션을 사용하면 애플리케이션을 일시적으로 사용할 수 없게 될 수 있습니다.

클러스터에 PDB가 구성되어 있는지 확인하려면 다음의 명령을 실행하세요.

$ kubectl get pdb --all-namespaces

또는 Amazon EKS 콘솔에서 감사 로깅을 활성화한 경우 다음 단계를 따르세요.

1. 클러스터 탭 아래의 목록에서 원하는 클러스터(예: rpam-eks-qa2-control-plane)를 선택합니다.

2. 로깅 탭 아래에서 감사를 선택합니다. 이 작업을 수행하면 Amazon CloudWatch 콘솔로 리디렉션됩니다.

3. CloudWatch 콘솔에서 로그를 선택합니다. 그런 다음 로그 인사이트를 선택하고 다음 쿼리를 실행합니다.

   fields @timestamp, @message| filter @logStream like "kube-apiserver-audit"
   | filter ispresent(requestURI)
   | filter objectRef.subresource = "eviction"
   | display @logStream, requestURI, responseObject.message
   | stats count(*) as retry by requestURI, responseObject.message

4. 사용자 지정을 선택하여 업데이트 날짜를 확인합니다. 과도한 PDB로 인해 노드 그룹 업데이트에 실패하는 경우 resposeObject.message가 포드 제거 실패 이유를 설명합니다.

5. PDB가 실패를 초래한 경우 PDB를 수정합니다. 다음 명령을 실행한 다음 해당 노드 그룹을 다시 업그레이드합니다.

   $ kubectl edit pdb pdb_name;

모든 테인트를 감당할 수 있는 배포

모든 포드가 제거되면 이전 단계에서 노드가 테인트되었기 때문에 노드가 비어 있게 됩니다. 그러나 배포가 모든 테인트를 감당한다면 노드가 비어 있지 않을 가능성이 더 큽니다. 이는 포드 제거 실패를 유발합니다. 자세한 내용을 알아보려면 Kubernetes 웹사이트의 테인트 및 톨러레이션을 참조하세요.

유효하지 않은 릴리스 버전으로 인한 업데이트 실패

유효하지 않은 릴리스 버전이 있는 경우 다음과 같은 오류가 표시될 수 있습니다.

"Error Message: Requested release version 1.xx is not valid for kubernetes version 1.xx."

이 문제를 해결하려면 업그레이드 명령을 다시 실행하세요. 이 명령이 그룹을 컨트롤 플레인의 Kubernetes 버전과 동일한 버전으로 업그레이드합니다.

eksctl upgrade nodegroup --name=test --cluster=test --kubernetes-version=1.xx

**참고:**1.xx 버전을 Amazon EKS 컨트롤 플레인에서 지원하는 버전으로 교체하세요.

노드 그룹 상태 문제로 인한 업데이트 실패

노드 그룹에 상태 문제가 있는 경우 업데이트 실패로 인해 다음과 같은 오류가 반환됩니다.

"Error message: Nodegroup has health issue other than [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]"

이는 노드 그룹의 Auto Scaling 그룹이 Amazon Elastic Compute Cloud(Amazon EC2) 시작 템플릿의 기대되는 버전을 찾을 수 없음을 나타냅니다. 이 오류는 노드 그룹과 연결된 템플릿 버전을 수동으로 수정하거나 삭제하는 경우에 발생합니다. 이로 인해 EKS는 노드 그룹을 성능이 저하된 것으로 표시합니다.

시작 템플릿을 삭제하지 않은 경우 Auto Scaling 그룹의 시작 템플릿 버전을 수동으로 다시 적절한 버전으로 변경하세요. 이 작업을 수행하면 노드 그룹이 정상 및 활성 상태로 되돌아가며, 업데이트 프로세스를 다시 시작할 수 있게 됩니다.

새 노드가 노드 그룹에 조인하지 않아 업데이트 실패

이 문제는 노드 그룹의 새 노드가 클러스터에 조인할 수 없는 경우에 발생합니다. 따라서 노드 그룹이 이전 버전으로 롤백됩니다. 이 경우 다음과 같은 오류가 표시될 수 있습니다.

"NodeCreationFailure
Couldn't proceed with upgrade process as new nodes are not joining node group ng-backend"

업데이트된 노드가 클러스터에 조인할 수 없는 이유에는 여러 가지가 있습니다.

기존 노드 그룹에서 사용하는 보안 그룹 규칙을 변경함

노드 보안 그룹의 아웃바운드 규칙이 클러스터의 보안 그룹에 포트 443을 허용하는지 검증하세요.

클러스터의 보안 그룹이 노드 보안 그룹의 트래픽을 허용하지 않음

클러스터 보안 그룹의 인바운드 규칙이 노드 보안 그룹의 포트 443을 허용하는지 검증하세요. 자세한 내용을 알아보려면 Amazon EKS 보안 그룹 요구 사항 및 고려 사항을 참조하세요.

사용자 지정 시작 템플릿으로 노드 그룹을 생성함

사용자 지정 시작 템플릿을 업데이트하는 경우 새 버전의 템플릿에 올바른 사용자 데이터가 있어야 합니다. 또한 사용자 지정 AMI를 사용하는 경우 AMI를 클러스터에 조인하도록 올바르게 구성했는지 확인하세요.

시작 템플릿 문제를 해결하려면 동일한 시작 템플릿을 통해 새 노드 그룹을 생성하세요. 템플릿이 사용자 지정 AMI의 최신 버전을 사용하는지 확인하세요. 그런 다음 노드가 클러스터에 성공적으로 조인하는지 확인하세요. 노드가 클러스터에 조인하지 않는 경우 SSH를 통해 노드 인스턴스에 연결하고 kubelet 로그를 확인하세요.

누락된 IAM 권한이 있음

해당 노드 그룹에 대한 AWS Identity and Access Management(IAM) 역할에 필수 권한이 있는지 확인하세요.

ACL이 트래픽을 거부함

노드 서브넷의 액세스 제어 목록(ACL)이 포트 443에 대한 아웃바운드 트래픽 또는 임시 포트에 대한 인바운드 트래픽을 거부할 수 있습니다. 노드의 서브넷에 이러한 규칙을 허용했는지 확인하세요.

마찬가지로 클러스터 서브넷의 ACL이 포트 443에 대한 인바운드 트래픽을 거부할 수 있습니다. 클러스터의 서브넷에 대해 이 트래픽을 허용했는지 확인하세요.

새 노드가 플러그인을 추가하는 데 실패함

Amazon Virtual Private Cloud(Amazon VPC) CNI 플러그인 또는 kube-proxy 추가 기능이 새 노드에 표시되는 데 실패할 수 있습니다. 자세한 내용을 알아보려면 Amazon EKS에 대한 kubelet 또는 CNI 플러그인 문제를 해결하려면 어떻게 해야 하나요?를 참조하세요.

서브넷에 연결 문제가 있음

Amazon EKS가 노드를 생성하는 서브넷이 필수적인 엔드포인트와 연결되지 않았을 수 있습니다. 이러한 엔드포인트에는 Amazon Elastic Container Registry(Amazon ECR), Amazon Simple Storage Service(Amazon S3) 또는 Amazon EC2가 포함될 수 있습니다. 인터넷 또는 VPC 엔드포인트를 통한 연결에 실패할 수 있습니다. VPC 엔드포인트의 경우 노드와 엔드포인트의 보안 그룹이 필수적인 트래픽을 허용하는지 확인하세요. NAT 게이트웨이 또는 인터넷 게이트웨이를 사용하는 경우, 서브넷의 라우팅 테이블에 있는 라우팅 규칙이 올바른지 검증하세요. 또한 해당 NAT 게이트웨이 또는 인터넷 게이트웨이가 존재하는지 검증하세요.