ComputeClasses 권장사항

플랫폼 엔지니어는 커스텀 ComputeClasses를 사용하여 Google Kubernetes Engine (GKE)에서 자동 확장 중에 노드를 만드는 데 사용하는 노드 설정 및 대체 우선순위를 선언적으로 구성할 수 있습니다. 특정 전략 및 워크로드 요구사항에 따라 ComputeClass를 만들 수 있습니다. 이 문서에서는 클러스터에서 ComputeClass를 설계하고 구현하기 위한 권장사항을 제공합니다. 이미 커스텀 ComputeClass에 익숙해야 합니다. 모든 GKE 권장사항의 통합 개요는 GKE 권장사항을 참조하세요.

ComputeClass 설계

다음 섹션에서는 확보 가능성 및 성능 극대화와 같은 목표에 따라 클러스터에서 ComputeClass를 설계하고 구현하기 위한 권장사항을 제공합니다. ComputeClass는 수동으로 만든 노드 풀과 자동으로 만든 노드 풀 모두에서 작동합니다.

전략에 따라 각 ComputeClass 설계

워크로드, 팀 또는 조직의 특정 목표를 충족하도록 각 ComputeClass를 설계합니다. ComputeClass의 대체 동작과 수동으로 만든 노드 풀과 자동으로 만든 노드 풀을 모두 선택하는 기능을 사용하여 수동 오버헤드 감소 또는 예약 성능 개선과 같은 특정 결과를 우선시합니다. 다음 섹션에서는 일반적인 전략을 설명합니다.

확보 가능성 개선 및 수동 오버헤드 감소

노드 풀 생성을 GKE에 위임하려면 ComputeClass에서 자동으로 만든 노드 풀만 사용합니다. 자동 확장 처리기는 하드웨어 가용성, 포드 리소스 요구사항, 영역별 용량에 따라 노드를 구성합니다. 이 전략은 노드 풀을 수동으로 만들고 조정할 필요가 없으며 유휴 상태의 사용되지 않는 노드 용량과 관련된 비용을 줄일 수 있습니다.

예약 성능 개선 및 노드 미세 조정

우선순위가 가장 높은 노드를 미세 조정하고 예약 지연 시간을 줄이려면 ComputeClass에서 수동으로 만든 노드 풀과 자동으로 만든 노드 풀을 혼합하여 사용합니다. 이 하이브리드 전략은 포드가 GKE에서 새 노드 풀을 만들 때까지 기다리는 빈도를 줄입니다. 우선순위가 가장 높은 노드 풀은 수동으로 만들어지므로 포드의 정확한 요구사항을 충족하도록 하드웨어를 미세 조정할 수 있습니다.

하이브리드 전략에는 ComputeClass의 우선순위에 따라 다음과 같은 유형의 노드 풀이 포함됩니다.

  1. 수동으로 만든 노드 풀: 이러한 노드 풀에는 대부분의 포드가 실행되기를 원하는 정확한 사양이 있습니다. 특정 노드 라벨, 노드 taint, 용량 예약 또는 kubelet 매개변수와 같은 특수 구성으로 이러한 노드 풀을 구성합니다. 포드에 필요한 것으로 예상되는 만큼의 노드로 이러한 노드 풀을 만듭니다. ComputeClass에서 이러한 노드 풀에 가장 높은 우선순위를 할당합니다.
  2. 자동으로 만든 노드 풀: 대체 수단으로 ComputeClass를 사용하여 포드에 여전히 최적화된 추가 노드 풀을 요청합니다. 수동으로 만든 노드 풀보다 자동으로 만든 노드 풀에 더 낮은 우선순위를 할당합니다.

다음 ComputeClass 예시에서는 이 하이브리드 전략을 사용합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: hybrid-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - nodepools: ['manual-pool1']
  - machineFamily: n4
    minCores: 16
    minMemoryGb: 64
  whenUnsatisfiable: DoNotScaleUp

