클러스터 만들기
이 페이지에서는 Kubernetes 버전 1.29.3-gke.600의 Azure용 GKE에서 클러스터와 노드 풀을 만드는 방법을 설명합니다.
시작하기 전에
이 페이지의 단계를 완료하려면 다음을 수행하세요.
기본 요건 구성의 단계를 따르세요.
제어 영역을 여러 영역 또는 단일 영역에서 실행할지 선택합니다.
클러스터에 제공할 클래스 없는 도메인 간 라우팅(CIDR) 범위를 선택합니다.
제어 영역의 영역 배치
기본적으로 Azure용 GKE는 선택한 리전에서 3개 영역 간에 동일한 서브넷에 개별 제어 영역 복제본을 배치합니다. 이러한 영역과 서브넷을 선택할 수 있습니다.
기본 제어 영역 복제본 배치를 사용하려면 클러스터의 CIDR 범위 선택으로 건너뜁니다.
Azure NAT 게이트웨이 및 클러스터 제어 영역
각 제어 영역 복제본이 정상 상태로 작동하려면 Google에서 호스팅되는 관리 서비스에도 연결해야 합니다.
Azure NAT 게이트웨이를 사용하여 아웃바운드 연결을 제공하는 경우 영역 장애가 클러스터 제어 영역에 미치는 영향을 고려해야 합니다. 하나의 NAT 게이트웨이 엔드포인트가 단일 영역으로 격리되거나 리전/비영역이고 이것이 단일 장애점을 나타냅니다.
단일 영역에 제어 영역 복제본을 배치하려면 단일 서브넷 및 영역을 사용합니다. 아웃바운드 연결을 위해 NAT 게이트웨이를 사용하는 경우 엔드포인트가 동일한 영역에 배치되었는지 확인합니다.
복제본을 2개 또는 3개의 영역에 배치하려면 클러스터를 만들 때 서브넷 및 영역 목록을 전달할 수 있습니다. 2개의 서브넷 및 영역을 전달할 때 Azure용 GKE는 제공된 첫 번째 영역에 2개의 복제본을 배치합니다. 3개의 서브넷과 영역을 전달할 때 Azure용 GKE는 각 서브넷에 복제본을 배치합니다. 자세한 내용은 특정 서브넷에 복제본 배치를 참조하세요.
고가용성을 위해 Azure 서브넷 및 영역을 구성하는 방법에 대한 자세한 내용은 Azure 문서의 영역 스택을 사용한 영역 격리를 참조하세요.
특정 서브넷에 복제본 배치
이 섹션은 선택사항입니다.
제어 영역 복제본이 배치되는 영역을 제어하려면 --replica-placements 플래그를 사용하고 클러스터를 만들 때 서브넷 ID 및 영역 목록을 전달합니다. 제어 영역 복제본을 배치할 서브넷 및 영역은 최대 3개까지 사용할 수 있습니다.
서브넷 목록의 형식을 지정하려면 다음 단계를 수행합니다.
az명령줄 도구를 사용하여 Azure 서브넷 ID를 가져옵니다.az network vnet subnet show \ --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \ --name SUBNET_NAME --query "id" -otsv다음을 바꿉니다.
CLUSTER_RESOURCE_GROUP_NAME: 클러스터를 실행하려는 기존 리소스 그룹 이름VNET_RESOURCE_GROUP_NAME: VNet이 포함된 리소스 그룹 이름VNET_NAME: VNet 이름SUBNET_NAME: 서브넷 이름
출력은 서브넷의 ID입니다. Azure 서브넷 ID는 다음과 같이 표시됩니다.
/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME
제어 영역 복제본을 만들 서브넷마다 이 명령어를 반복합니다. 다음 단계를 위해 서브넷 ID를 텍스트 편집기에 복사합니다.
서브넷 및 영역이 콜론으로 구분되어 있고 서브넷 ID 및 Azure 가용성 영역이 쉼표로 구분된 목록을 만듭니다. 예를 들어 영역 1의
subnet1, 영역 2의subnet2, 영역 3의subnet3에 제어 영역 복제본을 만들려면 다음 문자열을 사용합니다./subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet1:1,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet2:2,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet3:3
이 문자열을 복사해서 클러스터를 만들 때
--replica-placements플래그에 대한 값으로 사용합니다.
클러스터의 CIDR 범위 선택
Azure용 GKE에서 클러스터를 만들 때 포드 및 서비스에 사용할 IPv4 주소 범위를 제공해야 합니다.
이러한 IP 범위는 클래스 없는 도메인 간 라우팅(CIDR) 표기법(예: 100.64.0.0/16)을 사용하여 지정합니다.
추천 범위
서비스 및 포드에 다음 CIDR 범위를 사용하는 것이 좋습니다.
- 서비스: 100.64.0.0/16
- 포드: 100.96.0.0/11
아무 문제 없이 클러스터를 확장할 수 있을 만큼 충분히 큰 범위입니다.
다음 섹션에서 더 자세히 다룹니다.
범위 선택에 대한 세부정보
Azure용 GKE는 포드와 서비스에 오버레이 네트워크를 사용하므로 이러한 네트워크의 IP 범위를 VNet 내에서 라우팅할 필요가 없습니다. 사용하는 모든 IP 범위를 사용할 수 있어야 합니다. 자세한 내용은 Dataplane V2를 참조하세요.
포드와 서비스 IP 범위는 제어 영역이나 노드 풀 서브넷 IP 범위가 포함되지 않는 경우 VNet 네트워크와 겹칠 수 있습니다.
포드와 서비스 IP 범위는 다음 비공개 IP 범위 중 하나에 속해야 합니다.
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16— 비공개 IP 주소(RFC 1918)100.64.0.0/10— 공유 주소 공간(RFC 6598)192.0.0.0/24— IETF 프로토콜 할당(RFC 6890)192.0.2.0/24,198.51.100.0/24,203.0.113.0/24— 문서(RFC 5737)192.88.99.0/24— IPv6-IPv4 릴레이(지원 중단됨)(RFC 7526)198.18.0.0/15— 벤치마크 테스트(RFC 2544)
100.64.0.0/10(RFC 6598) 내의 IP 범위를 사용하는 것이 좋습니다. 이 범위는 이동통신사급 NAT에 예약되며 사용자의 VNet에서 사용되지 않을 가능성이 높습니다.
예를 들어 다음은 포드, 서비스, 노드 네트워크가 겹치지 않는 유효한 구성입니다(VNet은 RFC 1918 비공개 IP 주소를 사용하는 반면 포드와 서비스 네트워크는 RFC 6598 비공개 IP와 겹침).
- VNet 네트워크:
10.0.0.0/16,172.16.1.0/24,172.16.2.0/24 - 포드 네트워크:
100.65.0.0/16 - 서비스 네트워크:
100.66.0.0/16
다음은 제어 영역 복제본과 겹치지 않으므로 포드와 서비스 네트워크가 VNet 네트워크와 겹치더라도 유효한 구성입니다.
- VNet 네트워크:
10.0.0.0/16 - 포드 네트워크:
10.0.1.0/24 - 서비스 네트워크:
10.0.2.0/24 - 제어 영역 복제본 서브넷:
10.0.3.0/24,10.0.4.0/24,10.0.5.0/24
다음 구성은 포드 IP 범위가 제어 영역 네트워크와 겹치므로 잘못되었습니다. 이러한 중복으로 인해 워크로드가 VNet 네트워크의 제어 영역 복제본과 통신하지 못할 수 있습니다.
- VNet 네트워크:
10.0.0.0/16 - 포드 네트워크:
10.0.1.0/24 - 서비스 네트워크:
10.1.0.0/24 - 제어 영역 복제본 서브넷:
10.0.1.0/24,10.0.2.0/24,10.0.3.0/24
포드 주소 범위에 대한 세부정보
Kubernetes는 포드 주소 범위에서 포드 객체에 주소를 할당합니다. 클러스터의 포드 범위는 각 노드에 대해 더 작은 범위로 분할됩니다. 포드가 특정 노드에 예약되면 Kubernetes는 노드의 범위에 속하는 포드 IP 주소를 할당합니다.
포드 주소 범위의 크기를 계산하려면 클러스터에 사용할 노드 수와 각 노드에서 실행할 포드 수를 예측해야 합니다.
다음 표에서 실행할 노드 수와 포드 수를 기준으로 포드 CIDR 범위의 크기가 나와 있습니다.
포드 주소 범위 표
| 포드 주소 범위 | 최대 포드 IP 주소 수 | 최대 노드 수 | 최대 포드 수 |
|---|---|---|---|
| /24 가능한 최소 포드 주소 범위 |
주소 256개 | 노드 1개 | 포드 110개 |
| /23 | 주소 512개 | 노드 2개 | 포드 220개 |
| /22 | 주소 1,024개 | 노드 4개 | 포드 440개 |
| /21 | 주소 2,048개 | 노드 8개 | 포드 880개 |
| /20 | 주소 4,096개 | 노드 16개 | 포드 1,760개 |
| /19 | 주소 8,192개 | 노드 32개 | 포드 3,520개 |
| /18 | 주소 16,384개 | 노드 64개 | 포드 7,040개 |
| /17 | 주소 32,768개 | 노드 128개 | 포드 14,080개 |
| /16 | 주소 65,536개 | 노드 256개 | 포드 28,160개 |
| /15 | 주소 131,072개 | 노드 512개 | 포드 56,320개 |
| /14 | 주소 262,144개 | 노드 1,024개 | 포드 112,640개 |
서비스 주소 범위에 대한 세부정보
Kubernetes는 서비스 객체(예: 이 주소 범위의 부하 분산기)에 가상 IP 주소를 할당합니다.
서비스 주소 범위의 크기를 계산하려면 클러스터에 포함할 서비스 수를 예측해야 합니다.
다음 표에서는 실행할 서비스 수를 기준으로 서비스 CIDR 범위의 크기 권장사항을 제공합니다.
서비스 주소 범위 표
| 서비스 주소 범위 | 최대 서비스 수 |
|---|---|
| /27 가능한 최소 서비스 주소 범위 |
서비스 32개 |
| /26 | 서비스 64개 |
| /25 | 서비스 128개 |
| /24 | 서비스 256개 |
| /23 | 서비스 512개 |
| /22 | 서비스 1,024개 |
| /21 | 서비스 2,048개 |
| /20 | 서비스 4,096개 |
| /19 | 서비스 8,192개 |
| /18 | 서비스 16,384개 |
| /17 | 서비스 32,768개 |
| /16 가능한 최대 서비스 주소 범위 |
서비스 65,536개 |
Azure에 인증
Azure용 GKE는 Azure에 인증하는 두 가지 방법인 워크로드 아이덴티티 제휴와 클라이언트 인증서 만들기를 제공합니다. 워크로드 아이덴티티 제휴 인증은 더 간단하고 안전하므로 권장되는 방법입니다.
워크로드 아이덴티티 제휴
워크로드 식별 제휴를 사용하면 Azure용 GKE가 Google 서비스 계정을 사용하여 Azure에 인증하고 이를 통해 Azure AD 애플리케이션의 리소스를 관리할 수 있습니다. AzureClient와 달리 인증서를 관리하고 Azure AD에 수동으로 업로드할 필요가 없습니다.
Azure AD 애플리케이션에서 제휴 ID 사용자 인증 정보를 구성하려면 다음 명령어를 실행합니다. 각 Azure AD 애플리케이션에 최대 20개의 사용자 인증 정보를 추가할 수 있습니다.
Azure 애플리케이션 ID를 환경 변수에 저장합니다.
APPLICATION_ID=$(az ad app list --all \ --query "[?displayName=='APPLICATION_NAME'].appId" --output tsv) PROJECT_ID="$(gcloud config get-value project)" PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \ --format "value(projectNumber)")APPLICATION_NAME: Azure Active Directory 애플리케이션 만들기에서 사용한 Azure AD 애플리케이션 이름입니다.
credential.json이라는 JSON 파일을 만듭니다.{ "name": "CREDENTIAL_NAME", "issuer": "https://accounts.google.com", "subject": "service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com", "audiences": ["api://AzureADTokenExchange"], "description": "Allow GKE on Azure to authenticate to the Azure AD application using a Google service account." }CREDENTIAL_NAME: 사용자 인증 정보 이름PROJECT_NUMBER: 클러스터를 호스팅하는 Google Cloud 프로젝트 수
Azure AD 애플리케이션에 제휴 ID 사용자 인증 정보를 만듭니다.
az ad app federated-credential create --id "${APPLICATION_ID}" --parameters credential.json
자세한 내용은 Google Cloud와 Azure AD 워크로드 아이덴티티 제휴 문서를 참조하세요.
Terraform을 사용하여 Azure 제휴 ID 사용자 인증 정보를 프로비저닝할 수도 있습니다. 자세한 내용은 azuread_application_federated_identity_credential을 참조하세요.
사용자 인증 정보를 구성한 후 클러스터의 SSH 키 쌍을 만들거나 선택합니다.
SSH 키 쌍 만들기
클러스터를 만들 때 SSH 키 쌍을 제공해야 합니다. 사용할 키 쌍이 이미 있으면 이 단계를 건너뜁니다.
새 키 쌍을 만들려면
ssh-keygen명령줄 도구를 사용합니다.ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATHKEY_PATH를 새 비공개 키의 경로로 바꿉니다.이 키를 환경 변수에 저장합니다.
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)예를 들어
~/.ssh/anthos-multicloud-key.pub에 새 키 쌍을 만들고 공개 키를 환경 변수에 저장하려면 다음 명령어를 실행합니다.ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/anthos-multicloud-key SSH_PUBLIC_KEY=$(cat ~/.ssh/anthos-multicloud-key.pub)
공개 키를 환경 변수에 저장한 후에는 이제 클러스터를 만들 수 있습니다.
Fleet 호스트 프로젝트 선택
Fleet은 클러스터를 더 큰 그룹으로 조직화하는 Google Cloud의 개념입니다. Fleet을 사용하면 여러 클라우드를 망라하여 다수의 클러스터를 관리하고 일관된 정책을 적용할 수 있습니다. GKE Multi-cloud API는 클러스터가 생성될 때 자동으로 클러스터를 Fleet에 등록합니다.
클러스터를 만들 때 클러스터가 관리될 Fleet 호스트 프로젝트를 지정합니다. Azure용 GKE는 클러스터 이름을 Fleet 멤버십 이름으로 사용하므로 클러스터 이름이 Fleet 전체에서 고유해야 합니다.
프로젝트 간 등록
클러스터가 있는 Google Cloud 프로젝트 이외의 Fleet 호스트 프로젝트를 사용하려면 멀티 클라우드 서비스 에이전트 서비스 계정에 추가 IAM 정책 바인딩을 적용해야 합니다. 그러면 서비스 계정이 Fleet 호스트 프로젝트로 Fleet을 관리할 수 있습니다.
서비스 에이전트를 프로젝트에 추가하려면 다음 명령어를 실행합니다.
gcloud beta services identity create --service=gkemulticloud.googleapis.com \ --project=CLUSTER_PROJECT_NUMBERCLUSTER_PROJECT_NUMBER를 Google Cloud 프로젝트 번호로 바꿉니다.다음 명령어로 이 binding을 할당합니다.
gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \ --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \ --role="roles/gkemulticloud.serviceAgent"다음을 바꿉니다.
FLEET_PROJECT_ID: Fleet 호스트 프로젝트의 Google Cloud 프로젝트CLUSTER_PROJECT_NUMBER: Google Cloud 프로젝트 번호
멀티 클라우드 서비스 에이전트 계정 이름은 service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com 형식입니다.
Google Cloud 콘솔 서비스 계정 페이지에서 서비스 계정을 찾을 수 있습니다. 프로젝트 번호를 찾는 방법에 대한 자세한 내용은 프로젝트 식별을 참조하세요.
클러스터 만들기
클러스터를 만들려면 다음 명령어를 실행하세요.
Azure 리소스 그룹, VNet, 서브넷 ID를 환경 변수에 저장합니다.
SUBSCRIPTION_ID=$(az account show --query "id" --output tsv) TENANT_ID=$(az account list \ --query "[?id=='${SUBSCRIPTION_ID}'].{tenantId:tenantId}" --output tsv) CLUSTER_RG_ID=$(az group show --resource-group=CLUSTER_RESOURCE_GROUP_NAME \ --query "id" -otsv) VNET_ID=$(az network vnet show --resource-group=VNET_RESOURCE_GROUP_NAME \ --name=VNET_NAME --query "id" -otsv) SUBNET_ID=$(az network vnet subnet show \ --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \ --name default --query "id" -otsv)다음을 바꿉니다.
CLUSTER_RESOURCE_GROUP_NAME: 클러스터를 실행하려는 기존 리소스 그룹 이름VNET_RESOURCE_GROUP_NAME: VNet이 포함된 리소스 그룹 이름VNET_NAME: VNet의 이름
Google Cloud CLI로 클러스터를 만듭니다.
워크로드 아이덴티티 제휴
gcloud container azure clusters create CLUSTER_NAME \ --location GOOGLE_CLOUD_LOCATION \ --fleet-project FLEET_PROJECT \ --azure-tenant-id "${TENANT_ID}" \ --azure-application-id "${APPLICATION_ID}" \ --azure-region AZURE_REGION \ --pod-address-cidr-blocks POD_CIDR \ --service-address-cidr-blocks SERVICE_CIDR \ --vm-size VM_SIZE \ --cluster-version 1.29.3-gke.600 \ --ssh-public-key "$SSH_PUBLIC_KEY" \ --resource-group-id "$CLUSTER_RG_ID" \ --vnet-id "$VNET_ID" \ --subnet-id "$SUBNET_ID" # Optional, see following note \ --tags "control-plane=CLUSTER_NAME" \ --admin-users ADMIN_USERS_LISTAzure 클라이언트
gcloud container azure clusters create CLUSTER_NAME \ --location GOOGLE_CLOUD_LOCATION \ --fleet-project FLEET_PROJECT \ --client CLIENT_NAME \ --azure-region AZURE_REGION \ --pod-address-cidr-blocks POD_CIDR \ --service-address-cidr-blocks SERVICE_CIDR \ --vm-size VM_SIZE \ --cluster-version 1.29.3-gke.600 \ --ssh-public-key "$SSH_PUBLIC_KEY" \ --resource-group-id "$CLUSTER_RG_ID" \ --vnet-id "$VNET_ID" \ --subnet-id "$SUBNET_ID" # Optional, see following note \ --tags "control-plane=CLUSTER_NAME" \ --admin-users ADMIN_USERS_LIST다음을 바꿉니다.
CLUSTER_NAME: 클러스터 이름GOOGLE_CLOUD_LOCATION: 클러스터를 관리하는 Google Cloud 위치FLEET_PROJECT: 클러스터를 등록할 Fleet 호스트 프로젝트. 다른 Google Cloud 프로젝트에서 이 클러스터를 관리하려면 프로젝트 간 등록을 참조하세요.AZURE_REGION: Google Cloud 리전과 연결된 지원되는 Azure 리전POD_CIDR: 클러스터의 포드 주소 범위(예:10.0.1.0/18)SERVICE_CIDR: 클러스터의 서비스 주소 범위VM_SIZE: 지원되는 Azure VM 크기ADMIN_USERS_LIST(선택사항): 관리자 권한을 부여할 사용자의 이메일 주소가 쉼표로 구분된 목록. 예를 들면 다음과 같습니다. 'kai@example.com,hao@example.com,kalani@example' 기본값은 클러스터를 만드는 사용자입니다.CLIENT_NAME: AzureClient 이름
클러스터 상태를 확인합니다.
gcloud container azure clusters describe CLUSTER_NAME --location GOOGLE_CLOUD_LOCATION다음을 바꿉니다.
CLUSTER_NAMEGOOGLE_CLOUD_LOCATION
출력에는 클러스터의 상태 및 구성에 대한 정보가 포함됩니다.
Cloud Logging/Cloud Monitoring 승인
Azure용 GKE가 시스템 로그 및 측정항목을 만들고 Google Cloud에 업로드할 수 있도록 하려면 승인되어야 합니다.
Google Cloud Logging에 로그를 기록하고 Google Cloud Monitoring에 측정항목을 기록하도록 Kubernetes 워크로드 아이덴티티 gke-system/gke-telemetry-agent를 승인하려면 다음 명령어를 실행합니다.
gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
--member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
--role=roles/gkemulticloud.telemetryWriter
GOOGLE_PROJECT_ID를 클러스터의 Google Cloud 프로젝트 ID로 바꿉니다.
이 IAM binding은 Google Cloud 프로젝트의 모든 클러스터가 로그 및 측정항목을 업로드하도록 액세스 권한을 부여합니다. 프로젝트의 첫 번째 클러스터를 만든 후에만 이를 실행해야 합니다.
Google Cloud 프로젝트에 클러스터가 하나 이상 생성되어 있지 않으면 이 IAM 바인딩 추가가 실패합니다. 이는 참조하는 워크로드 아이덴티티 풀(GOOGLE_PROJECT_ID.svc.id.goog)이 클러스터를 만들 때까지 프로비저닝되지 않기 때문입니다.
노드 풀 만들기
노드 풀을 만들려면 다음이 필요합니다.
az명령줄 도구를 사용하여 Azure 서브넷 ID를 검색할 수 있는 권한- 클러스터의 SSH 공개 키에 대한 액세스 권한
노드 풀을 만들려면 다음 명령어를 실행합니다.
Azure VNet 서브넷 ID와 SSH 공개 키를 환경 변수에 저장합니다.
SUBNET_ID=$(az network vnet subnet show \ --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \ --name default --query "id" -otsv) SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)다음을 바꿉니다.
VNET_RESOURCE_GROUP_NAME: VNet이 포함된 리소스 그룹 이름VNET_NAME: VNet의 이름KEY_PATH: 키 쌍의 경로
Google Cloud CLI를 사용하여 노드 풀을 만듭니다.
gcloud container azure node-pools create NODE_POOL_NAME \ --cluster CLUSTER_NAME \ --location GOOGLE_CLOUD_LOCATION \ --node-version 1.29.3-gke.600 \ --vm-size VM_SIZE \ --max-pods-per-node 110 \ --min-nodes MIN_NODES \ --max-nodes MAX_NODES \ --ssh-public-key "${SSH_PUBLIC_KEY}" \ --subnet-id "${SUBNET_ID}"다음을 바꿉니다.
NODE_POOL_NAME: 노드 풀의 고유한 이름(예:node-pool-1)CLUSTER_NAME: Azure용 GKE 클러스터의 이름GOOGLE_CLOUD_LOCATION: 클러스터를 관리하는 Google Cloud 위치VM_SIZE: 지원되는 Azure VM 크기MIN_NODES: 노드 풀의 최소 노드 수. 자세한 내용은 클러스터 자동 확장 처리를 참조하세요.MAX_NODES: 노드 풀의 최대 노드 수
노드 풀의 상태를 확인합니다.
gcloud container azure node-pools describe NODE_POOL_NAME \ --cluster CLUSTER_NAME \ --location GOOGLE_CLOUD_LOCATION다음을 바꿉니다.
NODE_POOL_NAME: 노드 풀의 고유한 이름(예:node-pool-1)CLUSTER_NAME: Azure용 GKE 클러스터의 이름GOOGLE_CLOUD_LOCATION: 클러스터를 관리하는 Google Cloud 위치
출력에는
PROVISIONING또는RUNNING을 포함하여 노드 풀의 상태가 포함됩니다.
다음 단계
- kubectl의 클러스터 액세스 구성
- 노드 풀 만들기
- 빠른 시작을 사용하여 첫 번째 워크로드 시작해 보기
gcloud container clusters create참조 문서를 읽어봅니다.- 클러스터를 만드는 데 문제가 있나요? 자세한 내용은 문제 해결을 참조하세요.