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

GKE Standard에 TPU 워크로드 배포

표준

이 페이지에서는 Google Kubernetes Engine(GKE)에서 TPU를 사용하여 머신러닝(ML) 워크로드를 가속화하는 방법을 학습하기 위한 기반을 제공합니다. TPU는 대규모 딥 러닝 모델 학습과 같은 행렬 곱셈 처리를 위해 설계되었습니다. TPU는 ML의 방대한 데이터 세트와 복잡한 모델을 처리하는 데 최적화되어 있으므로 성능이 우수하여 ML 워크로드에 더 비용 효율적이고 에너지 효율적입니다. 이 가이드에서는 Cloud TPU 가속기를 사용하여 ML 워크로드를 배포하고, TPU 할당량을 구성하고, TPU를 실행하는 노드 풀의 업그레이드를 구성하고, TPU 워크로드 측정항목을 모니터링하는 방법을 알아봅니다.

이 튜토리얼은 TPU를 사용하여 대규모 모델 학습, 튜닝 및 추론 워크로드를 관리하기 위해 Kubernetes 컨테이너 조정을 사용하는 데 관심이 있는 머신러닝(ML) 엔지니어와 플랫폼 관리자 및 운영자를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.

이 페이지를 읽기 전 다음 내용을 숙지해야 합니다.

시작하기 전에

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

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과 같은 오류를 방지할 수 있습니다. 클러스터의 위치가 설정한 기본값과 다른 경우 특정 명령어에서 위치를 지정해야 할 수 있습니다.

TPU 구성 계획

모델과 필요한 메모리 양에 따라 TPU 구성을 계획합니다. 이 가이드를 사용하여 TPU에 워크로드를 배포하기 전에 TPU 구성 계획의 계획 단계를 완료하세요.

TPU 할당량이 있는지 확인

다음 섹션에서는 GKE에서 TPU를 사용할 때 할당량이 충분한지 확인하는 방법을 설명합니다.

주문형 또는 스팟 VM 할당량

주문형 또는 스팟 VM으로 TPU 슬라이스 노드 풀을 만드는 경우 사용하려는 리전에서 사용 가능한 TPU 할당량이 충분해야 합니다.

TPU 예약을 소비하는 TPU 슬라이스 노드 풀을 만드는 경우에는 TPU 할당량이 필요하지 않습니다.¹ 예약된 TPU의 경우 이 섹션을 건너뛰어도 무방합니다.

GKE에서 주문형 또는 스팟 TPU 슬라이스 노드 풀을 만들려면 Compute Engine API 할당량이 필요합니다. Compute Engine API 할당량(compute.googleapis.com)은 Cloud TPU API로 TPU를 만들 때 필요한 Cloud TPU API 할당량(tpu.googleapis.com)과 다릅니다.

TPU용 Compute Engine API 할당량의 한도 및 현재 사용량을 확인하려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 할당량 페이지로 이동합니다.

할당량으로 이동

필터 상자에서 다음을 수행합니다,

다음 표를 사용하여 TPU 버전 및 머신 유형에 따라 할당량의 속성을 선택하고 복사합니다. 예를 들어 머신 유형이 ct5lp-로 시작하는 주문형 TPU v5e 노드를 만들려면 Name: TPU v5 Lite PodSlice chips를 입력합니다.

TPU 버전, 머신 유형이 다음으로 시작함	온디맨드 인스턴스의 할당량 속성 및 이름	스팟² 인스턴스의 할당량 속성 및 이름
TPU v3, `ct3-`	Dimensions (e.g. location): tpu_family:CT3	해당 사항 없음
TPU v3, `ct3p-`	Dimensions (e.g. location): tpu_family:CT3P	해당 사항 없음
TPU v4, `ct4p-`	Name: TPU v4 PodSlice chips	Name: Preemptible TPU v4 PodSlice chips
TPU v5e, `ct5lp-`	Name: TPU v5 Lite PodSlice chips	Name: Preemptible TPU v5 Lite Podslice chips
TPU v5p, `ct5p-`	Name: TPU v5p chips	Name: Preemptible TPU v5p chips
TPU Trillium, `ct6e-`	Dimensions (e.g. location): tpu_family:CT6E	Name: Preemptible TPU slices v6e

측정기준(예: 위치) 속성을 선택하고 region:을 입력한 다음 GKE에서 TPU를 생성할 리전의 이름을 입력합니다. 예를 들어 us-west4-a 영역에 TPU 슬라이스 노드를 만들려면 region:us-west4를 입력합니다. TPU 할당량은 리전 기준이므로 동일한 리전 내의 모든 영역에서 동일한 TPU 할당량을 사용합니다.

입력한 필터와 일치하는 할당량이 없으면 필요한 리전에 대해 지정된 할당량이 프로젝트에 부여되지 않았으므로 TPU 할당량 조정을 요청해야 합니다.

TPU 예약이 생성되면 해당 할당량의 한도 및 현재 사용량 값이 TPU 예약의 칩 수만큼 증가합니다. 예를 들어 머신 유형이 ct5lp-로 시작되는 16개의 TPU v5e 칩에 대한 예약이 생성되면 관련 리전에서 TPU v5 Lite PodSlice chips 할당량의 한도 및 현재 사용량이 모두 16개씩 증가합니다.

TPU 슬라이스 노드 풀을 만들 때는 --reservation 및 --reservation-affinity=specific 플래그를 사용하여 예약 인스턴스를 만듭니다. TPU 예약은 약정을 구매할 때 사용할 수 있습니다. ↩
TPU 슬라이스 노드 풀을 만들 때는 --spot 플래그를 사용하여 스팟 인스턴스를 만듭니다. ↩

추가 GKE 리소스의 할당량

GKE에서 리소스를 만드는 리전에서 다음 GKE 관련 할당량을 늘려야 할 수 있습니다.

영구 디스크 SSD(GB) 할당량: 각 Kubernetes 노드의 부팅 디스크에는 기본적으로 100GB가 필요합니다. 따라서 이 할당량은 생성될 것으로 예상되는 최대 GKE 노드 수와 100GB(노드 * 100GB)의 곱 이상으로 설정해야 합니다.
사용 중인 IP 주소 할당량: 각 Kubernetes 노드는 하나의 IP 주소를 사용합니다 따라서 이 할당량은 생성될 것으로 예상되는 최대 GKE 노드 수 이상으로 설정해야 합니다.
max-pods-per-node가 서브넷 범위와 일치하는지 확인: 각 Kubernetes 노드는 포드에 보조 IP 범위를 사용합니다. 예를 들어 max-pods-per-node가 32이면 64개의 IP 주소가 필요하며 이는 노드당 /26 서브넷으로 변환됩니다. 이 범위는 다른 클러스터와 공유해서는 안 됩니다. IP 주소 범위가 소진되지 않도록 하려면 --max-pods-per-node 플래그를 사용하여 노드에 예약할 수 있는 포드 수를 제한합니다. max-pods-per-node의 할당량은 생성될 것으로 예상되는 최대 GKE 노드 수 이상으로 설정해야 합니다.

할당량 상향을 요청하려면 할당량 조정 요청을 참고하세요.

예약 가용성 확인

예약을 사용하여 TPU 슬라이스 노드 풀을 만들려면 노드 풀 생성 시 예약에 사용 가능한 TPU 칩이 충분해야 합니다.

프로젝트 내에 존재하는 예약과 TPU 예약 내에서 사용 가능한 TPU 칩 수를 확인하려면 예약 목록을 확인합니다.

GKE에서 TPU를 프로비저닝하는 옵션

GKE를 사용하면 워크로드 매니페스트에서 Kubernetes nodeSelector를 사용하거나 TPU가 포함된 Standard 모드 노드 풀을 만들어 개별 워크로드에서 TPU를 직접 사용할 수 있습니다.

