Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

ComputeClasses 권장사항

Autopilot Standard

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

ComputeClass 설계

다음 섹션에서는 컴퓨팅 용량의 유연성, 효율성, 가용성, 성능을 극대화하는 것과 같은 목표에 따라 클러스터에서 ComputeClass를 설계하고 구현하기 위한 권장사항을 제공합니다. ComputeClass는 수동으로 생성된 노드 풀과 자동으로 생성된 노드 풀 모두에서 작동합니다.

전략에 따라 각 ComputeClass 설계

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

리소스 가용성 개선 및 수동 오버헤드 감소

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

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

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

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

수동으로 생성된 노드 풀: 이러한 노드 풀에는 대부분의 포드가 실행되기를 원하는 정확한 사양이 있습니다. 특정 노드 라벨, 노드 테인트, 용량 예약 또는 kubelet 매개변수와 같은 특수 구성으로 이러한 노드 풀을 구성합니다. 포드에 필요한 만큼의 노드로 이러한 노드 풀을 만듭니다. ComputeClass에서 이러한 노드 풀에 가장 높은 우선순위를 할당합니다.
자동 생성 노드 풀: 대체 조치로 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의 노드 라벨 또는 노드 테인트가 있는 노드 풀을 무시합니다.

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

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

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

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

스테이트풀 워크로드

다음 섹션에서는 영구 데이터를 사용하는 스테이트풀 워크로드에서 중단이나 예기치 않은 동작을 줄이기 위한 권장사항을 제공합니다.

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

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

StorageClass를 사용하여 예약 안정성 향상

StorageClass를 사용하여 다음과 같은 방식으로 스테이트풀 워크로드의 예약 안정성을 개선하세요.

포드 생성 후에만 볼륨 생성: 동적 볼륨 프로비저닝을 사용하는 경우 StorageClass의 volumeBindingMode 필드에 WaitForFirstConsumer 값을 지정합니다. 이 볼륨 바인딩 모드는 GKE가 해당 PersistentVolumeClaim을 사용하는 포드를 생성할 때까지 PersistentVolume이 생성되지 않도록 합니다. GKE는 포드를 실행하는 노드와 동일한 영역에 PersistentVolume을 프로비저닝합니다.
토폴로지 인식 StorageClass 사용: ComputeClass가 여러 세대의 머신 시리즈 (예: C4 및 C3)에 걸쳐 있는 경우 자동 디스크 유형 선택이 사용 설정되어 있고 지정된 디스크 유형을 지원하는 노드에서만 예약되는 StorageClass를 사용합니다. 기본 제공 dynamic-rwo StorageClass 또는 커스텀 StorageClass를 사용할 수 있습니다. 클러스터 자동 스케일러가 호환되는 디스크 유형을 동적으로 선택하므로 스테이트풀 워크로드가 여러 Compute Engine 인스턴스 세대에서 실행될 수 있습니다.

컴퓨팅 용량의 유연성, 효율성, 가용성을 고려하여 인프라 설계

다음 섹션에서는 포드가 Pending 상태로 있는 시간을 줄일 수 있도록 ComputeClass에서 컴퓨팅 용량의 유연성, 효율성, 가용성을 개선하기 위한 권장사항을 제공합니다.

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

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 액세스 제한

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

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

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

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

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

안정성

다음 섹션에서는 ComputeClass의 자동 확장 및 포드 이전을 개선하여 중단 또는 멈춘 포드의 위험을 줄이는 권장사항을 제공합니다.

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

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

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

활성 이전 및 자동 확장 설정의 모든 변경사항 테스트

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

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

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

스테이징 환경에서 업그레이드를 테스트합니다.
GKE 출시 노트에서 ComputeClass CRD의 변경사항이나 추가사항을 확인하세요.
타겟 업그레이드 버전의 필드 업데이트는 ComputeClass CRD 참조 페이지를 확인하세요.

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

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

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

완료될 때까지 실행되어야 하거나, 인스턴스가 하나만 있거나, 로컬 영구 데이터를 사용하는 워크로드를 보호하기 위해 PodDisruptionBudget을 사용하지 마세요. 워크로드 가용성 간의 균형을 유지하고 업그레이드와 같은 기능이 완료될 수 있는 예산을 지정합니다.

중요한 워크로드가 강제 종료되지 않도록 보호

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