이 ComputeClass를 사용하는 워크로드를 배포하면 GKE는 manual-pool1의 사용 가능한 노드에 포드를 배치합니다. GKE는 수동으로 만든 노드 풀에 사용 가능한 용량이 없는 경우에만 새 노드 풀을 만듭니다. 수동으로 만든 노드 풀의 기존 노드 수가 증가하면 GKE에서 새 노드를 자주 만들 필요가 없으므로 예약 지연 시간이 줄어듭니다.

최후의 수단 확장 동작 명시적으로 정의

whenUnsatisfiable 필드는 GKE에서 ComputeClass의 우선순위 규칙 요구사항을 충족할 수 없는 경우 발생하는 상황을 제어합니다. 버전 업그레이드 후 예상치 못한 동작을 방지하려면 모든 ComputeClass에서 이 필드의 값을 명시적으로 지정합니다. 값을 설정하면 ComputeClass 사용자가 워크로드에서 해당 ComputeClass를 선택할 때 예상되는 사항을 알 수 있습니다. 이 필드의 권장 값은 다음과 같이 워크로드 유형에 따라 다릅니다.

  • 범용 워크로드: 워크로드가 모든 머신 시리즈에서 실행될 수 있는 경우 ScaleUpAnyway 값을 지정합니다. ComputeClass의 우선순위 규칙과 일치하는 노드를 사용할 수 없는 경우 GKE는 클러스터의 기본 머신 시리즈를 사용하는 노드를 확장합니다.
  • 특수 하드웨어가 필요한 워크로드: GPU 또는 특정 Compute Engine 머신 시리즈와 같은 특정 하드웨어에 종속된 액셀러레이터 또는 고성능 컴퓨팅 워크로드의 경우 값을 지정합니다. DoNotScaleUp ComputeClass의 우선순위 규칙과 일치하는 노드를 사용할 수 없는 경우 리소스를 사용할 수 있을 때까지 포드는 Pending 상태로 유지됩니다. 이 접근 방식은 포드가 호환되지 않는 하드웨어에서 실행되지 않도록 합니다.

자세한 내용은 우선순위 규칙이 적용되지 않는 경우 확장 동작 정의를 참조하세요.

대부분의 워크로드에 클러스터 수준 기본 ComputeClass 설정

대부분의 워크로드에 동일한 하드웨어 요구사항이 있는 경우 클러스터의 기본 ComputeClass를 구성합니다. GKE는 ComputeClass를 명시적으로 선택하지 않는 모든 워크로드에 기본 ComputeClass를 적용합니다. 기본 ComputeClass를 설정하면 애플리케이션 운영자가 노드 선택기를 변경하거나 개별 포드에서 특정 노드 풀 및 하드웨어를 수동으로 요청할 필요가 없습니다. 클러스터 수준 기본 ComputeClass를 설정하는 경우 다른 ComputeClass의 노드 라벨 및 taint를 클러스터의 기존 노드 풀에 추가하지 마세요. 클러스터 수준 기본 ComputeClass를 예약하는 동안 GKE는 다른 ComputeClass의 노드 라벨 또는 노드 taint가 있는 노드 풀을 무시합니다.

네임스페이스의 기본 ComputeClass를 설정하여 테넌트 분리

클러스터 수준 기본 ComputeClass 외에도 특정 네임스페이스의 기본 ComputeClass를 set a default ComputeClass for specific namespaces 설정할 수 있습니다. 다중 테넌트 환경이 있거나 특수 하드웨어에서 실행되는 워크로드를 분리하려면 해당 네임스페이스의 기본 ComputeClass를 구성합니다. 시스템 포드가 GPU 노드와 같은 특수 하드웨어에서 실행되지 않도록 하려면 범용 ComputeClass를 시스템 네임스페이스의 기본 ComputeClass로 추가합니다.

Autopilot 모드에서 상호작용이 적은 워크로드 실행

