Membuat cluster

Halaman ini menjelaskan cara membuat cluster dan node pool di GKE pada Azure pada Kubernetes versi 1.29.3-gke.600.

Sebelum memulai

Untuk menyelesaikan langkah-langkah di halaman ini, lakukan hal berikut:

  1. Ikuti langkah-langkah di Mengonfigurasi prasyarat.

  2. Pilih apakah Anda akan menjalankan bidang kontrol di beberapa zona atau satu zona.

  3. Pilih rentang perutean antar-domain (CIDR) tanpa class yang akan diberikan ke cluster Anda.

Penempatan zona bidang kontrol

Secara default, GKE di Azure menempatkan replika bidang kontrol terpisah dalam subnet yang sama di tiga zona di region yang Anda pilih. Anda dapat memilih zona dan subnet.

Jika Anda ingin menggunakan penempatan replika bidang kontrol default, lanjutkan ke bagian Memilih rentang CIDR untuk cluster Anda.

Gateway dan bidang kontrol cluster Azure NAT

Setiap replika bidang kontrol juga memerlukan konektivitas ke layanan pengelolaan yang dihosting Google untuk beroperasi dalam status normal.

Jika menggunakan gateway Azure NAT untuk menyediakan konektivitas keluar, Anda harus mempertimbangkan bagaimana kegagalan zona memengaruhi bidang kontrol cluster. Satu endpoint gateway NAT diisolasi ke satu zona atau bersifat regional/non-zona, dan ini menunjukkan titik kegagalan tunggal.

Jika Anda ingin menempatkan replika bidang kontrol dalam satu zona, gunakan satu subnet dan zona. Jika Anda menggunakan NAT Gateway untuk konektivitas keluar, pastikan endpoint ditempatkan di zona yang sama.

Jika ingin menempatkan replika di dua atau tiga zona, Anda dapat meneruskan daftar subnet dan zona saat membuat cluster. Saat Anda meneruskan dua subnet dan zona, GKE di Azure akan menempatkan dua replika di zona pertama yang disediakan. Saat Anda meneruskan tiga subnet dan zona, GKE di Azure menempatkan replika di setiap subnet. Untuk mengetahui informasi selengkapnya, lihat Menempatkan replika di subnet tertentu.

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi subnet dan zona Azure untuk ketersediaan tinggi, lihat Isolasi zona dengan stack zona dalam dokumentasi Azure.

Menempatkan replika di subnet tertentu

Bagian ini bersifat opsional.

Untuk mengontrol di zona mana replika bidang kontrol ditempatkan, gunakan flag --replica-placements serta teruskan daftar ID dan zona subnet saat membuat cluster. Anda dapat menggunakan hingga tiga subnet dan zona untuk menempatkan replika bidang kontrol.

Untuk memformat daftar subnet, lakukan langkah-langkah berikut.

  1. Ambil ID subnet Azure Anda dengan alat command line az:

    az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name SUBNET_NAME --query "id" -otsv

    Ganti kode berikut:

    • CLUSTER_RESOURCE_GROUP_NAME: nama grup resource yang sudah ada tempat Anda ingin menjalankan cluster
    • VNET_RESOURCE_GROUP_NAME: nama grup resource yang menyimpan VNet Anda
    • VNET_NAME: nama VNet Anda
    • SUBNET_NAME: nama subnet Anda

    Outputnya adalah ID subnet. ID subnet Azure terlihat seperti berikut:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

    Ulangi perintah ini untuk setiap subnet tempat Anda ingin membuat replika bidang kontrol. Salin ID subnet ke editor teks untuk langkah berikut.

  2. Buat daftar yang dipisahkan koma untuk ID subnet dan zona ketersediaan Azure, dengan titik dua yang memisahkan subnet dan zona. Misalnya, untuk membuat replika bidang kontrol di subnet1 di zona 1, subnet2 di zona 2, dan subnet3 di zona 3, gunakan string berikut:

    /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

    Salin string ini dan gunakan sebagai nilai untuk flag --replica-placements saat Anda membuat cluster.

