Bagikan melalui

Opsi dan rekomendasi peningkatan untuk kluster Azure Kubernetes Service (AKS)

Artikel ini membahas opsi peningkatan untuk kluster AKS dan memberikan rekomendasi berbasis skenario untuk tantangan peningkatan umum.

Pilihan upgrade

Melakukan peningkatan manual

Peningkatan manual memungkinkan Anda mengontrol kapan kluster ditingkatkan ke versi Kubernetes baru. Berguna untuk menguji atau menargetkan versi tertentu.

Mengonfigurasi peningkatan otomatis

Peningkatan otomatis menjaga kluster Anda tetap pada versi yang didukung dan terbarui. Ini adalah ketika Anda ingin mengatur dan melupakan.

Pertimbangan khusus untuk kumpulan simpul yang mencakup beberapa zona ketersediaan

AKS menggunakan penyeimbangan zona upaya terbaik dalam grup node. Selama peningkatan yang mendadak, zona untuk simpul peningkatan di Virtual Machine Scale Sets belum diketahui sebelumnya, yang dapat menyebabkan konfigurasi zona sementara menjadi tidak seimbang. AKS menghapus simpul lonjakan setelah peningkatan dan memulihkan keseimbangan zona asli. Untuk menjaga zona tetap seimbang, atur peningkatan kapasitas sesuai kelipatan dari tiga node. PVC yang menggunakan disk Azure LRS terikat pada zona dan dapat menyebabkan waktu henti jika simpul lonjakan berada di zona berbeda. Gunakan Anggaran Gangguan Pod untuk menjaga ketersediaan tinggi selama pembuangan.

Optimalkan peningkatan untuk meningkatkan performa dan meminimalkan gangguan

Gabungkan Jendela Pemeliharaan Terencana, Lonjakan Maks, Anggaran Gangguan Pod, batas waktu pengurasan simpul, dan waktu rendam simpul untuk meningkatkan kemungkinan peningkatan yang berhasil dengan gangguan yang minim.

Pengaturan pemutakhiran Bagaimana simpul tambahan digunakan Perilaku yang diharapkan
maxSurge=5, maxUnavailable=0 5 simpul lonjakan 5 simpul melonjak untuk peningkatan
maxSurge=5, maxUnavailable=0 0-4 node lonjakan Peningkatan gagal karena node tambahan yang tidak mencukupi
maxSurge=0, maxUnavailable=5 Tidak tersedia 5 simpul yang ada dikosongkan untuk peningkatan

Nota

Sebelum meningkatkan, periksa perubahan API yang mengganggu dan tinjau catatan rilis AKS untuk menghindari gangguan.

Validasi yang digunakan dalam proses peningkatan

AKS melakukan validasi pra-peningkatan untuk memastikan kesehatan kluster:

  • Perubahan mendasar pada API: Mendeteksi API yang kadaluarsa.
  • Versi peningkatan Kubernetes: Memastikan jalur peningkatan yang valid.
  • Konfigurasi PDB: Memeriksa PDB yang salah dikonfigurasi (misalnya, maxUnavailable=0).
  • Kuota: Mengonfirmasi kuota yang cukup untuk node lonjakan.
  • Subnet: Memverifikasi alamat IP yang memadai.
  • Sertifikat/Perwakilan Layanan: Mendeteksi kredensial yang kedaluwarsa.

Pemeriksaan ini membantu meminimalkan kegagalan peningkatan dan memberikan visibilitas awal ke dalam masalah.

Skenario dan rekomendasi peningkatan umum

Skenario 1: Batasan kapasitas

Jika kluster Anda dibatasi oleh SKU atau kapasitas regional, peningkatan mungkin gagal ketika node tambahan tidak dapat disediakan. Ini umum dengan SKU khusus (seperti simpul GPU) atau di wilayah dengan sumber daya terbatas. Kesalahan seperti SKUNotAvailable, , AllocationFailedatau OverconstrainedAllocationRequest mungkin terjadi jika maxSurge diatur terlalu tinggi untuk kapasitas yang tersedia.

Rekomendasi untuk mencegah atau mengatasinya

  • Gunakan maxUnavailable untuk melakukan peningkatan menggunakan simpul yang ada alih-alih menambah simpul baru. Pelajari selengkapnya.
  • Turunkan maxSurge untuk mengurangi kebutuhan kapasitas tambahan. Pelajari selengkapnya.
  • Untuk pembaruan yang hanya untuk keamanan, gunakan gambar ulang patch keamanan yang tidak memerlukan node tambahan. Pelajari selengkapnya.

Skenario 2: Kegagalan pengurasan node dan PDB

Peningkatan memerlukan pengosongan simpul (memindahkan pod). Saluran air dapat gagal jika:

Contoh pesan kesalahan:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This is often caused by a restrictive Pod Disruption Budget (PDB) policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

Rekomendasi untuk mencegah atau mengatasinya

  • Konfigurasikan maxUnavailable dalam PDB untuk mengizinkan setidaknya satu pod ditendang.
  • Tingkatkan replika pod agar batas gangguan dapat mentolerir pemindahan.
  • Gunakan undrainableNodeBehavior untuk memungkinkan peningkatan dilanjutkan meskipun beberapa simpul tidak dapat dikosongkan:
    • Jadwal (Default): Penggantian node dan lonjakan mungkin dihapus, sehingga mengurangi kapasitas.
    • Cordon (Disarankan): Node berkode dan diberi label sebagai kubernetes.azure.com/upgrade-status=Quarantined.

      • Contoh perintah:

        az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon

        Contoh output berikut menunjukkan perilaku simpul yang tidak dapat dikeringkan yang telah diperbarui:

        "upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}

