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

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

Amazon EKS 관리형 워커 노드 업그레이드 전략의 네 단계를 설명합니다.

출처: 문서

본문

Amazon EKS 관리형 워커 노드 업그레이드 전략은 다음 섹션에 설명된 네 단계로 구성됩니다.

설정 단계(Setup phase)

설정 단계에는 다음 단계가 있습니다.

• 노드 그룹과 연결된 Auto Scaling 그룹에 대한 새 Amazon EC2 런치 템플릿 버전을 생성합니다. 새 런치 템플릿 버전은 업데이트에 대상 AMI 또는 사용자 지정 런치 템플릿 버전을 사용합니다.
• Auto Scaling 그룹이 최신 런치 템플릿 버전을 사용하도록 업데이트합니다.
• 노드 그룹의 updateConfig 속성을 사용해 병렬로 업그레이드할 최대 노드 수를 결정합니다. 최대 사용 불가(maximum unavailable)에는 100개 노드 할당량이 있습니다. 기본값은 1개 노드입니다. 자세한 내용은 Amazon EKS API Reference의 updateConfig 속성을 참고하세요.

확장 단계(Scale up phase)

관리형 노드 그룹의 노드를 업그레이드할 때 업그레이드된 노드는 업그레이드 중인 노드와 동일한 가용 영역에서 시작됩니다. 이 배치를 보장하기 위해 Amazon EC2의 가용 영역 리밸런싱(Availability Zone Rebalancing)을 사용합니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 "가용 영역 리밸런싱"을 참고하세요. 이 요구 사항을 충족하기 위해 관리형 노드 그룹의 가용 영역당 최대 두 개의 인스턴스를 시작할 수 있습니다.

확장 단계에는 다음 단계가 있습니다.

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

  • Auto Scaling 그룹이 배포된 가용 영역 수의 최대 두 배.
  • 업그레이드의 최대 사용 불가.

  예를 들어 노드 그룹에 5개의 가용 영역이 있고 maxUnavailable이 1이면 업그레이드 프로세스는 최대 10개의 노드를 시작할 수 있습니다. 그러나 maxUnavailable이 20(또는 10보다 큰 값)이라면 프로세스는 20개의 새 노드를 시작합니다.

• 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

참고: 스케일링 구성 변경 없이 업데이트나 업그레이드를 시작하면 워크플로는 노드 그룹에 저장된 스케일링 구성이 아니라 라이브 Auto Scaling 그룹 값을 시작점으로 사용합니다. 자세한 내용은 "관리형 노드 그룹 개념"을 참고하세요.

• 새 Pod가 스케줄되지 않도록 노드를 예약 불가(unschedulable)로 표시합니다. 또한 노드를 종료하기 전에 로드 밸런서에서 이전 노드를 제거하기 위해 node.kubernetes.io/exclude-from-external-load-balancers=true 라벨을 노드에 지정합니다.

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

• 가용 영역의 용량 부족 – 가용 영역에 요청한 인스턴스 유형의 용량이 없을 수 있습니다. 관리형 노드 그룹을 만들 때 여러 인스턴스 유형을 구성할 것을 권장합니다.
• 계정의 EC2 인스턴스 한도 – Service Quotas를 사용해 계정이 동시에 실행할 수 있는 Amazon EC2 인스턴스 수를 늘려야 할 수 있습니다. 자세한 내용은 Amazon Elastic Compute Cloud 사용 설명서(Linux 인스턴스용)의 "EC2 Service Quotas"를 참고하세요.
• 사용자 지정 사용자 데이터 – 사용자 지정 사용자 데이터가 부트스트랩 프로세스를 깨뜨릴 수 있습니다. 이 시나리오는 kubelet이 노드에서 시작되지 않거나 노드가 예상 Amazon EKS 라벨을 받지 못하게 할 수 있습니다. 자세한 내용은 "AMI 지정"을 참고하세요.
• 노드를 비정상 또는 미준비 상태로 만드는 모든 변경 – 노드 디스크 압력, 메모리 압력 및 유사한 조건이 노드를 Ready 상태로 만들지 못하게 할 수 있습니다.
• 각 노드는 15분 내에 부트스트랩해야 함 – 노드가 부트스트랩하고 클러스터에 가입하는 데 15분보다 오래 걸리면 업그레이드가 시간 초과됩니다. 이는 새 노드가 필요할 때부터 클러스터에 가입할 때까지 측정한 새 노드 부트스트랩의 총 실행 시간입니다. 관리형 노드 그룹을 업그레이드할 때 Auto Scaling 그룹 크기가 증가하는 즉시 시간 카운터가 시작됩니다.

업그레이드 단계(Upgrade phase)