Pilih rentang CIDR untuk cluster Anda

Saat membuat cluster di GKE di Azure, Anda harus menyediakan rentang alamat IPv4 yang akan digunakan untuk Pod dan Service.

Rentang IP ini ditentukan menggunakan notasi Classless Inter-Domain Routing (CIDR)—misalnya, 100.64.0.0/16.

Sebaiknya gunakan rentang CIDR berikut untuk Layanan dan Pod:

  • Layanan: 100.64.0.0/16
  • Pod: 100.96.0.0/11

Rentang ini cukup besar bagi Anda untuk mengembangkan cluster tanpa masalah.

Bagian berikut memberikan detail selengkapnya.

Detail tentang memilih rentang

GKE di Azure menggunakan jaringan overlay untuk Pod dan Service, sehingga rentang IP untuk jaringan ini tidak perlu dapat dirutekan dalam VNet. Setiap rentang IP yang Anda gunakan harus dijamin tersedia. Untuk mengetahui informasi selengkapnya, lihat Dataplane V2.

  • Rentang IP Pod dan Service dapat tumpang-tindih dengan jaringan VNet, asalkan tidak mencakup bidang kontrol atau rentang IP subnet kumpulan node.

  • Rentang IP Pod dan Service harus berada dalam salah satu rentang IP pribadi berikut:

    • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — Alamat IP pribadi (RFC 1918)
    • 100.64.0.0/10 — Ruang alamat bersama (RFC 6598)
    • 192.0.0.0/24 — Penetapan protokol IETF (RFC 6890)
    • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — Dokumentasi (RFC 5737)
    • 192.88.99.0/24 — Relai IPv6 ke IPv4 (tidak digunakan lagi) (RFC 7526)
    • 198.18.0.0/15 — Pengujian benchmark (RFC 2544)

Sebaiknya rentang IP dalam 100.64.0.0/10 (RFC 6598). Rentang ini dicadangkan untuk NAT tingkat operator, yang kemungkinan tidak digunakan di VNet Anda.

Misalnya, berikut adalah konfigurasi yang valid dengan jaringan Pod, Service, dan Node yang tidak tumpang tindih (VNet menggunakan alamat IP pribadi RFC 1918, sedangkan jaringan Pod dan Service ditempatkan ke IP pribadi RFC 6598).

  • Jaringan VNet: 10.0.0.0/16, 172.16.1.0/24, 172.16.2.0/24
  • Jaringan pod: 100.65.0.0/16
  • Jaringan layanan: 100.66.0.0/16

Berikut ini juga konfigurasi yang valid meskipun ada jaringan Pod dan Service yang tumpang-tindih dengan jaringan VNet karena tidak ada tumpang-tindih dengan replika bidang kontrol.

  • Jaringan VNet: 10.0.0.0/16
  • Jaringan pod: 10.0.1.0/24
  • Jaringan layanan: 10.0.2.0/24
  • Subnet Replika Pesawat Kontrol: 10.0.3.0/24, 10.0.4.0/24, 10.0.5.0/24

Konfigurasi berikut tidak valid karena rentang IP Pod tumpang-tindih dengan jaringan bidang kontrol. Tumpang tindih ini dapat mencegah beban kerja berkomunikasi dengan replika bidang kontrol di jaringan VNet:

  • Jaringan VNet: 10.0.0.0/16
  • Jaringan pod: 10.0.1.0/24
  • Jaringan layanan: 10.1.0.0/24
  • Subnet Replika Pesawat Kontrol: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Detail tentang rentang alamat IP Pod

Kubernetes mengalokasikan alamat ke objek Pod dari rentang alamat IP Pod. Rentang Pod cluster dibagi menjadi rentang yang lebih kecil untuk setiap node. Saat Pod dijadwalkan pada node tertentu, Kubernetes akan menetapkan alamat IP Pod dari rentang node.