또는 커스텀 컴퓨팅 클래스를 사용하여 TPU를 요청할 수 있습니다. 커스텀 컴퓨팅 클래스를 사용하면 플랫폼 관리자가 노드 확장 결정 중에 GKE가 우선시할 노드 구성의 계층 구조를 정의하여 워크로드가 선택한 하드웨어에서 실행되도록 할 수 있습니다.

자세한 내용은 커스텀 컴퓨팅 클래스를 사용하여 TPU 프로비저닝 섹션을 참조하세요.

클러스터 만들기

사용 가능한 TPU가 있는 리전에서 표준 모드로 GKE 클러스터를 만듭니다.

권장사항:

Kubernetes 컨트롤 플레인의 고가용성을 제공하는 리전 클러스터를 사용합니다.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

다음을 바꿉니다.

CLUSTER_NAME: 새 클러스터의 이름입니다.
LOCATION: TPU 용량을 사용할 수 있는 리전입니다.
VERSION: 사용하려는 머신 유형을 지원해야 하는 GKE 버전입니다. 기본 GKE 버전은 대상 TPU에 대한 가용성이 없을 수 있습니다. TPU 머신 유형에 사용 가능한 최소 GKE 버전을 알아보려면 GKE의 TPU 가용성을 참조하세요.

노드 풀 만들기

단일 또는 멀티 호스트 TPU 슬라이스 노드 풀을 만들 수 있습니다.

단일 호스트 TPU 슬라이스 노드 풀을 만듭니다.

Google Cloud CLI, Terraform 또는 Google Cloud 콘솔을 사용하여 단일 호스트 TPU 슬라이스 노드 풀을 만들 수 있습니다.

gcloud

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--sandbox=type=gvisor]

다음을 바꿉니다.

NODE_POOL_NAME: 새 노드 풀의 이름.
LOCATION: 사용할 TPU 버전에 따른 영역의 이름. 사용 가능한 위치를 확인하려면 GKE의 TPU 가용성을 참조하세요.
CLUSTER_NAME: 클러스터의 이름입니다.
NODE_ZONES: GKE가 노드 풀을 만드는 하나 이상의 영역을 쉼표로 구분한 목록
MACHINE_TYPE: 노드에 사용할 머신 유형. TPU 호환 머신 유형에 관한 자세한 내용은 TPU 버전 선택의 표를 참고하세요.

선택적으로 다음 플래그를 사용할 수도 있습니다.

--num-nodes=NUM_NODES: 각 영역의 노드 풀에 있는 초기 노드 수. 이 플래그를 생략하면 GKE가 기본값인 3을 할당합니다.

권장사항:
노드 풀에 enable-autoscaling 플래그를 사용하는 경우 워크로드가 요구하는 즉시 자동 확장 처리가 추가 노드를 즉시 프로비저닝할 수 있도록 num-nodes를 0으로 설정하세요.
--reservation=RESERVATION_NAME: 노드 풀을 만들 때 GKE가 사용하는 예약의 이름. 이 플래그를 생략하면 GKE가 사용 가능한 TPU를 사용합니다. TPU 예약에 대해 자세히 알아보려면 Cloud TPU 예약 정보를 참고하세요.
--node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: 단일 호스트 TPU 슬라이스 노드 풀이 컬렉션의 일부임을 GKE에 알립니다. 다음 조건이 적용되는 경우 이 플래그를 사용하세요.
- 노드 풀은 새 노드 풀에서 추론 워크로드를 실행합니다.
- 노드 풀에서 TPU Trillium을 사용합니다.
- 노드 풀에서 스팟 VM을 사용하지 않습니다.
컬렉션 예약 관리에 대해 자세히 알아보려면 단일 호스트 TPU 슬라이스에서 컬렉션 예약 관리를 참조하세요.
--enable-autoscaling: 자동 확장이 사용 설정된 노드 풀을 만듭니다. 다음 추가 플래그가 필요합니다.
- --total-min-nodes=TOTAL_MIN_NODES: 노드 풀에 있는 모든 노드의 최소 수입니다.
- --total-max-nodes=TOTAL_MAX_NODES: 노드 풀에 있는 모든 노드의 최대 수입니다.
- --location-policy=ANY: 사용되지 않은 예약을 우선 사용하고 스팟 VM의 선점 위험을 줄입니다.
--spot: 노드 풀의 노드에 스팟 VM을 사용하도록 노드 풀을 설정합니다. 노드 풀을 만든 후에는 변경할 수 없습니다.
--flex-start: Flex-start VM을 사용하도록 노드 풀을 설정합니다. Flex-start VM은 GKE 버전 1.33.0-gke.1712000 이상에서 지원되는 flex-start 소비 옵션을 사용하여 생성됩니다.
--sandbox=type=gvisor: GKE Sandbox가 사용 설정된 노드를 프로비저닝합니다. TPU v4 이상 버전이 필요합니다. 자세한 내용은 GKE Sandbox를 참조하세요.

지정할 수 있는 모든 플래그의 전체 목록은 gcloud container clusters create 참조를 확인하세요.

Terraform

google 제공업체 버전 4.84.0 이상을 사용해야 합니다.
Terraform 구성에 다음 블록을 추가합니다.

resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }
}

다음을 바꿉니다.

NODE_POOL_RESOURCE_NAME: Terraform 템플릿의 노드 풀 리소스 이름
PROJECT_ID: 프로젝트 ID입니다.
CLUSTER_NAME: 기존 클러스터의 이름
POOL_NAME: 만들 노드 풀의 이름
CLUSTER_LOCATION: 클러스터의 컴퓨팅 영역. TPU 버전을 사용할 수 있는 리전을 지정합니다. 자세한 내용은 TPU 버전 및 토폴로지 선택을 참조하세요.
NODE_ZONES: GKE가 노드 풀을 만드는 하나 이상의 영역을 쉼표로 구분한 목록
MACHINE_TYPE: 사용할 TPU 머신 유형. TPU 호환 머신 유형을 확인하려면 TPU 버전 선택의 표를 참조하세요.

선택적으로 다음 변수를 사용할 수도 있습니다.

autoscaling: 자동 확장이 사용 설정된 노드 풀을 만듭니다. 단일 호스트 TPU 슬라이스의 경우 GKE는 TOTAL_MIN_NODES와 TOTAL_MAX_NODES 값 사이에서 확장됩니다.
- TOTAL_MIN_NODES: 노드 풀에 있는 모든 노드의 최소 수. 자동 확장도 지정하지 않는 한 이 필드는 선택사항입니다.
- TOTAL_MAX_NODES: 노드 풀에 있는 모든 노드의 최대 수. 자동 확장도 지정하지 않는 한 이 필드는 선택사항입니다.
RESERVATION_NAME: Cloud TPU 예약 정보를 사용하는 경우 노드 풀을 만들 때 사용할 예약 리소스의 라벨 목록입니다. reservation_affinity 필드에 RESERVATION_LABEL_VALUES를 채우는 방법에 대한 자세한 내용은 Terraform 제공업체를 참조하세요.
spot: TPU 노드에 스팟 VM을 사용하도록 노드 풀을 설정합니다. 노드 풀을 만든 후에는 변경할 수 없습니다. 자세한 내용은 스팟 VM을 참조하세요.
flex_start: flex-start 소비 옵션을 사용하도록 노드 풀을 설정합니다. spot이 사용 설정된 경우 true로 설정할 수 없습니다. Flex-start(유연한 시작)는 GKE 버전 1.33.0-gke.1712000 이상에서 지원됩니다.

콘솔

TPU가 포함된 노드 풀을 만들려면 다음 안내를 따르세요.

Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

