Membuat cluster

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

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 classless inter-domain routing (CIDR) yang akan diberikan ke cluster Anda.

Penempatan zona bidang kontrol

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

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

Gateway Azure NAT dan bidang kontrol cluster

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

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

Jika Anda ingin menempatkan replika bidang kontrol di satu zona, gunakan satu subnet dan zona. Jika Anda menggunakan Gateway NAT 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 meneruskan dua subnet dan zona, GKE di Azure akan menempatkan dua replika di zona pertama Jika 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 tempat replika bidang kontrol ditempatkan, gunakan flag --replica-placements dan teruskan daftar ID subnet dan zona saat membuat cluster. Anda dapat menggunakan hingga tiga subnet dan zona tempat 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

    Output-nya 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 ID subnet dan zona ketersediaan Azure yang dipisahkan koma, 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 tanda --replica-placements saat Anda membuat cluster.

Memilih rentang CIDR untuk cluster Anda

Saat membuat cluster di GKE di Azure, Anda perlu 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 cara memilih rentang

GKE di Azure menggunakan jaringan overlay untuk Pod dan Service, sehingga rentang IP untuk jaringan ini tidak perlu di-rout 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 menyertakan bidang kontrol atau rentang IP subnet kumpulan node.

  • Rentang IP Pod dan Service harus termasuk 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 gunakan 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 ini adalah konfigurasi yang valid dengan jaringan Pod, Service, dan Node 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 merupakan konfigurasi yang valid meskipun jaringan Pod dan Service 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 Bidang 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 Bidang Kontrol: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Detail tentang rentang alamat Pod

Kubernetes mengalokasikan alamat ke objek Pod dari rentang alamat 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 Anda inginkan dalam cluster dan jumlah Pod yang ingin dijalankan pada setiap node.

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

Tabel rentang alamat pod

Rentang alamat IP pod Alamat IP Pod maksimum Node maksimum Pod maksimum
/24
Rentang alamat Pod 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 IP layanan

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

Untuk menghitung ukuran rentang alamat IP Layanan, Anda perlu memperkirakan jumlah layanan yang Anda inginkan di 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 IP 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

Autentikasi ke Azure

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

Workload identity federation

Dengan penggabungan workload, GKE di Azure dapat melakukan autentikasi ke Azure menggunakan akun layanan Google, sehingga 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 Federasi identitas workload Azure AD 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 perlu menyediakan pasangan kunci SSH. Jika Anda sudah memiliki pasangan kunci untuk 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 Fleet 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 akan otomatis mendaftarkan cluster Anda dengan Fleet saat cluster dibuat.

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

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 Multi-Cloud Service Agent. Tindakan ini memungkinkan akun layanan mengelola Fleet dengan Project Host Fleet.

  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 informasi selengkapnya tentang cara menemukan nomor project Anda, lihat Mengidentifikasi project.

Membuat cluster

Untuk membuat cluster, jalankan perintah berikut:

  1. Simpan grup resource Azure, VNet, dan ID subnet Anda 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.4-gke.200 \
    --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.4-gke.200 \
    --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 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, yang dapat diberikan hak istimewa administratif kepada pengguna, 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

    Output mencakup informasi tentang status dan konfigurasi cluster Anda.

Mengizinkan Cloud Logging / Cloud Monitoring

Izin harus diberikan agar GKE di Azure dapat membuat serta mengupload log dan metrik sistem ke Google Cloud.

Untuk mengizinkan gke-system/gke-telemetry-agent workload Kubernetes 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 ID project Google Cloud cluster.

Binding IAM ini memberikan akses ke semua cluster dalam 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 dalam project Google Cloud Anda. Hal ini karena kumpulan workload identity yang dirujuk (GOOGLE_PROJECT_ID.svc.id.goog) tidak disediakan hingga cluster dibuat.

Membuat node pool

Sebelum membuat kumpulan node, Anda memerlukan hal berikut:

  • Izin untuk menggunakan alat command line az untuk 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 Anda 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

  2. Buat node pool dengan Google Cloud CLI:

    gcloud container azure node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version 1.29.4-gke.200 \
    --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 Penskala 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

    Outputnya mencakup status kumpulan node Anda, termasuk apakah kumpulan node tersebut adalah PROVISIONING atau RUNNING.

Langkah selanjutnya