수동 상호작용 또는 관리가 필요하지 않은 워크로드가 있는 경우 ComputeClass를 사용하여 Autopilot 모드에서 해당 워크로드를 실행합니다. Standard 클러스터가 있는 경우에도 모든 ComputeClass에서 Autopilot 모드를 사용 설정할 수 있습니다. GKE는 GKE Autopilot의 보안, 확장, 결제 기능을 구현하는 완전 관리형 노드에서 Autopilot ComputeClass를 선택하는 워크로드를 실행합니다. 자세한 내용은 Autopilot 모드 GKE Standard의 워크로드 정보를 참조하세요.

스테이트풀(Stateful) 워크로드

다음 섹션에서는 영구 데이터에 종속된 스테이트풀(Stateful) 워크로드에서 중단 또는 예상치 못한 동작을 줄이기 위한 권장사항을 제공합니다.

활성 마이그레이션 사용 중지

활성 마이그레이션은 ComputeClass에서 우선순위가 더 높거나 예약되지 않은 DaemonSet 포드를 실행할 수 있는 용량이 있는 새 노드로 포드를 자동으로 이동합니다. 활성 마이그레이션 중에 GKE는 기존 노드의 포드를 종료하고 우선순위가 더 높은 노드에 새 포드를 만듭니다. 로컬 영구 스토리지의 데이터에 종속된 워크로드가 있는 경우 포드를 새 노드로 이동하면 포드가 영구 데이터에 액세스할 수 없으므로 중단이 발생할 수 있습니다. 이 문제를 방지하려면 스테이트풀(Stateful) 워크로드에 사용되는 ComputeClass의 활성 마이그레이션을 사용 중지합니다.

StorageClass를 사용하여 예약 안정성 개선

StorageClass를 사용하여 다음과 같은 방법으로 스테이트풀(Stateful) 워크로드의 예약 안정성을 개선합니다.

확보 가능성

다음 섹션에서는 ComputeClass의 확보 가능성을 개선하여 포드가 Pending 상태로 보내는 시간을 줄이기 위한 권장사항을 제공합니다.

머신 유형 대신 머신 시리즈 요청

ComputeClass 우선순위 규칙에서 Compute Engine 머신 시리즈 또는 특정 머신 유형을 요청할 수 있습니다. 특정 머신 유형에 엄격하게 종속되지 않는 한 machineFamily 필드를 사용하여 머신 시리즈를 선택합니다. 확장 작업 중에 GKE는 해당 머신 시리즈에서 실행 가능한 머신 유형을 사용하는 노드를 만들 수 있으므로 포드가 가장 선호하는 노드 구성에서 실행될 가능성이 높아집니다.

수요가 많은 하드웨어에 용량 예약 사용

워크로드가 TPU 또는 고성능 GPU와 같이 수요가 많은 하드웨어에 종속된 경우 하드웨어의 Compute Engine 용량 예약을 만들고 ComputeClass에서 이러한 예약을 사용합니다. 용량 예약을 사용하면 리전 또는 영역에서 하드웨어를 사용할 수 있을 가능성이 높아지므로 리소스 확보 가능성을 높일 수 있습니다. 대체 동작에 영향을 주지 않고 ComputeClass에서 예약을 사용하려면 Specific 또는 AnyThenFail 예약 어피니티를 사용합니다. AnyBestEffort 또는 Automatic 어피니티를 사용하고 사용 가능한 예약 용량이 없는 경우 Compute Engine은 ComputeClass 우선순위 규칙을 무시하고 주문형 하드웨어로 대체할 수 있습니다. 자세한 내용은 예약된 영역별 리소스 소비를 참조하세요.

최소 1시간 동안 새 예약 사용하지 않음

클러스터 자동 확장 처리기는 용량 예약에 대한 정보를 캐시에 저장합니다. 새 용량 예약을 만들 때 자동 확장 처리기가 해당 예약을 검색하는 데 최대 1시간이 걸릴 수 있습니다. 예약을 만든 후 워크로드에서 해당 예약을 사용하기 전에 최소 1시간 동안 기다립니다. 자동 확장 처리기가 캐시에 예약을 저장하기 전에 예약을 사용하는 워크로드를 배포하면 자동 확장 작업이 실패할 수 있습니다.