Google Kubernetes Engine으로 이동
클러스터 목록에서 수정하려는 클러스터 이름을 클릭합니다.
노드 풀 추가를 클릭합니다.
노드 풀 세부정보 섹션에서 노드 위치 지정 체크박스를 선택합니다.
사용할 TPU 버전에 따라 영역을 선택합니다. 사용 가능한 영역을 확인하려면 GKE의 TPU 가용성을 참조하세요.
탐색창에서 노드를 클릭합니다.
머신 구성 섹션에서 TPU를 선택합니다.
시리즈 드롭다운 메뉴에서 다음 중 하나를 선택합니다.
- CT3: TPU v3, 단일 호스트 기기
- CT3P: TPU v3, 멀티 호스트 포드 슬라이스
- CT4P: TPU v4
- CT5LP: TPU v5e
- CT5P: TPU v5p
- CT6E: TPU Trillium(v6e)
머신 유형 드롭다운 메뉴에서 노드에 사용할 머신 이름을 선택합니다. TPU 버전 선택 표를 사용하여 단일 호스트 TPU 슬라이스 노드 풀을 만드는 머신 유형 및 TPU 토폴로지를 정의하는 방법을 알아봅니다.
TPU 토폴로지 드롭다운 메뉴에서 TPU 슬라이스의 물리적 토폴로지를 선택합니다.
필요한 변경사항 대화상자에서 변경을 클릭합니다.
부팅 디스크 유형이 표준 영구 디스크 또는 SSD 영구 디스크인지 확인합니다.
선택적으로 노드 풀의 노드에 스팟 VM을 사용하려면 스팟 VM에서 노드 사용 설정 체크박스를 선택합니다.
만들기를 클릭합니다.

멀티 호스트 TPU 슬라이스 노드 풀 만들기

Google Cloud CLI, Terraform 또는 Google Cloud 콘솔을 사용하여 멀티 호스트 TPU 슬라이스 노드 풀을 만들 수 있습니다.