업그레이드 단계는 업데이트 전략에 따라 두 가지 방식으로 동작합니다. 두 가지 업데이트 전략이 있습니다: 기본(default)과 최소(minimal).

대부분의 시나리오에서 기본 전략을 권장합니다. 이 전략은 이전 노드를 종료하기 전에 새 노드를 생성하므로 업그레이드 단계 중에 사용 가능한 용량이 유지됩니다. 최소 전략은 GPU 같은 하드웨어 가속기로 리소스나 비용이 제한된 시나리오에서 유용합니다. 이 전략은 새 노드를 생성하기 전에 이전 노드를 종료하므로 총 용량이 구성된 수량을 넘어 증가하지 않습니다.

기본 업데이트 전략에는 다음 단계가 있습니다.

• Auto Scaling 그룹의 노드 수(원하는 수)를 늘려 노드 그룹이 추가 노드를 만들게 합니다.
• 노드 그룹에 구성된 최대 사용 불가까지 업그레이드가 필요한 노드를 무작위로 선택합니다.
• 새 노드가 Ready 상태에 도달하는 즉시 이전 노드를 cordon하여 서비스 컨트롤러가 해당 노드에 새 요청을 보내지 못하게 합니다.
• 노드에서 Pod를 드레인합니다. Pod가 15분 내에 노드를 떠나지 않고 force 플래그가 없으면 업그레이드 단계가 PodEvictionFailure 오류로 실패합니다. 이 시나리오에서는 Pod를 삭제하기 위해 update-nodegroup-version 요청으로 force 플래그를 적용할 수 있습니다.
• 모든 Pod를 축출한 후 60초를 기다립니다. 그런 다음 Auto Scaling 그룹에 종료 요청을 보내고 노드를 활성 노드 목록에서 제거합니다.
• 노드 그룹에 이전 버전의 런치 템플릿으로 배포된 노드가 없을 때까지 이전 업그레이드 단계를 반복합니다.

최소 업데이트 전략에는 다음 단계가 있습니다.

• 시작 시 노드 그룹의 모든 노드를 cordon하여 서비스 컨트롤러가 이 노드에 새 요청을 보내지 못하게 합니다.
• 노드 그룹에 구성된 최대 사용 불가까지 업그레이드가 필요한 노드를 무작위로 선택합니다.
• 선택한 노드에서 Pod를 드레인합니다. Pod가 15분 내에 노드를 떠나지 않고 force 플래그가 없으면 업그레이드 단계가 PodEvictionFailure 오류로 실패합니다. 이 시나리오에서는 Pod를 삭제하기 위해 update-nodegroup-version 요청으로 force 플래그를 적용할 수 있습니다.
• 모든 Pod가 축출되고 60초를 기다린 후 선택한 노드에 대해 Auto Scaling 그룹에 종료 요청을 보냅니다. Auto Scaling 그룹은 부족한 용량을 대체하기 위해 새 노드(선택한 노드 수와 동일)를 생성합니다.
• 노드 그룹에 이전 버전의 런치 템플릿으로 배포된 노드가 없을 때까지 이전 업그레이드 단계를 반복합니다.

업그레이드 단계 중 PodEvictionFailure 오류

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

• 공격적인 PDB – Pod에 공격적인 PDB가 정의되어 있거나 여러 PDB가 같은 Pod를 가리키고 있습니다.
• 모든 taint를 허용하는 배포 – 모든 Pod가 축출되면 이전 단계에서 노드가 tainted되었으므로 노드가 비어 있을 것으로 예상됩니다. 그러나 배포가 모든 taint를 허용(tolerate)한다면 노드가 비어 있지 않을 가능성이 높아 Pod 축출 실패로 이어집니다.

축소 단계(Scale down phase)

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

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

참고: 노드 그룹에 웜 풀이 활성화되어 있다면 확장 작업을 시작하기 전에 웜 풀 인스턴스가 드레인됩니다. 웜 풀 인스턴스가 새 런치 템플릿 구성으로 업데이트되지 않았기 때문입니다. 확장 단계 중에 업데이트된 구성으로 새 인스턴스를 시작하는 대신 웜 풀 인스턴스가 Auto Scaling 그룹으로 끌려 들어가면 업그레이드 프로세스가 깨질 수 있습니다. 웜 풀을 드레인하면 업데이트된 구성의 새 인스턴스만 시작되도록 보장됩니다. 축소 작업이 완료되면 웜 풀이 복원되고, 웜 풀의 새 인스턴스가 업데이트된 런치 템플릿 구성으로 시작됩니다.

웜 풀에 대한 자세한 내용은 "관리형 노드 그룹과 웜 풀을 사용한 부팅 시간이 긴 애플리케이션의 지연 시간 감소"를 참고하세요.

더 알아보기 (Learn more)

• 공식 문서