Zona ketersediaan di Azure Kubernetes Service (AKS)

2025-05-09

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

Menggunakan Azure Kubernetes Service (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:

Komponen kontrol AKS

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

Sumber daya lain dari kluster Anda dikelola dalam grup sumber daya yang sudah ada di langganan Azure Anda. Secara default, grup sumber daya ini diawali dengan MC_ untuk kluster terkelola dan berisi sumber daya yang disebutkan di bagian 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 menampung pod sistem penting seperti CoreDNS dan metrics-server. Anda dapat menambahkan lebih banyak kumpulan simpul pengguna ke kluster AKS Anda untuk menghosting aplikasi Anda.

Ada tiga cara kumpulan simpul dapat disebarkan:

Rentang zona
Rata zona
Wilayah

Zona kumpulan node sistem dikonfigurasi saat kluster atau kumpulan node dibuat.

Rentang zona

Dalam konfigurasi ini, simpul tersebar di semua zona yang dipilih. Zona ini ditentukan dengan menggunakan --zones parameter .

# Create an AKS cluster, and create a zone-spanning system node pool 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 node pool, 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 secara otomatis menyeimbangkan jumlah simpul antar zona.

Jika pemadaman zona terjadi, simpul dalam zona yang terpengaruh mungkin terpengaruh, tetapi simpul di zona ketersediaan lain tetap tidak terpengaruh.

Untuk memvalidasi lokasi simpul, jalankan perintah berikut:

kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.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

Rata zona

Dalam konfigurasi ini, 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 node pools, 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 penskalaan, atau ketika Anda menggunakan pengubah skala otomatis kluster.

Nota

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 (misalnya, "zones"=[] atau "zones"=null).

Dalam konfigurasi ini, kumpulan simpul membuat instans regional (tidak terkait zona) dan secara otomatis menyebar instans di seluruh wilayah. Tidak ada jaminan bahwa instans tersebut memiliki keseimbangan atau tersebar di seluruh zona, maupun bahwa instans berada di zona ketersediaan yang sama.

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

Untuk memvalidasi lokasi simpul, jalankan perintah berikut:

kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.topology\.kubernetes\.io/zone'

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   0
aks-nodepool1-34917322-vmss000001   eastus   0
aks-nodepool1-34917322-vmss000002   eastus   0

Penyebaran

Kapsul

Kubernetes mengetahui zona ketersediaan Azure, dan dapat menyeimbangkan pod di seluruh node di zona yang berbeda. Jika suatu zona menjadi tidak tersedia, Kubernetes memindahkan pod dari simpul yang terpengaruh secara otomatis.

Seperti yang didokumentasikan dalam referensi Kubernetes Well-Known Label, Anotasi, dan Taint, Kubernetes menggunakan label untuk secara otomatis mendistribusikan topology.kubernetes.io/zone pod dalam pengontrol replikasi atau layanan di berbagai zona yang tersedia.

Untuk melihat pod dan node 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, atur nilai ini untuk 1 memastikan bahwa setiap zona memiliki setidaknya satu pod yang berjalan:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app
      containers:
      - name: my-container
        image: my-image

Penyimpanan dan volume

Secara default, Kubernetes versi 1.29 dan yang lebih baru menggunakan Disk Terkelola Azure dengan menggunakan penyimpanan redundan zona untuk Klaim Volume Persisten.

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

Contoh berikut menunjukkan Klaim Volume Persisten yang menggunakan Azure Standard SSD dalam penyimpanan redundansi zona:

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 Anda.

Meskipun disk penyimpanan yang redundan secara lokal lebih murah, disk tersebut tidak redundan secara zona, dan melampirkan disk ke node di zona lain tidak didukung.

Contoh berikut menunjukkan kelas penyimpanan SSD Standar redundan secara lokal:

kind: StorageClass

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

Penyeimbang beban

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, Basic Load Balancer akan dihentikan. Untuk informasi selengkapnya, lihat pengumuman resmi. Jika Anda menggunakan Load Balancer Dasar, pastikan untuk meningkatkan ke Load Balancer Standar sebelum tanggal penghentian.

Keterbatasan

Batasan berikut berlaku saat Anda 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. Lihat daftar wilayah.

Pelajari tentang kumpulan simpul sistem.
Pelajari tentang kumpulan simpul pengguna.
Pelajari tentang load balancer.
Dapatkan praktik terbaik untuk kelangsungan bisnis dan pemulihan bencana di AKS.