보안

다음 섹션에서는 클러스터에서 ComputeClass의 보안을 개선하기 위한 권장사항을 제공합니다. ComputeClass를 사용하여 비용이 많이 들거나 가용성이 제한된 하드웨어를 사용하는 노드를 만들고 구성할 수 있으므로 이러한 조치는 중요합니다. 의도적 또는 실수로 인한 오용으로 인해 워크로드 중단, 계획되지 않은 리소스 사용 요금, 할당량 소진이 발생할 수 있습니다.

ComputeClass 구성에 대한 API 액세스 제한

워크로드는 ComputeClass를 사용하여 GPU 및 TPU를 비롯한 특수 하드웨어를 실행하는 노드를 만들 수 있습니다. ComputeClass를 만들고 수정하고 삭제할 수 있는 액세스 권한을 클러스터에서 노드를 만들고 수정하고 삭제할 수 있는 동일한 보안 주체로 제한합니다. ComputeClass에 대한 액세스를 제어하려면 RBAC 정책을 사용합니다.

네임스페이스별 ComputeClass 가용성 제한

GKE 고객은 Kubernetes 네임스페이스별로 여러 팀 또는 워크로드 유형을 분리하는 경우가 많습니다. ComputeClass는 클러스터 범위 리소스이므로 기본적으로 모든 네임스페이스의 모든 워크로드가 ComputeClass를 선택할 수 있습니다. 의도적 또는 실수로 인한 오용을 방지하려면 ValidatingAdmissionPolicies를 사용하여 각 네임스페이스의 워크로드가 선택할 수 있는 ComputeClass 집합을 제어합니다. 예를 들어 웹 프런트엔드 네임스페이스의 포드가 액셀러레이터를 만드는 ComputeClass를 선택하지 못하도록 할 수 있습니다. ValidatingAdmissionPolicies가 다음과 같은 일반적인 구성을 확인하는지 확인합니다.

  • 모든 선택 필드 확인: 워크로드는 포드 사양의 nodeSelector, nodeAffinity 또는 tolerations 필드를 사용하여 ComputeClass를 선택할 수 있습니다. 의도하지 않은 ComputeClass 선택을 방지하려면 ValidatingAdmissionPolicy 표현식에서 이러한 모든 필드를 확인합니다.
  • 와일드 카드 톨러레이션(toleration) 우회 확인: 와일드 카드 톨러레이션(toleration)(예: 키가 없는 operator: Exists 톨러레이션(toleration))을 명시적으로 차단하거나 검증합니다. 이러한 와일드 카드 선택기는 ComputeClass taint를 비롯한 대부분의 노드 taint를 포함할 수 있습니다.
  • 모든 워크로드 컨트롤러 확인: 모든 워크로드 컨트롤러 리소스 (Deployment, StatefulSet, DaemonSet, Job, CronJob 등)를 포함하도록 정책의 matchConstraints를 구성합니다. 검사를 Pod 리소스로만 범위 지정하지 마세요.

자세한 내용은 ComputeClass 수정 및 선택에 대한 액세스 제한을 참조하세요.

안정성

다음 섹션에서는 ComputeClass의 자동 확장 및 포드 마이그레이션의 안정성을 개선하여 중단 또는 정체된 포드의 위험을 줄이기 위한 권장사항을 제공합니다.

충돌하는 노드 선택기 사용 방지

포드의 노드 선택기는 GKE가 포드를 배치하는 위치에 영향을 미치며 Autopilot 모드 또는 노드 풀 자동 생성 시 클러스터에서 새 노드 풀 생성을 트리거할 수 있습니다. ComputeClass를 선택하고 노드 선택기를 사용하여 ComputeClass 구성과 충돌하는 노드를 요청하는 포드가 있는 경우 GKE는 포드를 전혀 예약하지 않을 수 있습니다.

