이 페이지는 Cloud Translation API를 통해 번역되었습니다.

커스텀 ComputeClass로 자동 확장된 노드 속성 제어

Autopilot Standard

이 문서에서는 커스텀 ComputeClasses를 사용하여 워크로드의 특정 요구사항에 따라 Google Kubernetes Engine (GKE) 클러스터의 컴퓨팅 인프라 및 자동 확장 동작을 제어하는 방법을 보여줍니다.

이 문서는 노드의 자동 확장 프로필을 선언적으로 정의하려는 플랫폼 관리자와 특정 ComputeClass에서 워크로드를 실행하려는 클러스터 운영자를 위해 작성되었습니다.

맞춤 ComputeClass 정보

커스텀 ComputeClass는 워크로드를 실행하도록 노드를 프로비저닝할 때 GKE가 따라야 할 우선순위를 정의할 수 있는 Kubernetes 커스텀 리소스입니다. 커스텀 ComputeClass를 사용하여 다음 작업을 할 수 있습니다.

Compute Engine 머신 시리즈 또는 최소 리소스 용량과 같은 특정 매개변수가 각각 포함된 노드를 프로비저닝할 때 GKE에 순차적으로 따를 일련의 우선순위를 부여합니다.
사용률이 낮은 노드를 삭제하고 기존 컴퓨팅 용량에서 워크로드를 효율적으로 통합하기 위한 자동 확장 기준점 및 매개변수 정의
최적의 워크로드 성능을 위해 선호도가 낮은 노드 구성을 선호도가 높은 노드 구성으로 자동 교체하도록 GKE에 지시

모든 구성 옵션과 옵션 간의 상호작용 방식, GKE Autopilot 모드 및 GKE Standard 모드와의 상호작용 방식을 알아보려면 커스텀 ComputeClass 정보를 참고하세요.

가격 책정

ComputeClass 커스텀 리소스는 GKE에서 추가 비용 없이 제공됩니다. 다음과 같은 가격 책정 고려사항이 적용됩니다.

GKE Autopilot 모드: 노드 기반 결제 모드를 사용하여 요금이 청구됩니다. 자세한 내용은 Autopilot 모드 가격 책정을 참고하세요.
GKE Standard 모드: Standard 모드 가격 책정을 참고하세요.

제한사항

ComputeClass의 이름은 gke 또는 autopilot로 시작할 수 없습니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

Google Kubernetes Engine API를 사용 설정합니다.

Google Kubernetes Engine API 사용 설정

이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우 gcloud components update 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
참고: 기존 gcloud CLI 설치의 경우 compute/region 속성을 설정해야 합니다. 주로 영역 클러스터를 사용하는 경우에는 대신 compute/zone을 설정합니다. 기본 위치를 설정하면 gcloud CLI에서 One of [--zone, --region] must be supplied: Please specify location과 같은 오류를 방지할 수 있습니다. 클러스터의 위치가 설정한 기본값과 다른 경우 특정 명령어에서 위치를 지정해야 할 수 있습니다.

버전 1.30.3-gke.1451000 이상을 실행하는 기존 GKE 클러스터가 있는지 확인합니다. 자세한 내용은 Autopilot 클러스터 만들기를 참고하세요.
Standard 모드 클러스터를 사용하는 경우 다음 요구사항 중 하나를 충족하는지 확인합니다.
- 클러스터에 있는 하나 이상의 노드 풀에서 자동 확장을 사용 설정합니다.
- Standard 클러스터가 1.33.3-gke.1136000 이전 버전을 실행하고 빠른 출시 채널에 등록되어 있지 않으면 클러스터 수준 노드 자동 프로비저닝을 사용 설정합니다.

ComputeClasses 시나리오 예시

이 문서에서는 커스텀 ComputeClass를 정의하는 예시 시나리오를 보여줍니다. 실제로 특정 워크로드와 조직의 요구사항을 고려하고 이러한 요구사항을 충족하는 ComputeClass를 정의해야 합니다. ComputeClass의 모든 옵션에 관한 자세한 설명과 특별한 고려사항은 커스텀 ComputeClass 정보를 참고하세요.

이러한 시나리오의 예시는 다음과 같습니다.