gcloud

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    [--num-nodes=NUM_NODES] \
    [--spot \]
    [--flex-start \]
    [--enable-autoscaling \
      --max-nodes MAX_NODES]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME] \
    [--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
    [--placement-type=COMPACT]

다음을 바꿉니다.

POOL_NAME: 새 노드 풀의 이름.
LOCATION: 사용할 TPU 버전에 따른 영역의 이름. 사용 가능한 위치를 확인하려면 GKE의 TPU 가용성을 참조하세요.
CLUSTER_NAME: 클러스터의 이름입니다.
NODE_ZONES: GKE가 노드 풀을 만드는 하나 이상의 영역을 쉼표로 구분한 목록
MACHINE_TYPE: 노드에 사용할 머신 유형. 사용 가능한 머신 유형에 대해 자세히 알아보려면 TPU 버전 선택을 참조하세요.
TPU_TOPOLOGY: TPU 슬라이스의 물리적 토폴로지입니다. 토폴로지 형식은 TPU 버전에 따라 달라집니다. TPU 토폴로지에 대한 자세한 내용은 토폴로지 선택의 표를 참고하세요.

자세한 내용은 토폴로지를 참조하세요.

선택적으로 다음 플래그를 사용할 수도 있습니다.

NUM_NODES: 노드 풀의 노드 수입니다. 0이거나, TPU_TOPOLOGY에 정의된 값의 곱({A}x{B}x{C})을 각 VM의 칩 수로 나눈 값이어야 합니다. 멀티 호스트 TPU v4 및 TPU v5e의 경우 각 VM의 칩 수는 4개입니다. 따라서 TPU_TOPOLOGY가 2x4x4(각 VM에 4개의 칩이 포함된 TPU v4)인 경우 NUM_NODES는 8과 동일한 32/4입니다. 이 플래그를 생략하면 토폴로지와 머신 유형에 따라 노드 수가 계산되고 기본값이 지정됩니다.
RESERVATION_NAME: 노드 풀을 만들 때 GKE가 사용하는 예약의 이름. 이 플래그를 생략하면 GKE에서 사용 가능한 TPU 슬라이스 노드 풀을 사용합니다. TPU 예약에 대한 자세한 내용은 TPU 예약을 참조하세요.
--spot: TPU 슬라이스 노드에 스팟 VM을 사용하도록 노드 풀을 설정합니다. 노드 풀을 만든 후에는 변경할 수 없습니다. 자세한 내용은 스팟 VM을 참조하세요.
--flex-start: Flex-start VM을 사용하도록 노드 풀을 설정합니다. Flex-start VM은 GKE 버전 1.33.0-gke.1712000 이상에서 지원되는 flex-start 소비 옵션을 사용하여 생성됩니다.
--enable-autoscaling: 자동 확장이 사용 설정된 노드 풀을 만듭니다. GKE는 멀티 호스트 TPU 슬라이스 노드 풀을 확장할 때 노드 풀을 0에서 최대 크기로 원자적으로 수직 확장합니다.
- MAX_NODES: 노드 풀의 최대 크기입니다. --enable-autoscaling이 제공되는 경우 --max-nodes 플래그가 필요하며 TPU_TOPOLOGY({A}x{B}x{C})에 정의된 값의 곱을 각 VM의 칩 수로 나눈 값과 같아야 합니다.
--node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: 멀티 호스트 TPU 슬라이스 노드 풀이 컬렉션임을 GKE에 알립니다. 다음 조건이 적용되는 경우 이 플래그를 사용하세요.
- 노드 풀은 새 노드 풀에서 추론 워크로드를 실행합니다.
- 노드 풀에서 TPU Trillium을 사용합니다.
- 스팟 VM은 컬렉션 예약을 지원하지 않습니다.
컬렉션 예약 관리에 대해 자세히 알아보려면 멀티 호스트 TPU 슬라이스에서 컬렉션 예약 관리를 참조하세요.
--placement-type=COMPACT: 압축 배치가 사용 설정된 노드 풀을 만듭니다. 이 옵션은 --tpu-topology 플래그와 함께 사용해야 합니다. 자세한 내용은 압축 배치 정책 만들기 및 TPU 토폴로지를 참조하세요.

Terraform

google 제공업체 버전 4.84.0 이상을 사용해야 합니다.
Terraform 구성에 다음 블록을 추가합니다.
```
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = TPU_TOPOLOGY
  }
}
```
다음을 바꿉니다.
- NODE_POOL_RESOURCE_NAME: Terraform 템플릿의 노드 풀 리소스 이름
- PROJECT_ID: 프로젝트 ID입니다.
- CLUSTER_NAME: 노드 풀을 추가할 기존 클러스터의 이름
- POOL_NAME: 만들 노드 풀의 이름
- CLUSTER_LOCATION: 클러스터의 컴퓨팅 위치. Kubernetes 컨트롤 플레인의 신뢰성 향상을 위해 리전 클러스터를 사용하는 것이 좋습니다. 영역 클러스터를 사용할 수도 있습니다. 자세한 내용은 TPU 버전 및 토폴로지 선택을 참조하세요.
- NODE_ZONES: GKE가 노드 풀을 만드는 하나 이상의 영역을 쉼표로 구분한 목록입니다.
- NUM_NODES: 노드 풀의 노드 수. 0이거나 TPU 칩 수의 곱을 4(멀티 호스트 TPU 슬라이스의 TPU 슬라이스 노드마다 칩이 4개 있기 때문)로 나눈 값이어야 합니다. 예를 들어 TPU_TOPOLOGY가 4x8이면 칩이 32개 있으므로 NUM_NODES는 8이어야 합니다. TPU 토폴로지에 대한 자세한 내용은 TPU 버전 선택의 표를 참조하세요.
- TPU_TOPOLOGY: TPU 슬라이스에 대해 원하는 물리적 토폴로지를 나타냅니다. 토폴로지 형식은 사용 중인 TPU 버전에 따라 달라집니다. TPU 토폴로지에 대한 자세한 내용은 토폴로지 선택의 표를 참조하세요.
선택적으로 다음 변수를 사용할 수도 있습니다.
- RESERVATION_NAME: TPU 예약을 사용하는 경우 노드 풀을 만들 때 사용할 예약 리소스의 라벨 목록. reservation_affinity 필드에 RESERVATION_LABEL_VALUES를 채우는 방법에 대한 자세한 내용은 Terraform 제공업체를 참조하세요.
- autoscaling: 자동 확장이 사용 설정된 노드 풀을 만듭니다. GKE는 멀티 호스트 TPU 슬라이스 노드 풀을 확장할 때 노드 풀을 0에서 최대 크기로 원자적으로 수직 확장합니다.
  - MAX_NODES: 노드 풀의 최대 크기. TPU_TOPOLOGY에 정의된 값의 곱({A}x{B}x{C})을 각 VM의 칩 수로 나눈 값이어야 합니다.
- spot: 노드 풀에서 TPU 슬라이스 노드에 스팟 VM을 사용할 수 있게 합니다. 노드 풀을 만든 후에는 변경할 수 없습니다. 자세한 내용은 스팟 VM을 참조하세요.
- flex_start: flex-start 소비 옵션을 사용하도록 노드 풀을 설정합니다. spot이 사용 설정된 경우 true로 설정할 수 없습니다.

콘솔

TPU가 포함된 노드 풀을 만들려면 다음 안내를 따르세요.

Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

Google Kubernetes Engine으로 이동
클러스터 목록에서 수정하려는 클러스터 이름을 클릭합니다.
노드 풀 추가를 클릭합니다.
노드 풀 세부정보 섹션에서 노드 위치 지정 체크박스를 선택합니다.
사용할 TPU 버전에 따른 영역의 이름. 사용 가능한 위치를 확인하려면 GKE의 TPU 가용성을 참조하세요.
탐색창에서 노드를 클릭합니다.
머신 구성 섹션에서 TPU를 선택합니다.
시리즈 드롭다운 메뉴에서 다음 중 하나를 선택합니다.
- CT3P: TPU v3의 경우에 선택합니다.
- CT4P: TPU v4의 경우에 선택합니다.
- CT5LP: TPU v5e의 경우에 선택합니다.
머신 유형 드롭다운 메뉴에서 노드에 사용할 머신 이름을 선택합니다. TPU 버전 선택 표를 사용하여 멀티 호스트 TPU 슬라이스 노드 풀을 만드는 머신 유형 및 TPU 토폴로지를 정의하는 방법을 알아봅니다.
TPU 토폴로지 드롭다운 메뉴에서 TPU 슬라이스의 물리적 토폴로지를 선택합니다.
필요한 변경사항 대화상자에서 변경을 클릭합니다.
부팅 디스크 유형이 표준 영구 디스크 또는 SSD 영구 디스크인지 확인합니다.
선택적으로 노드 풀의 노드에 스팟 VM을 사용하려면 스팟 VM에서 노드 사용 설정 체크박스를 선택합니다.
만들기를 클릭합니다.

GKE에서 용량 문제를 처리하는 방법

GKE가 사용 가능한 TPU 용량 부족으로 인해 TPU 슬라이스 노드 풀을 만들 수 없으면 GKE에서 용량 부족으로 인해 TPU 슬라이스 노드를 만들 수 없다는 오류 메시지가 반환됩니다.

단일 호스트 TPU 슬라이스 노드 풀을 만드는 경우 다음과 비슷한 오류 메시지가 표시됩니다.

2 nodes cannot be created due to lack of capacity. The missing nodes will be
created asynchronously once capacity is available. You can either wait for the
nodes to be up, or delete the node pool and try re-creating it again later.

멀티 호스트 TPU 슬라이스 노드 풀을 만드는 경우 다음과 비슷한 오류 메시지가 표시됩니다.

The nodes (managed by ...) cannot be created now due to lack of capacity. They
will be created asynchronously once capacity is available. You can either wait
for the nodes to be up, or delete the node pool and try re-creating it again
later.

TPU 프로비저닝 요청이 장시간 큐에 유지될 수 있고 큐에 있는 동안 '프로비저닝' 상태로 유지됩니다.

용량을 사용할 수 있으면 GKE가 생성되지 않은 남은 노드를 만듭니다.

곧 용량이 필요하면 스팟 VM을 시도할 수 있습니다. 하지만 스팟 VM은 주문형 인스턴스와 다른 할당량을 소비합니다.

TPU 슬라이스 노드 풀을 삭제하여 큐에 있는 TPU 요청을 삭제할 수 있습니다.

TPU 슬라이스 노드에서 워크로드 실행

이 섹션에서는 워크로드를 준비하는 방법과 워크로드를 실행하는 방법에 대한 예를 설명합니다.

워크로드 준비

TPU 워크로드 준비 요구사항은 다음과 같습니다.

JAX, PyTorch, TensorFlow와 같은 프레임워크는 libtpu 공유 라이브러리를 사용하여 TPU VM에 액세스합니다. libtpu에는 XLA 컴파일러, TPU 런타임 소프트웨어, TPU 드라이버가 포함됩니다. PyTorch 및 JAX의 각 출시 버전에는 특정 libtpu.so 버전이 필요합니다. 패키지 버전 충돌을 방지하려면 JAX AI 이미지를 사용하는 것이 좋습니다. GKE에서 TPU를 사용하려면 다음 버전을 사용해야 합니다.

TPU 유형	`libtpu.so` 버전
TPU Trillium(v6e) `tpu-v6e-slice`	권장 JAX AI 이미지: jax0.4.35-rev1 이상 권장 jax[tpu] 버전: v0.4.9 이상 권장 torchxla[tpuvm] version: v2.1.0 이상
TPU v5e `tpu-v5-lite-podslice`	권장 JAX AI 이미지: jax0.4.35-rev1 이상 권장 jax[tpu] 버전: v0.4.9 이상 권장 torchxla[tpuvm] version: v2.1.0 이상
TPU v5p `tpu-v5p-slice`	권장 JAX AI 이미지: jax0.4.35-rev1 이상 권장 jax[tpu] version: 0.4.19 이상 권장 torchxla[tpuvm] 버전: 2023년 10월 23일 나이틀리 버전 빌드를 사용하는 것이 좋습니다
TPU v4 `tpu-v4-podslice`	권장 JAX AI 이미지: jax0.4.35-rev1 이상 권장 jax[tpu]: v0.4.4 이상 권장 torchxla[tpuvm]: v2.0.0 이상
TPU v3 `tpu-v3-slice` `tpu-v3-device`	권장 JAX AI 이미지: jax0.4.35-rev1 이상 권장 jax[tpu]: v0.4.4 이상 권장 torchxla[tpuvm]: v2.0.0 이상

TPU 리소스를 요청하는 컨테이너에 다음 환경 변수를 설정합니다.
- TPU_WORKER_ID: 포드마다 고유한 정수입니다. 이 ID는 TPU 슬라이스의 고유한 worker-id를 나타냅니다. 이 필드에 지원되는 값 범위는 0부터 포드 수에서 1을 뺀 값까지입니다.
- TPU_WORKER_HOSTNAMES: 슬라이스 내에서 서로 통신해야 하는 TPU VM 호스트 이름이나 IP 주소의 쉼표로 구분된 목록입니다. 슬라이스의 TPU VM마다 호스트 이름이나 IP 주소가 있어야 합니다. IP 주소 또는 호스트 이름 목록은 TPU_WORKER_ID에 의해 정렬되고 색인이 0으로 지정됩니다.
- 워크로드 매니페스트에서 Kubernetes 노드 선택기를 추가하여 GKE가 정의된 TPU 머신 유형 및 TPU 토폴로지로 TPU 워크로드를 예약하도록 합니다.
```
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
  
```
  다음을 바꿉니다.
  - TPU_ACCELERATOR: TPU 가속기 이름입니다.
  - TPU_TOPOLOGY: TPU 슬라이스의 물리적 토폴로지입니다. 토폴로지 형식은 TPU 버전에 따라 달라집니다. 자세한 내용은 GKE에서 TPU 계획을 참조하세요.

워크로드 준비가 완료되면 TPU를 사용하는 작업을 실행할 수 있습니다.

다음 섹션에서는 TPU로 기본 계산을 수행하는 작업을 실행하는 방법에 대한 예시를 보여줍니다.

예시 1: TPU 슬라이스 노드 풀에서 사용 가능한 TPU 칩 수를 표시하는 워크로드 실행

다음 워크로드는 멀티 호스트 TPU 슬라이스의 모든 노드에서 TPU 칩 수를 반환합니다. 멀티 호스트 슬라이스를 만들기 위한 워크로드 매개변수는 다음과 같습니다.

TPU 버전: TPU v4
토폴로지: 2x2x4

이 버전과 토폴로지를 선택하면 멀티 호스트 슬라이스가 생성됩니다.

다음 매니페스트를 available-chips-multihost.yaml로 저장합니다.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-available-chips
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-available-chips
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice # Node selector to target TPU v4 slice nodes.
        cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice.
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips.
        resources:
          requests:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Request 4 TPU chips for this workload.
          limits:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Limit to 4 TPU chips for this workload.

매니페스트를 배포합니다.
```
kubectl create -f available-chips-multihost.yaml
```
GKE는 4개의 VM(멀티 호스트 TPU 슬라이스)으로 TPU v4 슬라이스를 실행합니다. 슬라이스에는 상호 연결된 TPU 칩 16개가 있습니다.

작업이 4개의 포드를 만들었는지 확인합니다.

kubectl get pods

출력은 다음과 비슷합니다.

NAME                       READY   STATUS      RESTARTS   AGE
tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s

포드 중 하나의 로그를 가져옵니다.
```
kubectl logs POD_NAME
```
POD_NAME을 생성된 포드 중 하나의 이름으로 바꿉니다. 예를 들면 tpu-job-podslice-0-5cd8r입니다.

출력은 다음과 비슷합니다.
```
TPU cores: 16
```

선택사항: 워크로드 삭제:

kubectl delete -f available-chips-multihost.yaml

예시 2: TPU 슬라이스 에서 사용 가능한 TPU 칩 수를 표시하는 워크로드 실행

다음 워크로드는 특정 노드에 연결된 TPU 칩 수를 표시하는 정적 포드입니다. 단일 호스트 노드를 만들기 위한 워크로드 매개변수는 다음과 같습니다.

TPU 버전: TPU v5e
토폴로지: 2x4

이 버전과 토폴로지를 선택하면 단일 호스트 슬라이스가 생성됩니다.

다음 매니페스트를 available-chips-singlehost.yaml로 저장합니다.

apiVersion: v1
kind: Pod
metadata:
  name: tpu-job-jax-v5
spec:
  restartPolicy: Never
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # Node selector to target TPU v5e slice nodes.
    cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice.
  containers:
  - name: tpu-job
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    ports:
    - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
    securityContext:
      privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
    command:
    - bash
    - -c
    - |
      python -c 'import jax; print("Total TPU chips:", jax.device_count())'
    resources:
      requests:
        google.com/tpu: 8 # Request 8 TPU chips for this container.
      limits:
        google.com/tpu: 8 # Limit to 8 TPU chips for this container.

매니페스트를 배포합니다.
```
kubectl create -f available-chips-singlehost.yaml
```
GKE는 TPU v5e를 사용하는 단일 호스트 TPU 슬라이스 8개로 노드를 프로비저닝합니다. 각 TPU 노드에는 8개의 TPU 칩이 있습니다(단일 호스트 TPU 슬라이스).
포드 로그를 가져옵니다.
```
kubectl logs tpu-job-jax-v5
```
출력은 다음과 비슷합니다.
```
Total TPU chips: 8
```

선택사항: 워크로드 삭제:

  kubectl delete -f available-chips-singlehost.yaml

가속기를 사용하여 노드 풀 업그레이드(GPU 및 TPU)

GKE는 노드 풀을 포함하여 Standard 클러스터를 자동으로 업그레이드합니다. 또한 노드 버전을 곧 새로운 버전으로 업그레이드하려는 경우 노드 풀을 수동으로 업그레이드할 수 있습니다. 클러스터의 업그레이드 방식을 제어하려면 출시 채널, 유지보수 기간 및 제외항목, 출시 시퀀싱을 사용합니다.

또한 일시 급증 업그레이드, 블루-그린 업그레이드 또는 단기 업그레이드와 같이 노드 풀에 대해 노드 업그레이드 전략을 구성할 수 있습니다. 이러한 전략을 구성하여 환경에서 속도와 중단 사이의 최적 균형을 이루는 방식으로 노드 풀이 업그레이드되도록 할 수 있습니다. 멀티 호스트 TPU 슬라이스 노드 풀의 경우 구성된 노드 업그레이드 전략을 사용하는 대신 GKE가 단일 단계로 전체 노드 풀을 원자적으로 다시 만듭니다. 자세한 내용은 GKE의 TPU 관련 용어에서 원자성 정의를 참고하세요.

노드 업그레이드 전략을 사용하려면 구성에 따라 GKE에서 일시적으로 추가 리소스를 프로비저닝해야 합니다. GPU 또는 TPU가 있는 노드를 더 만들려고 시도할 때 리소스 가용성 오류가 표시될 때와 같이 Google Cloud에서 노드 풀 리소스 용량이 제한적이면 리소스 제한 환경에서 업그레이드를 참조하세요.

삭제

이 가이드에 사용된 리소스에 대해 Google Cloud 계정에 비용이 발생하지 않도록 하려면 더 이상 예약된 워크로드가 없는 TPU 슬라이스 노드 풀을 삭제하는 것이 좋습니다. 실행 중인 워크로드를 정상적으로 종료해야 하는 경우 노드를 삭제하기 전에 kubectl drain을 사용하여 워크로드를 삭제합니다.

TPU 슬라이스 노드 풀을 삭제하려면 다음 안내를 따르세요.
```
gcloud container node-pools delete POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME
```
다음을 바꿉니다.
- POOL_NAME: 노드 풀의 이름
- CLUSTER_NAME: 클러스터의 이름
- LOCATION: 클러스터의 컴퓨팅 위치

추가 설정 구성

다음 섹션에서는 TPU 워크로드에 적용할 수 있는 추가 구성에 대해 설명합니다.

컬렉션 예약 관리

TPU Trillium에서는 컬렉션 예약을 사용하여 TPU 슬라이스 노드를 그룹화할 수 있습니다. 이러한 TPU 슬라이스 노드를 그룹화하면 워크로드 수요를 충족하도록 복제본 수를 더 쉽게 조정할 수 있습니다 . Google Cloud 는 소프트웨어 업데이트를 제어하여 컬렉션 내에서 항상 충분한 슬라이스를 사용하여 트래픽을 처리할 수 있도록 합니다.

TPU Trillium은 추론 워크로드를 실행하는 단일 호스트 및 멀티 호스트 노드 풀의 컬렉션 예약을 지원합니다. 다음은 컬렉션 예약 동작이 사용하는 TPU 슬라이스의 유형에 따라 어떻게 달라지는지 설명합니다.

멀티 호스트 TPU 슬라이스: GKE는 멀티 호스트 TPU 슬라이스를 그룹화하여 컬렉션을 형성합니다. 각 GKE 노드 풀은 이 컬렉션 내의 복제본입니다. 컬렉션을 정의하려면 멀티 호스트 TPU 슬라이스를 만들고 컬렉션에 고유한 이름을 할당합니다. 컬렉션에 TPU 슬라이스를 더 추가하려면 컬렉션 이름과 워크로드 유형이 동일한 멀티 호스트 TPU 슬라이스 노드 풀을 하나 더 만듭니다.
단일 호스트 TPU 슬라이스: GKE는 전체 단일 호스트 TPU 슬라이스 노드 풀을 컬렉션으로 간주합니다. 컬렉션에 TPU 슬라이스를 더 추가하려면 단일 호스트 TPU 슬라이스 노드 풀의 크기를 조정하면 됩니다.

컬렉션을 관리하려면 사용하는 노드 풀 유형에 따라 다음 작업 중 하나를 실행하세요.

멀티 호스트 TPU 슬라이스 노드 풀에서 컬렉션 예약 관리하기

다음 작업을 사용하여 멀티 호스트 TPU 슬라이스 노드 풀을 관리합니다.

멀티 호스트 TPU 슬라이스 풀이 컬렉션의 일부인지 확인하려면 다음 명령어를 실행합니다.

gcloud container node-pools describe NODE_POOL_NAME \
    --location LOCATION \
    --cluster CLUSTER_NAME \
    --format="json" | jq -r \
    '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'

출력은 다음과 비슷합니다.

nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code>
gke-workload-type: HIGH_AVAILABILITY

멀티 호스트 TPU 슬라이스 풀이 컬렉션의 일부인 경우 출력에는 다음 라벨이 있습니다.

cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>

클러스터의 컬렉션 목록을 가져오려면 다음 명령어를 실행합니다.

#!/bin/bash

# Replace with your cluster name, project, and location
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

declare -A collection_names

node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Describe the node pool and extract labels using jq
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Add the collection name to the associative array if it's not empty
    if [[ -n "$collection_name" ]]; then
        collection_names["$collection_name"]=1
    fi
done

# Print the unique node pool collection names
echo "Unique cloud.google.com/gke-nodepool-group-name values:"
for name in "${!collection_names[@]}"; do
    echo "$name"
done

출력은 다음과 비슷합니다.

Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}