예를 들어 주문형 인스턴스만 요청하는 ComputeClass를 생각해 보세요. 포드가 해당 ComputeClass를 선택하고 노드 선택기에서 스팟 VM을 선택하는 경우 ComputeClass와 노드 선택기가 서로 충돌하므로 GKE는 포드를 예약할 수 없습니다. 이 문제를 방지하려면 ValidatingAdmissionPolicies와 같은 메서드를 사용하여 ComputeClass를 선택하는 포드가 시스템 노드 라벨도 선택하지 못하도록 합니다. 자세한 내용은 시스템 노드 라벨의 노드 선택기를 참조하세요.

활성 마이그레이션 및 자동 확장 설정에 대한 모든 변경사항 테스트

ComputeClass의 활성 마이그레이션 및 자동 확장 설정은 포드를 더 선호하는 하드웨어로 이동하고 활용도가 낮은 노드를 통합하는 등의 작업을 수행하기 위해 GKE가 포드를 종료하는 빈도에 직접적인 영향을 미칩니다. 기존 ComputeClass에서 이러한 설정을 수정하면 예상치 못한 워크로드 중단이 발생할 수 있습니다. 기존 ComputeClass에서 이러한 설정을 수정하기 전에 스테이징 환경에서 변경사항을 테스트합니다. 주석을 사용하여 확장 중에 중요한 워크로드가 삭제되지 않도록 보호할 수도 있습니다 .

클러스터 업그레이드 전에 ComputeClass CRD 업데이트 테스트

GKE는 필드를 추가하고 필드 동작을 수정하고 문제를 해결하기 위해 ComputeClass CustomResourceDefinition(CRD)을 정기적으로 업데이트합니다. 필드 추가 및 수정은 일반적으로 특정 GKE 버전에서 적용됩니다. 프로덕션 클러스터를 새 부 버전 또는 패치 버전으로 업그레이드하기 전에 다음 가이드라인에 따라 CRD 변경사항으로 인해 워크로드 문제가 발생하는지 확인합니다.

  • 스테이징 환경에서 업그레이드를 테스트합니다.
  • ComputeClass CRD의 변경사항 또는 추가사항은 GKE 출시 노트 를 확인합니다.
  • 대상 업그레이드 버전의 필드 업데이트는 ComputeClass CRD 참조 페이지를 확인합니다.

PodDisruptionBudget을 사용하여 워크로드 가용성 개선

활성 마이그레이션과 같이 포드 삭제를 유발하는 ComputeClass 작업은 구성된 PodDisruptionBudgets을(를) 준수합니다. 예를 들어 포드의 70% 이상을 사용할 수 있어야 하는 PodDisruptionBudget이 있도록 추론 배포를 구성할 수 있습니다. 활성 마이그레이션 중에 포드 삭제가 해당 예산을 위반하는 경우 GKE는 포드를 삭제하지 않습니다. 다음과 같은 워크로드에 PodDisruptionBudget을 지정합니다.

  • 추론 배포와 같은 스테이트리스(Stateless) 워크로드
  • 고가용성 데이터베이스 애플리케이션과 같은 복제된 스테이트풀(Stateful) 워크로드

완료까지 실행해야 하거나 인스턴스가 하나만 있거나 로컬 영구 데이터에 종속된 워크로드를 보호하기 위해 PodDisruptionBudget에 의존하지 마세요. 워크로드 가용성 간의 균형을 맞추고 업그레이드와 같은 함수가 완료되도록 허용하는 예산을 지정합니다.

삭제로부터 중요한 워크로드 보호

각 포드가 종료되기 전에 완료까지 실행해야 하는 워크로드가 있는 경우 포드 사양에 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 주석을 추가합니다. 이 주석은 자동 확장 작업 중에 GKE가 포드를 삭제하지 못하도록 합니다. 이 주석을 사용하여 단일 인스턴스 스테이트풀(Stateful) 워크로드 및 장기 실행 일괄 작업과 같이 중단을 허용할 수 없는 포드를 보호합니다.

권장사항 요약

이 문서에는 ComputeClass에 대한 다음과 같은 권장사항이 있습니다.

다음 단계