워크로드의 실행 비용을 최적화하는 것이 목표입니다.
워크로드가 내결함성을 갖추고 있고 정상적으로 종료하거나 런타임을 연장할 필요가 없습니다.
워크로드를 최적으로 실행하는데 64개 이상의 vCPU가 필요합니다.
N4 Compute Engine 머신 시리즈로 제한됩니다.

예시 시나리오에 따라 다음과 같은 작업을 실행하는 ComputeClass를 사용하기로 결정합니다.

vCPU가 최소 64개 이상인 N4 스팟 노드에 우선순위를 지정
컴퓨팅 용량과 관계없이 GKE가 N4 스팟 노드로 대체하도록 허용
사용 가능한 N4 스팟 노드가 없는 경우 GKE가 주문형 N4 노드를 사용하도록 허용
스팟 노드를 다시 사용할 수 있을 때마다 워크로드를 스팟 노드로 이동하도록 GKE에 지시

Autopilot 모드에서 ComputeClass 구성

GKE Autopilot에서는 ComputeClass를 정의하고, 클러스터에 배포하고, 워크로드에서 ComputeClass를 요청합니다. GKE는 라벨 및 taint 적용과 같은 노드 구성 단계를 자동으로 실행합니다.

다음 매니페스트를 compute-class.yaml로 저장합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

Standard 모드에서 ComputeClass 구성

GKE Standard 모드 클러스터에서는 ComputeClass 포드가 예상대로 예약되도록 수동 구성을 실행해야 할 수 있습니다. 수동 구성은 다음과 같이 노드 풀이 자동으로 생성되는지 여부에 따라 달라집니다.

자동으로 생성된 노드 풀: 수동 구성이 필요하지 않습니다. GKE는 ComputeClass 구성 단계를 자동으로 실행합니다. 자세한 내용은 노드 풀 자동 생성 및 ComputeClasses를 참고하세요.
수동으로 생성된 노드 풀: 수동 구성이 필요합니다. 노드를 특정 ComputeClass와 연결하려면 수동으로 만든 노드 풀에 노드 라벨과 노드 taint를 추가해야 합니다. 자세한 내용은 ComputeClass 사용을 위해 수동으로 만든 노드 풀 구성을 참고하세요.

GKE가 ComputeClass의 노드 풀을 자동으로 만들도록 하려면 다음 단계를 따르세요.

1.33.3-gke.1136000 이전 버전을 실행하고 신속 출시 채널에 등록되지 않은 Standard 모드 클러스터의 경우 클러스터 수준 노드 자동 프로비저닝을 사용 설정합니다.

다음 예시 매니페스트를 compute-class.yaml로 저장합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

이 예시 ComputeClass를 요청하는 포드를 배포하고 새 노드를 만들어야 하는 경우 GKE는 priorities 필드의 항목 순서대로 노드 만들기를 우선시합니다. 필요한 경우 GKE는 ComputeClass의 하드웨어 요구사항을 충족하는 새 노드 풀을 만듭니다.

우선순위에서 정확한 커스텀 머신 유형을 지정할 수도 있습니다. 커스텀 머신 유형을 사용하려면 GKE 버전 1.33.2-gke.1111000 이상이 필요합니다. 다음 예에서는 n4-custom-8-20480 맞춤 머신 유형에 스팟 VM의 우선순위를 지정하고 스팟 용량을 사용할 수 없는 경우 동일한 유형의 주문형 VM으로 대체되는 ComputeClass를 구성합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-machine-type
spec:
  priorities:
  - machineType: n4-custom-8-20480
    spot: true
  - machineType: n4-custom-8-20480
    spot: false
  nodePoolAutoCreation:
    enabled: true

수동으로 생성된 노드 풀에서 ComputeClass 사용

이 섹션에서는 수동으로 만든 노드 풀만 사용하는 클러스터에서 ComputeClass를 정의하는 방법을 보여줍니다.

다음 매니페스트를 compute-class.yaml로 저장합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true

스팟 VM을 사용하는 새 자동 확장 노드 풀을 만들고 ComputeClass와 연결합니다.