컬렉션에 속한 노드 풀 목록을 가져오려면 다음 명령어를 실행합니다.

#!/bin/bash

TARGET_COLLECTION_NAME=COLLECTION_NAME
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

matching_node_pools=()

# Get the list of all node pools in the cluster
node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Get the value of the cloud.google.com/gke-nodepool-group-name label
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Check if the group name matches the target value
    if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then
        matching_node_pools+=("$pool")
    fi
done

# Print the list of matching node pools
echo "Node pools with collection name '$TARGET_COLLECTION_NAME':"
for pool in "${matching_node_pools[@]}"; do
    echo "$pool"
done

출력은 다음과 비슷합니다.

Node pools with collection name 'COLLECTION_NAME':
{NODE_POOL_NAME_1}
{NODE_POOL_NAME_2}
{NODE_POOL_NAME_3}

컬렉션을 수직 확장하려면 다른 멀티 호스트 TPU 슬라이스 노드 풀을 만들고 cloud.google.com/gke-workload-type 및 cloud.google.com/gke-nodepool-group-name을 추가합니다. cloud.google.com/gke-nodepool-group-name에서 동일한 컬렉션 이름을 사용하고 동일한 워크로드 유형을 실행합니다. 클러스터에서 노드 자동 프로비저닝이 사용 설정된 경우 GKE는 워크로드 요구에 따라 풀을 자동으로 만듭니다.
컬렉션을 축소하려면 노드 풀을 삭제하세요.
컬렉션을 삭제하려면 연결된 모든 노드 풀을 삭제하세요. 노드 풀을 삭제하거나 클러스터를 삭제할 수 있습니다. 클러스터를 삭제하면 클러스터에 있는 모든 컬렉션이 삭제됩니다.

