Opsi peningkatan untuk kluster Azure Kubernetes Service (AKS)

Artikel ini membahas berbagai opsi peningkatan untuk kluster AKS. Untuk melakukan peningkatan versi Kubernetes dasar, lihat Meningkatkan kluster AKS.

Untuk kluster AKS yang menggunakan beberapa kumpulan simpul atau simpul Windows Server, lihat Meningkatkan kumpulan simpul di AKS. Untuk meningkatkan kumpulan simpul tertentu tanpa melakukan peningkatan kluster Kubernetes, lihat Meningkatkan kumpulan simpul tertentu.

Melakukan peningkatan manual

Anda dapat melakukan peningkatan manual untuk mengontrol kapan kluster Anda ditingkatkan ke versi Kubernetes baru. Peningkatan manual berguna ketika Anda ingin menguji versi Kubernetes baru sebelum meningkatkan kluster produksi Anda. Anda juga dapat menggunakan peningkatan manual untuk meningkatkan kluster ke versi Kubernetes tertentu yang bukan versi terbaru yang tersedia.

Untuk melakukan peningkatan manual, lihat artikel berikut ini:

Mengonfigurasi peningkatan otomatis

Anda dapat mengonfigurasi peningkatan otomatis untuk secara otomatis meningkatkan kluster Anda ke versi Kubernetes terbaru yang tersedia. Peningkatan otomatis berguna ketika Anda ingin memastikan kluster Anda selalu menjalankan versi Kubernetes terbaru. Anda juga dapat menggunakan peningkatan otomatis untuk memastikan kluster Anda selalu menjalankan versi Kubernetes yang didukung.

Untuk mengonfigurasi peningkatan otomatis, lihat artikel berikut ini:

Pertimbangan khusus untuk kumpulan simpul yang mencakup beberapa zona ketersediaan

AKS menggunakan penyeimbangan zona upaya terbaik dalam grup node. Selama lonjakan peningkatan, zona untuk simpul lonjakan di Virtual Machine Scale Sets tidak diketahui sebelumnya, yang sementara dapat menyebabkan konfigurasi zona yang tidak seimbang selama peningkatan. Namun, AKS menghapus simpul lonjakan setelah peningkatan selesai dan mempertahankan keseimbangan zona asli. Jika Anda ingin menjaga zona Anda tetap seimbang selama peningkatan, Anda dapat meningkatkan lonjakan ke beberapa tiga simpul, dan Virtual Machine Scale Sets menyeimbangkan simpul Anda di seluruh zona ketersediaan dengan penyeimbangan zona upaya terbaik. Dengan keseimbangan zona upaya terbaik, skala yang ditetapkan mencoba untuk menyesuaikan skala sambil menjaga keseimbangan. Namun, jika karena alasan tertentu ini tidak dimungkinkan (misalnya, jika satu zona turun, set skala tidak dapat membuat VM baru di zona tersebut), set skala memungkinkan ketidakseimbangan sementara untuk berhasil menskalakan masuk atau keluar.

Klaim volume persisten (PVC) yang didukung oleh Disk penyimpanan redundan lokal Azure (LRS) terikat ke zona tertentu dan mungkin gagal segera pulih jika simpul lonjakan tidak cocok dengan zona PVC. Jika zona tidak cocok, itu dapat menyebabkan waktu henti pada aplikasi Anda ketika operasi peningkatan terus menguras simpul tetapi PV terikat ke zona. Untuk menangani kasus ini dan menjaga ketersediaan tinggi, konfigurasikan Anggaran Gangguan Pod pada aplikasi Anda untuk memungkinkan Kubernetes mematuhi persyaratan ketersediaan Anda selama operasi pengurasan.

Optimalkan peningkatan untuk meningkatkan performa dan meminimalkan gangguan

Kombinasi Jendela Pemeliharaan Terencana, Lonjakan Maks, Anggaran Gangguan Pod, batas waktu pengosongan simpul, dan waktu rendam simpul (pratinjau) dapat secara signifikan meningkatkan kemungkinan peningkatan node berhasil diselesaikan pada akhir jendela pemeliharaan sambil juga meminimalkan gangguan.

  • Jendela Pemeliharaan Terencana memungkinkan tim layanan untuk menjadwalkan peningkatan otomatis selama jendela yang telah ditentukan sebelumnya, biasanya periode lalu lintas rendah, untuk meminimalkan dampak beban kerja. Kami merekomendasikan durasi jendela setidaknya empat jam.

  • Lonjakan Maks pada kumpulan simpul memungkinkan permintaan kuota tambahan selama proses peningkatan dan membatasi jumlah simpul yang dipilih untuk peningkatan secara bersamaan. Lonjakan maks yang lebih tinggi menghasilkan proses peningkatan yang lebih cepat. Kami tidak merekomendasikan pengaturan pada 100%, karena meningkatkan semua simpul secara bersamaan, yang dapat menyebabkan gangguan pada aplikasi yang berjalan. Kami merekomendasikan kuota lonjakan maksimum 33% untuk kumpulan simpul produksi.

  • Anggaran Gangguan Pod diatur untuk aplikasi layanan dan membatasi jumlah pod yang dapat diturunkan selama gangguan sukarela, seperti peningkatan simpul yang dikontrol AKS. Ini dapat dikonfigurasi sebagai minAvailable replika, menunjukkan jumlah minimum pod aplikasi yang perlu aktif, atau maxUnavailable replika, menunjukkan jumlah maksimum pod aplikasi yang dapat dihentikan, memastikan ketersediaan tinggi untuk aplikasi. Lihat panduan yang diberikan untuk mengonfigurasi Anggaran Gangguan Pod (PDB). Nilai PDB harus divalidasi untuk menentukan pengaturan yang paling sesuai untuk layanan spesifik Anda.

  • Batas waktu pengosongan node pada kumpulan simpul memungkinkan Anda untuk mengonfigurasi durasi tunggu untuk pengeluaran Pod dan penghentian yang anggun per simpul selama peningkatan. Opsi ini berguna saat berhadapan dengan beban kerja yang berjalan lama. Ketika batas waktu pengurasan simpul ditentukan (dalam menit), AKS menghormati menunggu anggaran gangguan pod. Jika tidak ditentukan, batas waktu default adalah 30 menit.

  • Waktu rendam simpul (pratinjau) membantu peningkatan simpul yang mengejutkan dengan cara yang terkontrol dan dapat meminimalkan waktu henti aplikasi selama peningkatan. Anda dapat menentukan waktu tunggu, sebaiknya mendekati 0 menit secara wajar, untuk memeriksa kesiapan aplikasi di antara peningkatan simpul. Jika tidak ditentukan, nilai defaultnya adalah 0 menit. Waktu berendam simpul bekerja sama dengan properti batas waktu pengurasan dan pengurasan simpul maksimum yang tersedia di kumpulan simpul untuk memberikan hasil yang tepat dalam hal kecepatan peningkatan dan ketersediaan aplikasi.

    Catatan

    Untuk menggunakan durasi rendam simpul (pratinjau), Anda harus menginstal aks-preview ekstensi Azure CLI versi 0.5.173 atau yang lebih baru.

Langkah berikutnya

Artikel ini mencantumkan opsi peningkatan yang berbeda untuk kluster AKS. Untuk diskusi terperinci tentang praktik terbaik peningkatan dan pertimbangan lainnya, lihat panduan patch dan peningkatan AKS.