Untuk menghitung ukuran rentang alamat Pod, Anda perlu memperkirakan jumlah node yang diinginkan dalam cluster dan jumlah Pod yang ingin dijalankan di setiap node.

Tabel berikut memberikan rekomendasi ukuran untuk rentang CIDR Pod berdasarkan jumlah node dan Pod yang ingin dijalankan.

Tabel rentang alamat pod

Rentang alamat IP pod Alamat IP Pod maksimum Node maksimum Pod maksimum
/24
Rentang alamat IP Pod terkecil		 256 alamat 1 node 110 Pod
/23 512 alamat 2 node 220 Pod
/22 1.024 alamat 4 node 440 Pod
/21 2.048 alamat 8 node 880 Pod
/20 4.096 alamat 16 node 1.760 Pod
/19 8.192 alamat 32 node 3.520 Pod
/18 16.384 alamat 64 node 7.040 Pod
/17 32.768 alamat 128 node 14.080 Pod
/16 65.536 alamat 256 node 28.160 Pod
/15 131.072 alamat 512 node 56.320 Pod
/14 262.144 alamat 1.024 node 112.640 Pod

Detail tentang rentang alamat layanan

Kubernetes mengalokasikan alamat IP virtual untuk Objek layanan — misalnya, load balancer dari rentang alamat ini.

Untuk menghitung ukuran rentang alamat Layanan, Anda perlu memperkirakan jumlah layanan yang Anda inginkan dalam cluster.

Tabel berikut memberikan rekomendasi ukuran untuk rentang CIDR Layanan berdasarkan jumlah Layanan yang ingin Anda jalankan.

Tabel rentang alamat layanan

Rentang alamat IP layanan Jumlah Layanan maksimum
/27
Rentang alamat URL Layanan terkecil		 32 Layanan
/26 64 Layanan
/25 128 Layanan
/24 256 Layanan
/23 512 Layanan
/22 1.024 Layanan
/21 2.048 Layanan
/20 4.096 Layanan
/19 8.192 Layanan
/18 16.384 Layanan
/17 32.768 Layanan
/16
Rentang alamat IP Layanan seluas mungkin		 65.536 Layanan

Melakukan Autentikasi ke Azure

GKE di Azure menyediakan dua metode autentikasi ke Azure: federasi identitas workload dan membuat sertifikat klien. Autentikasi workload identity federation adalah metode yang direkomendasikan karena lebih sederhana dan aman.

Workload identity federation

Federasi identifikasi workload memungkinkan GKE di Azure melakukan autentikasi ke Azure menggunakan akun layanan Google, agar selanjutnya dapat mengelola resource di aplikasi Azure AD. Dibandingkan dengan AzureClient, Anda tidak perlu mengelola sertifikat dan mengupload ke Azure AD secara manual.

Untuk mengonfigurasi kredensial identitas gabungan di aplikasi Azure AD Anda, jalankan perintah berikut. Perlu diperhatikan bahwa Anda dapat menambahkan hingga dua puluh kredensial ke setiap aplikasi Azure AD.

  1. Simpan ID aplikasi Azure Anda ke variabel lingkungan:

    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)")

  2. Buat file JSON bernama credential.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: nama kredensial.
    • PROJECT_NUMBER: jumlah project Google Cloud yang menghosting cluster.

  3. Buat kredensial identitas gabungan di aplikasi Azure AD:

    az ad app federated-credential create --id "${APPLICATION_ID}" --parameters credential.json

Untuk mengetahui detail selengkapnya, lihat dokumentasi Azure Azure AD workload identity federation dengan Google Cloud.

Anda juga dapat menyediakan kredensial identitas gabungan Azure menggunakan Terraform. Untuk mengetahui detailnya, lihat azuread_application_federated_identity_credential.

