노드 업데이트의 각 단계 이해 - Amazon EKS
설정 단계확장 단계업그레이드 단계축소 단계

이 페이지 개선에 도움 주기

이 사용자 설명서에 기여하고 싶으신가요? 이 페이지 하단으로 스크롤하여 GitHub에서 이 페이지 편집을 선택하세요. 여러분의 기여는 모두를 위한 더 나은 사용자 설명서를 만드는 데 도움이 됩니다.

노드 업데이트의 각 단계 이해

Amazon EKS 관리형 작업자 노드 업그레이드 전략에는 다음 섹션에서 설명하는 4가지 단계가 있습니다.

설정 단계

설정 단계는 다음과 같습니다.

  1. 노드 그룹과 연결된 Auto Scaling 그룹의 새 Amazon EC2 시작 템플릿 버전을 생성합니다. 새 시작 템플릿 버전은 업데이트를 위해 대상 AMI 또는 사용자 지정 시작 템플릿 버전을 사용합니다.

  2. 최신 시작 템플릿 버전을 사용하도록 Auto Scaling 그룹을 업데이트합니다.

  3. 노드 그룹의 updateConfig 속성을 사용하여 병렬로 업그레이드할 최대 노드 수를 결정합니다. 사용할 수 없는 최대 노드의 할당량은 100개입니다. 기본값은 노드 1개입니다. 자세한 내용은 Amazon EKS API 참조의 updateConfig 속성을 참조하세요.

확장 단계

관리형 노드 그룹의 노드를 업그레이드할 때 업그레이드된 노드는 업그레이드 중인 노드와 동일한 가용 영역에서 시작됩니다. 이 배치를 보장하기 위해 Amazon EC2의 가용 영역 재분배를 사용합니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 가용 영역 재분배를 참조하세요. 이 요구 사항이 충족되도록 관리형 노드 그룹의 가용 영역당 최대 2개의 인스턴스를 시작할 수 있습니다.

확장 단계는 다음과 같습니다.

  1. Auto Scaling 그룹의 최대 크기와 원하는 크기를 다음 중 더 큰 값으로 늘립니다.

    • Auto Scaling 그룹이 배포된 가용 영역 수의 최대 2배

    • 업그레이드할 수 없는 최대값입니다.

      예를 들어 노드 그룹에 5개의 가용 영역이 있고 maxUnavailable이 하나인 경우 업그레이드 프로세스에서 최대 10개의 노드를 시작할 수 있습니다. 하지만 maxUnavailable이 20이거나 10보다 크면 프로세스에서 20개의 새 노드를 시작합니다.

  2. Auto Scaling 그룹 규모를 조정한 후 노드 그룹에 최신 구성을 사용하는 노드가 있는지 확인합니다. 이 단계는 다음 기준을 충족하는 경우에만 성공합니다.

    • 노드가 있는 모든 가용 영역에서 하나 이상의 새 노드가 시작됩니다.

    • 모든 새 노드는 Ready 상태여야 합니다.

    • 새 노드에 Amazon EKS 적용 레이블이 있어야 합니다.

      다음은 일반 노드 그룹에 있는 작업자 노드의 Amazon EKS 적용 레이블입니다.

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      다음은 사용자 정의 시작 템플릿 또는 AMI 노드 그룹에 있는 작업자 노드의 Amazon EKS 적용 레이블입니다.

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. 새 Pods의 스케줄링을 피하기 위해 노드를 스케줄 불가능으로 표시합니다. 또한 노드를 종료하기 전에 로드 밸런서에서 노드를 제거하도록 node.kubernetes.io/exclude-from-external-load-balancers=true로 노드에 레이블을 지정합니다.

이 단계에서 NodeCreationFailure 오류가 발생하는 알려진 이유는 다음과 같습니다.

가용 영역의 용량 부족

요청된 인스턴스 유형의 용량이 가용 영역에 없을 가능성이 있습니다. 관리형 노드 그룹을 생성하는 동안 여러 인스턴스 유형을 구성하는 것이 좋습니다.

계정의 EC2 인스턴스 제한

Service Quotas를 사용하여 계정이 동시에 실행할 수 있는 Amazon EC2 인스턴스 수를 늘려야 할 수 있습니다. 자세한 내용은 Linux 인스턴스용 Amazon Elastic Compute Cloud 사용 설명서의 EC2 Service Quotas를 참조하세요.

사용자 정의 사용자 데이터

사용자 정의 사용자 데이터로 인해 부트스트랩 프로세스가 중단될 수 있습니다. 이 시나리오에서는 노드에서 kubelet이 시작되지 않거나 예상되는 Amazon EKS 레이블을 가져오지 못할 수 있습니다. 자세한 내용은 AMI 지정 단원을 참조하십시오.

노드를 비정상적이거나 준비되지 않은 상태로 만드는 모든 변경 사항

노드 디스크 압력, 메모리 압력 및 이와 유사한 조건으로 인해 노드가 Ready 상태가 되지 않을 수 있습니다.

업그레이드 단계

업그레이드 단계는 다음과 같습니다.

  1. 노드 그룹에 대해 구성된 사용 불가능한 최대값까지 업그레이드해야 하는 노드를 무작위로 선택합니다.

  2. 노드에서 Pods를 드레이닝합니다. Pods가 15분 이내에 노드를 떠나지 않고 force 플래그가 없으면 PodEvictionFailure 오류와 함께 업그레이드 단계가 실패합니다. 이 시나리오에서는 update-nodegroup-version 요청과 함께 force 플래그를 적용하여 Pods를 삭제할 수 있습니다.

  3. 모든 Pod가 제거된 후 노드를 차단하고 60초 동안 기다립니다. 이 작업은 서비스 컨트롤러가 이 노드에 새 요청을 보내지 않고 활성 노드 목록에서 이 노드를 제거하도록 하기 위해 수행됩니다.

  4. 코드화된 노드에 대한 Auto Scaling 그룹에 종료 요청을 보냅니다.

  5. 이전 버전의 시작 템플릿으로 배포된 노드 그룹에 노드가 없을 때까지 이전 업그레이드 단계를 반복합니다.

이 단계에서 PodEvictionFailure 오류가 발생하는 알려진 이유는 다음과 같습니다.

적극적인 PDB

적극적인 PDB가 Pod에 정의되어 있거나 동일한 Pod를 가리키는 여러 PDB가 있습니다.

모든 테인트를 허용하는 배포

모든 Pod가 제거되면 이전 단계에서 노드가 테인트되었기 때문에 노드가 비어 있어야 합니다. 그러나 배포가 모든 테인트를 허용하는 경우 노드가 비어 있지 않을 가능성이 높아져 Pod 제거 실패로 이어집니다.

축소 단계

축소 단계는 Auto Scaling 그룹의 최대 크기와 원하는 크기를 하나씩 줄여 업데이트가 시작되기 전의 값으로 돌아갑니다.

업그레이드 워크플로에서 Cluster Autoscaler가 워크플로의 축소 단계에서 노드 그룹을 확장하고 있다고 판단하면 노드 그룹을 원래 크기로 되돌리지 않고 즉시 종료됩니다.