관리형 노드 업데이트 동작 - Amazon EKS

관리형 노드 업데이트 동작

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. 최신 레이블이 없는 노드 그룹의 모든 노드에 eks.amazonaws.com/nodegroup=unschedulable:NoSchedule 테인트를 적용합니다. 이렇게 하면 이전에 실패한 업데이트에서 이미 업데이트된 노드가 오염되지 않습니다.

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

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

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

  • 사용자 정의 사용자 데이터 - 사용자 정의 사용자 데이터로 인해 부트스트랩 프로세스가 중단될 수 있습니다. 이 시나리오에서는 노드에서 kubelet이 시작되지 않거나 예상되는 Amazon EKS 레이블을 가져오지 못할 수 있습니다. 사용자 정의 LT/AMI 처리에 대한 자세한 내용은 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가 워크플로의 축소 단계에서 노드 그룹을 확장하고 있다고 판단하면 노드 그룹을 원래 크기로 되돌리지 않고 즉시 종료됩니다.