Setelah mengonfigurasi kredensial, buat atau pilih pasangan kunci SSH untuk cluster Anda.

Membuat pasangan kunci ssh

Saat membuat cluster, Anda harus menyediakan pasangan kunci SSH. Jika Anda sudah memiliki pasangan kunci yang akan digunakan, lewati langkah ini.

  1. Untuk membuat pasangan kunci baru, gunakan alat command line ssh-keygen:

    ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATH

    Ganti KEY_PATH dengan jalur ke kunci pribadi baru Anda.

  2. Simpan kunci dalam variabel lingkungan:

    SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Misalnya, untuk membuat pasangan kunci baru di ~/.ssh/anthos-multicloud-key.pub dan menyimpan kunci publik dalam variabel lingkungan, jalankan perintah berikut:

    ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/anthos-multicloud-key
SSH_PUBLIC_KEY=$(cat ~/.ssh/anthos-multicloud-key.pub)

Setelah menyimpan kunci publik ke variabel lingkungan, Anda siap untuk membuat cluster.

Pilih project host Armada Anda

Armada adalah konsep Google Cloud untuk mengatur cluster ke dalam grup yang lebih besar. Dengan fleet, Anda dapat mengelola banyak cluster di beberapa cloud dan menerapkan kebijakan yang konsisten di semua cluster tersebut. GKE Multi-Cloud API secara otomatis mendaftarkan cluster Anda dengan Armada saat cluster dibuat.

Saat membuat cluster, Anda harus menentukan project host Fleet tempat cluster akan dikelola. Karena GKE di Azure menggunakan nama cluster sebagai nama keanggotaan Fleet, Anda harus memastikan bahwa nama cluster Anda bersifat unik di seluruh Armada Anda.

Pendaftaran lintas project

Jika ingin menggunakan project Fleet Host selain project Google Cloud tempat cluster berada, Anda harus menerapkan binding kebijakan IAM tambahan ke akun layanan Agen Layanan Multi-Cloud. Hal ini memungkinkan akun layanan untuk mengelola Fleet dengan Project Fleet Host.

  1. Untuk menambahkan Agen Layanan ke project Anda, jalankan perintah ini:

    gcloud beta services identity create --service=gkemulticloud.googleapis.com \
  --project=CLUSTER_PROJECT_NUMBER

    Ganti CLUSTER_PROJECT_NUMBER dengan nomor project Google Cloud Anda.

  2. Tetapkan binding ini dengan perintah berikut:

    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"

    Ganti kode berikut:

    • FLEET_PROJECT_ID: project Google Cloud project host Fleet Anda
    • CLUSTER_PROJECT_NUMBER: nomor project Google Cloud Anda

Nama akun Agen Layanan Multi-Cloud memiliki format berikut: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

Anda dapat menemukan akun layanan di halaman Service account di Konsol Google Cloud. Untuk mengetahui informasi selengkapnya tentang cara menemukan nomor project, lihat Mengidentifikasi project.

Membuat cluster