gcloud container node-pools create cost-optimized-pool \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --machine-type=n4-standard-64 \
    --spot \
    --enable-autoscaling \
    --max-nodes=9 \
    --node-labels="cloud.google.com/compute-class=cost-optimized" \
    --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"

다음을 바꿉니다.

LOCATION: 클러스터의 위치입니다.
CLUSTER_NAME: 기존 클러스터의 이름입니다.

주문형 VM을 사용하여 새 자동 확장 노드 풀을 만들고 ComputeClass와 연결합니다.

gcloud container node-pools create on-demand-pool \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --machine-type=n4-standard-64 \
    --enable-autoscaling \
    --max-nodes=9 \
    --num-nodes=0 \
    --node-labels="cloud.google.com/compute-class=cost-optimized" \
    --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"

이 ComputeClass를 요청하는 포드를 배포할 때 새 노드를 만들어야 하는 경우 GKE는 cost-optimized-pool 노드 풀에서 노드를 만드는 것을 우선시합니다. 새 노드를 만들 수 없는 경우 GKE는 on-demand-pool 노드 풀에 노드를 만듭니다.

수동으로 만든 노드 풀이 커스텀 ComputeClass와 상호작용하는 방식에 관한 자세한 내용은 ComputeClass 사용을 위해 수동으로 만든 노드 풀 구성을 참고하세요.

노드 통합을 위한 자동 확장 임곗값 맞춤설정

기본적으로 GKE는 사용률이 낮은 노드를 삭제하고 사용 가능한 다른 노드에 워크로드를 다시 예약합니다. 다음 예와 같이 ComputeClass 정의에서 autoscalingPolicy 필드를 사용하여 노드가 삭제 후보가 되는 기준점과 시기를 추가로 맞춤설정할 수 있습니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  autoscalingPolicy:
    consolidationDelayMinutes : 5
    consolidationThreshold    : 70

이 예시에서는 노드가 사용 가능한 CPU 및 메모리 용량의 70% 미만으로 5분 넘게 사용되지 않으면 노드가 삭제 후보가 됩니다. 사용 가능한 매개변수 목록은 노드 통합을 위한 자동 확장 매개변수 설정을 참고하세요.

클러스터에 ComputeClass 배포

ComputeClass를 정의한 후 클러스터에 배포합니다.

kubectl apply -f compute-class.yaml

이 ComputeClass는 클러스터에서 사용할 수 있습니다. 포드 사양에서 ComputeClass를 요청하거나, 원하는 경우 특정 네임스페이스에서 기본 ComputeClass로 설정할 수 있습니다.

워크로드에서 ComputeClass 요청

워크로드에서 ComputeClass를 요청하려면 다음 단계와 같이 매니페스트에 해당 ComputeClass의 노드 선택기를 추가합니다.

다음 매니페스트를 cc-workload.yaml로 저장합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: gcr.io/google_containers/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

워크로드를 배포합니다.
```
kubectl apply -f cc-workload.yaml
```

이 워크로드를 배포하면 GKE는 요청된 ComputeClass의 노드 taint에 해당하는 톨러레이션(toleration)을 포드에 자동으로 추가합니다. 이 톨러레이션(toleration)을 사용하면 ComputeClass를 요청하는 포드만 ComputeClass 노드에서 실행됩니다.

배포된 ComputeClass 업데이트

배포된 ComputeClass를 업데이트하려면 ComputeClass의 YAML 매니페스트를 수정합니다. 그런 다음 아래의 명령어를 실행하여 수정된 매니페스트를 배포합니다.

kubectl apply -f PATH_TO_FILE

PATH_TO_FILE을 수정된 매니페스트의 경로로 바꿉니다. name 필드의 값이 변경되지 않았는지 확인합니다.

업데이트된 ComputeClass를 배포하면 GKE는 업데이트된 구성을 사용하여 새 노드를 만듭니다. GKE는 업데이트된 구성으로 기존 노드를 수정하지 않습니다.

시간이 지남에 따라 ComputeClass가 활성 마이그레이션을 사용하고 기존 포드가 마이그레이션할 수 있는 경우 GKE는 업데이트된 구성을 사용하는 노드로 기존 포드를 이동할 수 있습니다.