Zona ketersediaan di Azure Kubernetes Service (AKS)

Artikel
02/04/2025

Zona ketersediaan membantu melindungi aplikasi dan data Anda dari kegagalan pusat data. Zona ketersediaan adalah lokasi fisik unik yang berada dalam wilayah Azure. Setiap zona mencakup satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan independen.

Menggunakan AKS dengan zona ketersediaan secara fisik mendistribusikan sumber daya di berbagai zona ketersediaan dalam satu wilayah, meningkatkan keandalan. Menyebarkan simpul di beberapa zona tidak dikenakan biaya tambahan.

Artikel ini memperlihatkan kepada Anda cara mengonfigurasi sumber daya AKS untuk menggunakan Zona Ketersediaan.

Sumber daya AKS

Diagram ini memperlihatkan sumber daya Azure yang dibuat saat Anda membuat kluster AKS:

Sarana Kontrol AKS

Microsoft menghosting sarana kontrol AKS, server API Kubernetes, dan layanan seperti scheduler dan etcd sebagai layanan terkelola. Microsoft mereplikasi sarana kontrol di beberapa zona.

Sumber daya lain dari penyebaran kluster Anda dalam grup sumber daya terkelola di langganan Azure Anda. Secara default, grup sumber daya ini diawali dengan MC_, untuk Kluster Terkelola dan berisi sumber daya berikut:

Kumpulan simpul

Kumpulan simpul dibuat sebagai Set Skala Komputer Virtual di Langganan Azure Anda.

Saat Anda membuat kluster AKS, satu kumpulan Simpul Sistem diperlukan dan dibuat secara otomatis. Ini menghosting pod sistem penting seperti CoreDNS dan metrics-server. Lebih banyak kumpulan Simpul Pengguna dapat ditambahkan ke kluster AKS Anda untuk menghosting aplikasi Anda.

Ada tiga cara kumpulan simpul dapat disebarkan:

Rentang zona
Zona diratakan
Wilayah

Untuk kumpulan simpul sistem, jumlah zona yang digunakan dikonfigurasi saat kluster dibuat.

Rentang zona

Zona yang mencakup set skala menyebarkan simpul di semua zona yang dipilih, dengan menentukan zona ini dengan --zones parameter .

# Create an AKS Cluster, and create a zone spanning System Nodepool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1, 2, 3
# Add one new zone spanning User Nodepool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1, 2, 3

AKS menyeimbangkan jumlah simpul antar zona secara otomatis.

Jika pemadaman zona terjadi, simpul dalam zona yang terkena dampak dapat terpengaruh, sementara simpul di zona ketersediaan lain tetap tidak terpengaruh.

Zona diratakan

Setiap simpul diselaraskan (disematkan) ke zona tertentu. Untuk membuat tiga kumpulan simpul untuk suatu wilayah dengan tiga Zona Ketersediaan:

# # Add three new zone aligned User Nodepools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

Konfigurasi ini dapat digunakan ketika Anda membutuhkan latensi yang lebih rendah antar simpul. Ini juga memberikan kontrol yang lebih terperinci atas operasi penskalakan, atau saat menggunakan autoscaler kluster.

Catatan

Jika satu beban kerja disebarkan di seluruh kumpulan simpul, sebaiknya atur --balance-similar-node-groups untuk true mempertahankan distribusi simpul yang seimbang di seluruh zona untuk beban kerja Anda selama operasi peningkatan skala.

Regional (tidak menggunakan Zona Ketersediaan)

Mode regional digunakan saat penetapan zona tidak diatur dalam templat penyebaran ("zones"=[] or "zones"=null).

Dalam konfigurasi ini, kumpulan simpul membuat instans Regional (bukan zona yang disematkan) dan secara implisit menempatkan instans di seluruh wilayah. Tidak ada jaminan untuk keseimbangan atau tersebar di seluruh zona, atau instans tersebut mendarat di zona ketersediaan yang sama.

Dalam kasus pemadaman zona penuh yang jarang terjadi, salah satu atau semua instans dalam kumpulan simpul dapat terpengaruh.

Untuk memvalidasi lokasi simpul, jalankan perintah berikut:

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

Penyebaran

Pod

Kubernetes mengetahui Zona Ketersediaan Azure, dan dapat menyeimbangkan pod di seluruh simpul di zona yang berbeda. Jika suatu zona menjadi tidak tersedia, Kubernetes memindahkan pod dari simpul yang terkena dampak secara otomatis.

Seperti yang didokumentasikan dalam Label, Anotasi dan Taint Umum, Kube menggunakan label topology.kubernetes.io/zone untuk secara otomatis mendistribusikan pod dalam kontroler replikasi atau layanan di berbagai zona yang tersedia.

Untuk melihat simpul pod mana yang berjalan, jalankan perintah berikut:

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

Parameter 'maxSkew' menjelaskan tingkat di mana Pod mungkin didistribusikan secara tidak merata. Dengan asumsi tiga zona dan tiga replika, mengatur nilai ini ke 1 memastikan setiap zona memiliki setidaknya satu pod yang berjalan:

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  replicas: 3
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Penyimpanan dan volume

Secara default, Kubernetes versi 1.29 dan yang lebih baru menggunakan Azure Managed Disks menggunakan Zone-Redundant-Storage (ZRS) untuk klaim volume persisten.

Disk ini direplikasi antar zona, untuk meningkatkan ketahanan aplikasi Anda, dan melindungi data Anda dari kegagalan pusat data.

Contoh klaim volume persisten yang menggunakan SSD Standar di ZRS:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

Untuk penyebaran yang selaras dengan zona, Anda dapat membuat kelas penyimpanan baru dengan parameter yang skuname diatur ke LRS (Penyimpanan Redundan Lokal). Anda kemudian dapat menggunakan kelas penyimpanan baru di Klaim Volume Persisten (PVC).

Meskipun disk LRS lebih murah, disk tersebut tidak berlebihan di zona, dan melampirkan disk ke node di zona lain tidak didukung.

Contoh kelas penyimpanan SSD Standar LRS:

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

load balancer

Kubernetes menyebarkan Azure Standard Load Balancer secara default, yang menyeimbangkan lalu lintas masuk di semua zona di suatu wilayah. Jika node menjadi tidak tersedia, load balancer akan mengalihkan lalu lintas ke simpul yang sehat.

Contoh Layanan yang menggunakan Azure Load Balancer:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

Penting

Pada 30 September 2025, Load Balancer Dasar akan dihentikan. Untuk informasi selengkapnya, lihat pengumuman resmi. Jika saat ini Anda menggunakan Load Balancer Dasar, pastikan untuk meningkatkan ke Load Balancer Standar sebelum tanggal penghentian.

Batasan

Batasan berikut berlaku saat menggunakan Zona Ketersediaan:

Lihat Kuota, pembatasan ukuran Komputer Virtual, dan ketersediaan wilayah di AKS.
Jumlah Zona Ketersediaan yang digunakan tidak dapat diubah setelah kumpulan simpul dibuat.
Sebagian besar wilayah mendukung Zona Ketersediaan. Daftar dapat ditemukan di sini.

Langkah berikutnya

Pelajari tentang kumpulan Simpul Sistem
Pelajari tentang kumpulan Simpul Pengguna
Pelajari tentang Load Balancer
Praktik terbaik untuk kelangsungan bisnis AKS dan pemulihan dari bencana

Bagikan melalui