Untuk membuat cluster, jalankan perintah berikut:

  1. Simpan grup resource Azure, VNet, dan ID subnet ke variabel lingkungan:

    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)

    Ganti kode berikut:

    • CLUSTER_RESOURCE_GROUP_NAME: nama grup resource yang sudah ada tempat Anda ingin menjalankan cluster
    • VNET_RESOURCE_GROUP_NAME: nama grup resource yang menyimpan VNet Anda
    • VNET_NAME: nama VNet Anda

  2. Buat cluster dengan Google Cloud CLI:

    Workload identity federation

    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_LIST

    Klien Azure

    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

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster Anda
    • GOOGLE_CLOUD_LOCATION: lokasi Google Cloud yang mengelola cluster Anda
    • FLEET_PROJECT dengan project host fleet tempat cluster akan didaftarkan. Jika Anda ingin mengelola cluster ini dari project Google Cloud lain, lihat Pendaftaran lintas project.
    • AZURE_REGION: region Azure yang didukung yang terkait dengan region Google Cloud Anda
    • POD_CIDR: rentang alamat Pod cluster Anda— misalnya, 10.0.1.0/18
    • SERVICE_CIDR: Rentang alamat layanan cluster Anda
    • VM_SIZE: ukuran VM Azure yang didukung
    • ADMIN_USERS_LIST (opsional): daftar alamat email pengguna yang dipisahkan koma untuk memberikan hak istimewa administratif - misalnya, "kai@example.com,hao@example.com,kalani@example.com". Setelan defaultnya adalah pengguna yang membuat cluster
    • CLIENT_NAME: nama AzureClient Anda

  3. Periksa status cluster Anda:

    gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION

    Ganti kode berikut:

    • CLUSTER_NAME
    • GOOGLE_CLOUD_LOCATION

    Outputnya mencakup informasi tentang status dan konfigurasi cluster Anda.

Mengizinkan Cloud Logging / Cloud Monitoring

Agar GKE di Azure dapat membuat serta mengupload log dan metrik sistem ke Google Cloud, GKE harus mendapatkan otorisasi.

Untuk mengizinkan identitas workload Kubernetes gke-system/gke-telemetry-agent guna menulis log ke Google Cloud Logging, dan metrik ke Google Cloud Monitoring, jalankan perintah ini:

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

Ganti GOOGLE_PROJECT_ID dengan project ID Google Cloud cluster.

Binding IAM ini memberikan akses ke semua cluster di project project Google Cloud untuk mengupload log dan metrik. Anda hanya perlu menjalankannya setelah membuat cluster pertama untuk project tersebut.

Penambahan binding IAM ini akan gagal, kecuali jika setidaknya satu cluster telah dibuat di project Google Cloud Anda. Hal ini karena kumpulan workload identity yang dirujuk (GOOGLE_PROJECT_ID.svc.id.goog) tidak disediakan hingga pembuatan cluster.

Membuat node pool

Sebelum membuat kumpulan node, Anda memerlukan hal berikut:

  • Izin untuk menggunakan alat command line az guna mengambil ID subnet Azure.
  • Akses ke kunci publik SSH cluster.

Untuk membuat kumpulan node, jalankan perintah berikut:

  1. Simpan ID subnet Azure VNet dan kunci publik SSH ke variabel lingkungan:

    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)

    Ganti kode berikut:

    • VNET_RESOURCE_GROUP_NAME: nama grup resource yang menyimpan VNet
    • VNET_NAME: nama VNet Anda
    • KEY_PATH: jalur ke pasangan kunci Anda

  2. Buat kumpulan node dengan 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}"

    Ganti kode berikut:

    • NODE_POOL_NAME: nama unik untuk kumpulan node Anda—misalnya, node-pool-1
    • CLUSTER_NAME: nama GKE Anda di cluster Azure
    • GOOGLE_CLOUD_LOCATION: lokasi Google Cloud yang mengelola cluster Anda
    • VM_SIZE: ukuran VM Azure yang didukung
    • MIN_NODES: jumlah minimum node dalam kumpulan node—untuk mengetahui informasi selengkapnya, lihat Penskalaan otomatis cluster
    • MAX_NODES: jumlah maksimum node dalam kumpulan node

  3. Periksa status kumpulan node Anda:

    gcloud container azure node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION

    Ganti kode berikut:

    • NODE_POOL_NAME: nama unik untuk kumpulan node Anda—misalnya, node-pool-1
    • CLUSTER_NAME: nama GKE Anda di cluster Azure
    • GOOGLE_CLOUD_LOCATION: lokasi Google Cloud yang mengelola cluster Anda

    Output-nya mencakup status kumpulan node Anda, termasuk apakah kumpulan node tersebut PROVISIONING atau RUNNING.

Langkah selanjutnya