단일 호스트 TPU 슬라이스 노드 풀에서 컬렉션 예약 관리

다음 작업을 사용하여 단일 호스트 TPU 슬라이스 노드 풀을 관리합니다.

단일 호스트 TPU 슬라이스 풀에 컬렉션 예약이 사용 설정되어 있는지 확인하려면 다음 명령어를 실행합니다.
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --project PROJECT_NAME \
    --location LOCATION \
    --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'
```
출력은 다음과 비슷합니다.
```
gke-workload-type: HIGH_AVAILABILITY
```
단일 호스트 TPU 슬라이스 풀이 컬렉션의 일부인 경우 출력에는 cloud.google.com/gke-workload-type: HIGH_AVAILABILITY 라벨이 있습니다.
컬렉션을 수직 확장하려면 노드 풀의 크기를 수동으로 조정하거나 노드 자동 프로비저닝을 사용하여 자동으로 조정합니다.
컬렉션을 축소하려면 노드 풀을 삭제하세요.
컬렉션을 삭제하려면 연결된 모든 노드 풀을 삭제하세요. 노드 풀을 삭제하거나 클러스터를 삭제할 수 있습니다. 클러스터를 삭제하면 클러스터에 있는 모든 컬렉션이 삭제됩니다.

멀티슬라이스 사용

더 큰 학습 워크로드를 처리하기 위해 멀티슬라이스에서 더 작은 슬라이스를 함께 집계할 수 있습니다. 자세한 내용은 GKE의 멀티슬라이스 TPU를 참조하세요.

TPU 예약 마이그레이션

기존 TPU 예약이 있는 경우 먼저 TPU 예약을 새로운 Compute Engine 기반 예약 시스템으로 마이그레이션해야 합니다. 또한 마이그레이션이 필요하지 않은 Compute Engine 기반 예약 시스템을 만들 수 있습니다. TPU 예약을 마이그레이션하는 방법을 알아보려면 TPU 예약을 참조하세요.

로깅 사용 설정

TPU VM을 포함하여 GKE 노드에서 실행되는 컨테이너에서 내보낸 로그는 GKE Logging 에이전트에 의해 수집되어 Logging으로 전송되고 Logging에 표시됩니다.

GKE 노드 자동 프로비저닝 사용

TPU 워크로드의 리소스 수요를 충족하기 위해 노드 풀을 자동으로 만들고 삭제하도록 GKE를 구성할 수 있습니다. 자세한 내용은 Cloud TPU 구성을 참조하세요.

커스텀 컴퓨팅 클래스를 사용하여 TPU 프로비저닝

커스텀 컴퓨팅 클래스를 사용하여 새 노드를 만드는 확장 작업 중에 TPU를 요청하도록 GKE를 구성할 수도 있습니다.

커스텀 컴퓨팅 클래스 사양에서 TPU 구성 옵션을 지정할 수 있습니다. GKE 워크로드가 해당 커스텀 컴퓨팅 클래스를 사용하면 GKE는 확장 시 지정된 구성을 사용하는 TPU를 프로비저닝하려고 시도합니다.

TPU 규칙을 따르는 커스텀 컴퓨팅 클래스로 TPU를 프로비저닝하고 워크로드를 배포하려면 다음 단계를 완료하세요.

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - spot: true
    tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - flexStart:
      enabled: true
    tpu:
      type: tpu-v6e-slice
      count: 4
      topology: 2x4
  nodePoolAutoCreation:
    enabled: true

컴퓨팅 클래스를 배포합니다.
```
kubectl apply -f tpu-compute-class.yaml
```
커스텀 컴퓨팅 클래스 및 TPU에 대한 자세한 내용은 TPU 구성을 참조하세요.

다음 매니페스트를 tpu-job.yaml로 저장합니다.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/compute-class: tpu-class
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
        resources:
          requests:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS

다음을 바꿉니다.

NUMBER_OF_CHIPS: 사용할 컨테이너의 TPU 칩 수입니다. limits 및 requests에 대해 동일한 값이어야 하며 선택한 커스텀 컴퓨팅 클래스의 tpu.count 필드 값과 같아야 합니다.
MEMORY_SIZE: TPU가 사용하는 최대 메모리 양입니다. 메모리 한도는 사용 중인 TPU 버전과 토폴로지에 따라 다릅니다. 자세한 내용은 가속기의 최솟값 및 최댓값을 참조하세요.
NUMBER_OF_CHIPS: 사용할 컨테이너의 TPU 칩 수입니다. limits 및 requests 값이 같아야 합니다.

작업을 배포합니다.
```
kubectl create -f tpu-job.yaml
```
이 작업을 만들면 GKE에서 자동으로 다음을 수행합니다.
- 포드를 실행할 노드를 프로비저닝합니다. 지정한 TPU 유형, 토폴로지, 리소스 요청에 따라 이러한 노드는 단일 호스트 슬라이스이거나 멀티 호스트 슬라이스입니다. 최고 우선순위의 TPU 리소스 가용성에 따라 GKE는 획득 가능성을 최대화하기 위해 낮은 우선순위로 대체할 수 있습니다.
- 다른 워크로드가 TPU 워크로드와 동일한 노드에서 실행되지 않도록 taint를 포드에, 톨러레이션(toleration)을 노드에 추가합니다.
자세한 내용은 커스텀 컴퓨팅 클래스 정보를 참조하세요.
이 섹션을 마치면 만든 리소스를 삭제하여 비용이 계속 청구되지 않도록 할 수 있습니다.
```
kubectl delete -f tpu-job.yaml
```

TPU 슬라이스 노드의 자동 복구 구성

멀티 호스트 TPU 슬라이스 노드 풀에서 TPU 슬라이스 노드가 비정상이면 전체 노드 풀이 다시 생성됩니다. 반면에 단일 호스트 TPU 슬라이스 노드 풀에서는 비정상 TPU 노드만 자동 복구됩니다.

비정상 TPU 슬라이스 노드 생성 조건은 다음과 같습니다.

공통 노드 조건이 있는 모든 TPU 슬라이스 노드
할당할 수 없는 TPU 수가 0보다 큰 모든 TPU 슬라이스 노드
선점으로 인해 중지되었거나 종료된 TPU 슬라이스의 모든 VM 인스턴스
노드 유지보수: 멀티 호스트 TPU 슬라이스 노드 풀 내의 TPU 슬라이스 노드가 호스트 유지보수를 위해 작동 중지되면 GKE가 전체 TPU 슬라이스 노드 풀을 다시 만듭니다.

작업 기록에서 복구 상태(실패 이유 포함)를 확인할 수 있습니다. 할당량 부족으로 인해 실패가 발생한 경우Google Cloud 계정 담당자에게 문의하여 해당 할당량을 늘리세요.

TPU 슬라이스 노드에 대한 단계적 종료 구성

1.29.1-gke.1425000 이상을 실행하는 컨트롤 플레인이 있는 GKE 클러스터에서 TPU 슬라이스 노드는 종료가 임박했음을 노드에 알려주는 SIGTERM 신호를 지원합니다. 종료 임박 알림은 TPU 노드에서 최대 5분까지 구성할 수 있습니다.

이 알림 기간 내에 워크로드를 단계적으로 종료하도록 GKE를 구성하려면 GPU 및 TPU에 대한 GKE 노드 중단 관리 안내를 따르세요.

권한이 있는 모드 없이 컨테이너 실행

GKE 버전 1.28 이상의 노드에서 실행되는 컨테이너는 권한이 있는 모드를 사용 설정하지 않아도 TPU에 액세스할 수 있습니다. GKE 버전 1.28 이상의 노드에는 권한 모드가 필요합니다.

TPU 슬라이스 노드가 1.28 미만 버전을 실행하는 경우 다음 섹션을 참조하세요.

TPU 슬라이스의 VM에서 실행 중인 컨테이너는 드라이버가 직접 메모리 액세스(DMA)를 통해 TPU 칩과 통신할 수 있도록 잠긴 메모리에 대한 더 높은 제한에 액세스해야 합니다. 이 기능을 사용 설정하려면 높은 ulimit를 구성해야 합니다. 컨테이너의 권한 범위를 줄이려면 다음 단계를 완료하세요.

다음 필드를 포함하도록 securityContext를 수정합니다.

securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]

TPU 리소스를 사용하도록 워크로드를 설정하기 전에 컨테이너 내에서 다음 명령어를 실행하여 ulimit를 늘립니다.
```
ulimit -l 68719476736
```

TPU v5e의 경우 버전 1.27.4-gke.900 이상의 클러스터에서 권한 모드 없이 실행 중인 컨테이너를 사용할 수 있습니다.

관측 가능성 및 측정항목

대시보드

Google Cloud 콘솔의 노드 풀 모니터링 가능성이 정식 버전으로 출시되었습니다. GKE에서 TPU 멀티 호스트 노드 풀의 상태를 보려면 Cloud Monitoring에서 제공하는 GKE TPU 노드 풀 상태 대시보드로 이동하세요.

GKE TPU 노드 풀 상태로 이동

이 대시보드는 멀티 호스트 TPU 노드 풀의 상태에 대한 포괄적인 통계를 제공합니다. 자세한 내용은 TPU 노드 및 노드 풀의 상태 측정항목 모니터링을 참조하세요.

Google Cloud 콘솔의 Kubernetes 클러스터 페이지에서 관측 가능성 탭에는 가속기 > TPU 헤더 아래에 TPU 사용량과 같은 TPU 관측 가능성 측정항목도 표시됩니다. 자세한 내용은 관측 가능성 측정항목 보기를 참조하세요.

TPU 대시보드는 GKE 클러스터에서 시스템 측정항목을 사용 설정한 경우에만 채워집니다.

런타임 측정항목

GKE 버전 1.27.4-gke.900 이상에서 JAX 버전 0.4.14 이상을 사용하고 containerPort: 8431을 지정하는 TPU 워크로드는 TPU 사용률 측정항목을 GKE 시스템 측정항목으로 내보냅니다. TPU 워크로드의 런타임 성능을 모니터링하기 위해 Cloud Monitoring에서 다음 측정항목을 사용할 수 있습니다.

가동 주기: 이전 샘플링 기간(60초) 동안 TPU 칩에서 TensorCore가 활발하게 처리된 시간의 백분율입니다. 백분율이 높을수록 TPU 사용률이 높은 것입니다.
메모리 사용량: 할당된 가속기 메모리 양(바이트)입니다. 60초마다 샘플링됩니다.
메모리 용량: 총 가속기 메모리 용량(바이트)입니다. 60초마다 샘플링됩니다.

이러한 측정항목은 Kubernetes 노드(k8s_node) 및 Kubernetes 컨테이너(k8s_container) 스키마에 있습니다.

Kubernetes 컨테이너:

kubernetes.io/container/accelerator/duty_cycle
kubernetes.io/container/accelerator/memory_used
kubernetes.io/container/accelerator/memory_total

Kubernetes 노드:

kubernetes.io/node/accelerator/duty_cycle
kubernetes.io/node/accelerator/memory_used
kubernetes.io/node/accelerator/memory_total

TPU 노드 및 노드 풀의 상태 측정항목 모니터링

학습 작업에 오류가 있거나 실패로 종료되면 기본 인프라와 관련된 측정항목을 확인하여 기본 노드 또는 노드 풀의 문제로 인해 중단되었는지 확인할 수 있습니다.

노드 상태

GKE 버전 1.32.1-gke.1357001 이상에서 다음 GKE 시스템 측정항목은 GKE 노드의 상태를 노출합니다.

kubernetes.io/node/status_condition

condition 필드는 Ready, DiskPressure, MemoryPressure와 같은 노드의 조건을 보고합니다. status 필드에는 True, False 또는 Unknown일 수 있는 조건의 보고된 상태가 표시됩니다. 이것은 k8s_node 모니터링 리소스 유형이 있는 측정항목입니다.

이 PromQL 쿼리는 특정 노드가 Ready인지 보여줍니다.

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

클러스터의 문제를 해결하려면 다른 조건을 나타낸 노드를 살펴보세요.

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

Ready가 아닌 노드를 구체적으로 살펴볼 수 있습니다.

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

데이터가 없으면 노드가 준비된 것입니다. 상태 조건은 60초마다 샘플링됩니다.

다음 쿼리를 사용하여 Fleet 전체의 노드 상태를 파악할 수 있습니다.

avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

노드 풀 상태

k8s_node_pool 모니터링 리소스에 대한 다음 GKE 시스템 측정항목은 GKE 노드 풀의 상태를 노출합니다.

kubernetes.io/node_pool/status

이 측정항목은 멀티 호스트 TPU 노드 풀에 대해서만 보고됩니다.

status 필드는 Provisioning, Running, Error, Reconciling, Stopping과 같은 노드 풀의 상태를 보고합니다. GKE API 작업이 완료된 후 상태가 업데이트됩니다.

특정 노드 풀의 상태가 Running인지 확인하려면 다음 PromQL 쿼리를 사용하세요.

kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

상태별로 그룹화된 프로젝트의 노드 풀 수를 모니터링하려면 다음 PromQL 쿼리를 사용하세요.

count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

노드 풀 가용성

다음 GKE 시스템 측정항목은 멀티 호스트 TPU 노드 풀의 사용 가능 여부를 보여줍니다.

kubernetes.io/node_pool/multi_host/available

노드 풀의 모든 노드를 사용할 수 있으면 측정항목의 값이 True이고 그렇지 않으면 False입니다. 측정항목은 60초마다 샘플링됩니다.

프로젝트에서 멀티 호스트 TPU 노드 풀의 가용성을 확인하려면 다음 PromQL 쿼리를 사용하세요.

avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

노드 중단 수

다음 GKE 시스템 측정항목은 마지막 샘플 이후 GKE 노드의 중단 수를 보고합니다(측정항목은 60초마다 샘플링됨).

kubernetes.io/node/interruption_count

interruption_type(예: TerminationEvent, MaintenanceEvent, PreemptionEvent) 및 interruption_reason(예: HostError, Eviction, AutoRepair) 필드는 노드가 중단된 이유를 제공하는 데 도움이 될 수 있습니다.

프로젝트의 클러스터에 있는 TPU 노드의 중단 및 원인을 분류하려면 다음 PromQL 쿼리를 사용하세요.

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

호스트 유지보수 이벤트만 표시하려면 interruption_reason에 대한 HW/SW Maintenance 값을 필터링하도록 쿼리를 업데이트합니다. 다음 PromQL 쿼리를 사용합니다.

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

노드 풀별로 집계된 중단 수를 확인하려면 다음 PromQL 쿼리를 사용하세요.

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

노드 풀 복구 시간(TTR)

다음 GKE 시스템 측정항목은 GKE 멀티 호스트 TPU 노드 풀의 복구 기간 분포를 보고합니다.

kubernetes.io/node_pool/accelerator/times_to_recover

이 측정항목에 기록된 각 샘플은 다운타임 기간의 노드 풀에 대한 단일 복구 이벤트를 나타냅니다.

이 측정항목은 멀티 호스트 TPU 노드 풀의 복구 시간 및 중단 사이의 시간을 추적하는 데 유용합니다.

다음 PromQL 쿼리를 사용하여 클러스터의 지난 7일 동안의 평균 복구 시간(MTTR)을 계산할 수 있습니다.

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

중단 간 노드 풀 시간(TBI)

중단 간 노드 풀 시간은 중단이 발생하기 전까지 인프라가 실행되는 시간을 측정합니다. 이는 일정 기간의 평균으로 계산되며, 분자는 인프라가 가동된 총 시간을 측정하고 분모는 인프라의 총 중단 시간을 측정합니다.

다음 PromQL 예시에서는 지정된 클러스터의 7일 중단 간 평균 시간(MTBI)을 보여줍니다.

sum(count_over_time(
  kubernetes_io:node_memory_total_bytes{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_interruption_count{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))

호스트 측정항목

GKE 버전 1.28.1-gke.1066000 이상에서 TPU 슬라이스의 VM은 TPU 사용률 측정항목을 GKE 시스템 측정항목으로 내보냅니다. TPU 호스트의 성능을 모니터링하기 위해 Cloud Monitoring에서 다음 측정항목을 사용할 수 있습니다.

TensorCore 사용률: 현재 사용되는 TensorCore의 백분율입니다. TensorCore 값은 행렬 곱셈 단위(MXU)와 벡터 단위의 합과 동일합니다. TensorCore 사용률은 지난 샘플 기간 (60초) 동안 수행된 TensorCore 작업을 동일 기간 동안 지원된 TensorCore 작업 수로 나눈 값입니다. 값이 클수록 사용률이 높습니다.
메모리 대역폭 사용률: 사용 중인 가속기 메모리 대역폭의 현재 백분율입니다. 샘플 기간(60초) 동안 사용된 메모리 대역폭을 동일한 샘플 기간 동안 지원된 최대 대역폭으로 나누어 계산합니다.

이러한 측정항목은 Kubernetes 노드(k8s_node) 및 Kubernetes 컨테이너(k8s_container) 스키마에 있습니다.

Kubernetes 컨테이너:

kubernetes.io/container/accelerator/tensorcore_utilization
kubernetes.io/container/accelerator/memory_bandwidth_utilization

Kubernetes 노드:

kubernetes.io/node/accelerator/tensorcore_utilization
kubernetes.io/node/accelerator/memory_bandwidth_utilization

자세한 내용은 Kubernetes 측정항목 및 GKE 시스템 측정항목을 참조하세요.

알려진 문제

이러한 노드가 사용 가능한 TPU를 보고하기 전에는 클러스터 자동 확장 처리가 새 TPU 슬라이스 노드의 용량을 부정확하게 계산할 수 있습니다. 이후 클러스터 자동 확장 처리에서 추가 확장을 수행하여 결과적으로 필요한 것보다 많은 노드가 생성될 수 있습니다. 클러스터 자동 확장 처리에서는 일반적인 축소 작업 후 더 이상 필요하지 않은 추가 노드를 축소합니다.
클러스터 자동 확장 처리에서는 대기 상태로 10시간 이상 유지되는 TPU 슬라이스 노드 풀의 수직 확장을 취소합니다. 클러스터 자동 확장 처리는 나중에 이러한 수직 확장 작업을 다시 시도합니다. 이 동작으로 인해 예약을 사용하지 않는 고객의 TPU 확보 가능성이 저하될 수 있습니다.
TPU taint에 대한 톨러레이션(toleration)이 있는 TPU 외의 워크로드는 TPU 슬라이스 노드 풀 드레이닝 중에 다시 생성될 경우 노드 풀의 축소를 막을 수 있습니다.
메모리 대역폭 사용률 측정항목은 v5e TPU에 제공되지 않습니다.

GKE Standard에 TPU 워크로드 배포 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

시작하기 전에

TPU 구성 계획

TPU 할당량이 있는지 확인

주문형 또는 스팟 VM 할당량

추가 GKE 리소스의 할당량

예약 가용성 확인

GKE에서 TPU를 프로비저닝하는 옵션

클러스터 만들기

노드 풀 만들기

단일 호스트 TPU 슬라이스 노드 풀을 만듭니다.

gcloud

Terraform

콘솔

멀티 호스트 TPU 슬라이스 노드 풀 만들기

gcloud

Terraform

콘솔

GKE에서 용량 문제를 처리하는 방법

TPU 슬라이스 노드에서 워크로드 실행

워크로드 준비

예시 1: TPU 슬라이스 노드 풀에서 사용 가능한 TPU 칩 수를 표시하는 워크로드 실행

예시 2: TPU 슬라이스 에서 사용 가능한 TPU 칩 수를 표시하는 워크로드 실행

가속기를 사용하여 노드 풀 업그레이드(GPU 및 TPU)

삭제

추가 설정 구성

컬렉션 예약 관리

멀티 호스트 TPU 슬라이스 노드 풀에서 컬렉션 예약 관리하기

단일 호스트 TPU 슬라이스 노드 풀에서 컬렉션 예약 관리

멀티슬라이스 사용

TPU 예약 마이그레이션

로깅 사용 설정

GKE 노드 자동 프로비저닝 사용

커스텀 컴퓨팅 클래스를 사용하여 TPU 프로비저닝

TPU 슬라이스 노드의 자동 복구 구성

TPU 슬라이스 노드에 대한 단계적 종료 구성

권한이 있는 모드 없이 컨테이너 실행

관측 가능성 및 측정항목

대시보드

런타임 측정항목

TPU 노드 및 노드 풀의 상태 측정항목 모니터링

노드 상태

노드 풀 상태

노드 풀 가용성

노드 중단 수

노드 풀 복구 시간(TTR)

중단 간 노드 풀 시간(TBI)

호스트 측정항목

알려진 문제

다음 단계

GKE Standard에 TPU 워크로드 배포