Simpul Maksimum yang Diblokir Diizinkan (Pratinjau)

  • [Pratinjau] Fitur Max Blocked Node Allowed memungkinkan Anda menentukan berapa banyak simpul yang gagal dikosongkan (node yang diblokir) dapat ditoleransi selama peningkatan atau operasi serupa. Fitur ini hanya berfungsi jika properti perilaku simpul yang tidak dapat dibatalkan diatur; jika tidak, perintah akan mengembalikan kesalahan.

Nota

Jika Anda tidak secara eksplisit mengatur Jumlah Maksimum Node Terblokir yang Diizinkan, maka secara default akan menggunakan nilai Lonjakan Maks. Jika Max Surge tidak diatur, defaultnya biasanya 10%, sehingga Max Blocked Nodes Allowed juga bernilai default 10%.

Prasyarat

  • Ekstensi Azure CLI aks-preview versi 18.0.0b9 atau yang lebih baru diperlukan untuk menggunakan fitur ini.

    Contoh perintah:

    az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5
  • Perpanjang waktu habis penyelesaian jika beban kerja membutuhkan lebih banyak waktu (pengaturan awal adalah 30 menit).
  • Uji PDB dalam penahapan, pantau peristiwa peningkatan, dan gunakan penyebaran biru-hijau untuk beban kerja penting. Pelajari selengkapnya.

Memverifikasi simpul yang tidak dapat dibatalkan

  • Simpul yang diblokir tidak dijadwalkan untuk pod dan ditandai dengan label "kubernetes.azure.com/upgrade-status: Quarantined".

  • Verifikasi label pada node yang diblokir ketika ada kegagalan simpul pengurasan saat peningkatan:

    kubectl get nodes --show-labels=true

Menyelesaikan simpul yang tidak dapat dikosongkan

  1. Hapus PDB yang bertanggung jawab:

    kubectl delete pdb <pdb-name>

  2. Hapus label kubernetes.azure.com/upgrade-status: Quarantined.

    kubectl label nodes <node-name> <label-name>

  3. Secara opsional, hapus node yang diblokir:

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

  4. Setelah menyelesaikan langkah ini, Anda dapat mendamaikan status kluster dengan melakukan operasi pembaruan apa pun tanpa bidang opsional seperti yang diuraikan di sini. Atau, Anda dapat menyesuaikan skala kumpulan node ke jumlah node yang sama dengan jumlah node yang ditingkatkan. Tindakan ini memastikan node pool mencapai ukuran yang diinginkan semula. AKS memprioritaskan penghapusan simpul yang diblokir. Perintah ini juga memulihkan status provisi kluster ke Succeeded. Dalam contoh yang diberikan, 2 adalah jumlah total node yang ditingkatkan.

    # Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2

Skenario 3: Peningkatan lambat

Peningkatan dapat ditunda oleh pengaturan konservatif atau masalah tingkat node, yang memengaruhi kemampuan Anda untuk tetap terkini dengan patch dan peningkatan.

Penyebab umum peningkatan lambat meliputi:

  • Rendah maxSurge atau maxUnavailable nilai (membatasi paralelisme).
  • Waktu tunggu lama (menunggu lama di antara peningkatan node).
  • Masalah pengeringan (lihat Kegagalan pengeringan node]).

Rekomendasi untuk mencegah atau mengatasinya

  • Untuk produksi: maxSurge=33%, maxUnavailable=1.
  • Untuk dev/test: maxSurge=50%, maxUnavailable=2.
  • Gunakan Patch Keamanan OS untuk patching yang cepat dan ditargetkan (menghindari pencitraan ulang simpul penuh).
  • Aktifkan undrainableNodeBehavior untuk menghindari pemblokir peningkatan.

Skenario 4: Kelelahan IP

Simpul lalu lintas memerlukan IP tambahan. Jika subnet mendekati kapasitas, provisi node dapat gagal (misalnya, Error: SubnetIsFull). Ini umum dengan Azure CNI, jumlah simpul tinggi maxPods, atau besar.

Rekomendasi untuk mencegah atau mengatasinya

  • Pastikan subnet Anda memiliki jumlah IP yang cukup untuk semua node, node tambahan, dan pod.

    • Rumus: Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)

  • Klaim kembali IP yang tidak digunakan atau perluas subnet (misalnya, dari /24 ke /22).

  • Turunkan maxSurge jika ekspansi subnet tidak memungkinkan.

    az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

  • Pantau penggunaan IP dengan Azure Monitor atau pemberitahuan kustom.

  • Kurangi maxPods untuk setiap simpul, bersihkan IP penyeimbang beban yang sudah tidak terpakai, dan rencanakan ukuran subnet untuk kluster dengan skala tinggi.

Langkah berikutnya

  • Tinjau panduan patch dan peningkatan AKS untuk praktik terbaik dan tips perencanaan sebelum memulai peningkatan apa pun.
  • Selalu periksa perubahan pemecahan API dan validasi kompatibilitas beban kerja Anda dengan versi Kubernetes target.
  • Menguji pengaturan peningkatan (seperti maxSurge, maxUnavailable, dan PDB) di lingkungan penahapan untuk meminimalkan risiko produksi.
  • Pantau peristiwa peningkatan dan kesehatan kluster selama proses.