Praktik terbaik untuk performa dan penskalaan untuk beban kerja besar di Azure Kubernetes Service (AKS)

Catatan

Artikel ini berfokus pada praktik terbaik umum untuk beban kerja besar. Untuk praktik terbaik khusus untuk beban kerja kecil hingga menengah, lihat Praktik terbaik performa dan penskalaan untuk beban kerja kecil hingga menengah di Azure Kubernetes Service (AKS).

Saat Anda menyebarkan dan memelihara kluster di AKS, Anda dapat menggunakan praktik terbaik berikut untuk membantu Anda mengoptimalkan performa dan penskalakan.

Perlu diingat bahwa besar adalah istilah relatif. Kubernetes memiliki amplop skala multi-dimensi, dan amplop skala untuk beban kerja Anda tergantung pada sumber daya yang Anda gunakan. Misalnya, kluster dengan 100 simpul dan ribuan pod atau CRD mungkin dianggap besar. Kluster simpul 1.000 dengan 1.000 pod dan berbagai sumber daya lainnya mungkin dianggap kecil dari perspektif sarana kontrol. Sinyal terbaik untuk skala sarana kontrol Kubernetes adalah tingkat keberhasilan permintaan HTTP server API dan latensi, karena itu adalah proksi untuk jumlah beban pada sarana kontrol.

Dalam artikel ini, Anda mempelajari tentang:

• Skalabilitas sarana kontrol AKS dan Kubernetes.
• Praktik terbaik Klien Kubernetes, termasuk backoff, jam tangan, dan paginasi.
• Azure API dan batas pembatasan platform.
• Batasan fitur.
• Praktik terbaik penskalakan jaringan dan kumpulan simpul.

Skalabilitas sarana kontrol AKS dan Kubernetes

Dalam AKS, kluster terdiri dari satu set simpul (komputer virtual atau fisik (VM)) yang menjalankan agen Kubernetes dan dikelola oleh sarana kontrol Kubernetes yang dihosting oleh AKS. Meskipun AKS mengoptimalkan sarana kontrol Kube dan komponennya untuk skalabilitas dan performa, AKS masih terikat oleh batas proyek hulu.

Kubernetes memiliki amplop skala multi-dimensi dengan setiap jenis sumber daya yang mewakili dimensi. Tidak semua sumber daya sama. Misalnya, jam tangan biasanya diatur pada rahasia, yang mengakibatkan panggilan daftar ke kube-apiserver yang menambahkan biaya dan beban yang tidak proporsional lebih tinggi pada sarana kontrol dibandingkan dengan sumber daya tanpa jam tangan.

Sarana kontrol mengelola semua penskalakan sumber daya dalam kluster, sehingga semakin banyak Anda menskalakan kluster dalam dimensi tertentu, semakin sedikit Anda dapat menskalakan dalam dimensi lain. Misalnya, menjalankan ratusan ribu pod dalam kluster AKS memengaruhi berapa banyak tingkat churn pod (mutasi pod per detik) yang dapat didukung oleh sarana kontrol.

Ukuran amplop sebanding dengan ukuran sarana kontrol Kubernetes. AKS mendukung tiga tingkat sarana kontrol sebagai bagian dari SKU Dasar: Tingkat Gratis, Standar, dan Premium. Untuk informasi selengkapnya, lihat Tingkat harga Gratis, Standar, dan Premium untuk manajemen kluster AKS.

Penting

Sebaiknya gunakan tingkat Standar atau Premium untuk beban kerja produksi atau dalam skala besar. AKS secara otomatis meningkatkan sarana kontrol Kubernetes untuk mendukung batas skala berikut:

• Hingga 5.000 simpul per kluster AKS
• 200.000 pod per kluster AKS (dengan Azure CNI Overlay)

Dalam kebanyakan kasus, melewati ambang batas skala mengakibatkan penurunan performa, tetapi tidak menyebabkan kluster segera gagal. Untuk mengelola beban pada sarana kontrol Kube, pertimbangkan untuk menskalakan dalam batch hingga 10-20% dari skala saat ini. Misalnya, untuk kluster simpul 5.000, skalakan kenaikan 500-1.000 simpul. Meskipun AKS melakukan autoscale sarana kontrol Anda, AKS tidak terjadi secara instan.

Anda dapat memanfaatkan API Priority and Fairness (APF) untuk membatasi klien tertentu dan jenis permintaan untuk melindungi sarana kontrol selama churn dan beban tinggi.

Klien Kubernetes

Klien Kubernetes adalah klien aplikasi, seperti operator atau agen pemantauan, yang disebarkan di kluster Kubernetes yang perlu berkomunikasi dengan server kube-api untuk melakukan operasi baca atau mutasi. Penting untuk mengoptimalkan perilaku klien ini untuk meminimalkan beban yang mereka tambahkan ke server kube-api dan sarana kontrol Kubernetes.

Anda dapat menganalisis lalu lintas server API dan perilaku klien melalui log Audit Kube. Untuk informasi selengkapnya, lihat Memecahkan masalah sarana kontrol Kubernetes.

Permintaan LIST bisa mahal. Saat bekerja dengan daftar yang mungkin memiliki lebih dari beberapa ribu objek kecil atau lebih dari beberapa ratus objek besar, Anda harus mempertimbangkan panduan berikut:

• Pertimbangkan jumlah objek (CR) yang Anda harapkan pada akhirnya ada saat menentukan jenis sumber daya baru (CRD).
• Beban pada server etcd dan API terutama bergantung pada jumlah objek yang ada, bukan jumlah objek yang dikembalikan. Bahkan jika Anda menggunakan pemilih bidang untuk memfilter daftar dan hanya mengambil sejumlah kecil hasil, panduan ini masih berlaku. Satu-satunya pengecualian adalah pengambilan satu objek dengan metadata.name.
• Hindari panggilan LIST berulang jika memungkinkan jika kode Anda perlu mempertahankan daftar objek yang diperbarui dalam memori. Sebagai gantinya, pertimbangkan untuk menggunakan kelas Informer yang disediakan di sebagian besar pustaka Kubernetes. Informan secara otomatis menggabungkan fungsionalitas LIST dan WATCH untuk mempertahankan koleksi dalam memori secara efisien.
• Pertimbangkan apakah Anda membutuhkan konsistensi yang kuat jika Informan tidak memenuhi kebutuhan Anda. Apakah Anda perlu melihat data terbaru, hingga saat yang tepat pada waktu Anda mengeluarkan kueri? Jika tidak, atur ResourceVersion=0. Ini menyebabkan cache server API melayani permintaan Anda alih-alih etcd.
• Jika Anda tidak dapat menggunakan Informer atau cache server API, baca daftar besar dalam gugus.
• Hindari mencantumkan lebih sering daripada yang diperlukan. Jika Anda tidak dapat menggunakan Informer, pertimbangkan seberapa sering aplikasi Anda mencantumkan sumber daya. Setelah Anda membaca objek terakhir dalam daftar besar, jangan langsung mengkueri ulang daftar yang sama. Anda harus menunggu sebentar sebagai gantinya.
• Pertimbangkan jumlah instans aplikasi klien Anda yang sedang berjalan. Ada perbedaan besar antara memiliki satu objek daftar pengontrol vs. memiliki pod pada setiap simpul yang melakukan hal yang sama. Jika Anda berencana untuk memiliki beberapa instans aplikasi klien Anda secara berkala mencantumkan sejumlah besar objek, solusi Anda tidak akan diskalakan ke kluster besar.

Pembatasan Azure API dan Platform

Beban pada aplikasi cloud dapat bervariasi dari waktu ke waktu berdasarkan faktor-faktor seperti jumlah pengguna aktif atau jenis tindakan yang dilakukan pengguna. Jika persyaratan pemrosesan sistem melebihi kapasitas sumber daya yang tersedia, sistem dapat menjadi kelebihan beban dan menderita performa dan kegagalan yang buruk.

Untuk menangani berbagai ukuran beban dalam aplikasi cloud, Anda dapat mengizinkan aplikasi untuk menggunakan sumber daya hingga batas yang ditentukan lalu membatasinya saat batas tercapai. Di Azure, pembatasan terjadi pada dua tingkat. Azure Resource Manager (ARM) membatasi permintaan untuk langganan dan penyewa. Jika permintaan berada di bawah batas pembatasan untuk langganan dan penyewa, ARM merutekan permintaan ke penyedia sumber daya. Penyedia sumber daya kemudian menerapkan batas pembatasan yang disesuaikan dengan operasinya. Untuk informasi selengkapnya, lihat Permintaan pembatasan ARM.

Mengelola pembatasan di AKS

Batas Azure API biasanya ditentukan pada tingkat kombinasi wilayah langganan. Misalnya, semua klien dalam langganan di wilayah tertentu berbagi batas API untuk Api Azure tertentu, seperti API PUT Set Skala Komputer Virtual. Setiap kluster AKS memiliki beberapa klien milik AKS, seperti penyedia cloud atau autoscaler kluster, atau klien milik pelanggan, seperti Datadog atau Prometheus yang dihost sendiri, yang memanggil API Azure. Saat menjalankan beberapa kluster AKS dalam langganan dalam wilayah tertentu, semua klien milik AKS dan milik pelanggan dalam kluster berbagi serangkaian batas API umum. Oleh karena itu, jumlah kluster yang dapat Anda sebarkan di wilayah langganan adalah fungsi dari jumlah klien yang disebarkan, pola panggilan mereka, dan skala keseluruhan dan elastisitas kluster.

Mengingat pertimbangan di atas, pelanggan biasanya dapat menyebarkan antara 20-40 kluster skala kecil hingga menengah per wilayah langganan. Anda dapat memaksimalkan skala langganan menggunakan praktik terbaik berikut:

Selalu tingkatkan kluster Kubernetes Anda ke versi terbaru. Versi yang lebih baru berisi banyak peningkatan yang mengatasi masalah performa dan pembatasan. Jika Anda menggunakan versi Kubernetes yang ditingkatkan dan masih melihat pembatasan karena beban aktual atau jumlah klien dalam langganan, Anda dapat mencoba opsi berikut:

• Menganalisis kesalahan menggunakan AKS Mendiagnosis dan Memecahkan Masalah: Anda dapat menggunakan AKS Mendiagnosis dan Memecahkan Masalah untuk menganalisis kesalahan, identitas akar penyebab, dan mendapatkan rekomendasi resolusi.
  • Tingkatkan interval pemindaian Autoscaler Kluster: Jika laporan diagnostik menunjukkan bahwa pembatasan Autoscaler Kluster telah terdeteksi, Anda dapat meningkatkan interval pemindaian untuk mengurangi jumlah panggilan ke Set Skala Komputer Virtual dari Autoscaler Kluster.
  • Konfigurasi ulang aplikasi pihak ketiga untuk melakukan lebih sedikit panggilan: Jika Anda memfilter menurut agen pengguna dalam diagnostik Lihat tingkat permintaan dan detail pembatasan dan lihat bahwa aplikasi pihak ketiga, seperti aplikasi pemantauan, membuat sejumlah besar permintaan GET, Anda dapat mengubah pengaturan aplikasi ini untuk mengurangi frekuensi panggilan GET. Pastikan klien aplikasi menggunakan backoff eksponensial saat memanggil API Azure.
• Pisahkan kluster Anda menjadi langganan atau wilayah yang berbeda: Jika Anda memiliki sejumlah besar kluster dan kumpulan simpul yang menggunakan Virtual Machine Scale Sets, Anda dapat membaginya menjadi langganan atau wilayah yang berbeda dalam langganan yang sama. Sebagian besar batas Azure API dibagikan di tingkat wilayah langganan, sehingga Anda dapat memindahkan atau menskalakan kluster Anda ke langganan atau wilayah yang berbeda untuk dibuka blokirnya pada pembatasan Azure API. Opsi ini sangat membantu jika Anda mengharapkan kluster Anda memiliki aktivitas tinggi. Tidak ada panduan umum untuk batas ini. Jika Anda menginginkan panduan khusus, Anda dapat membuat tiket dukungan.

Batasan fitur

Saat Anda menskalakan kluster AKS Anda ke titik skala yang lebih besar, ingatlah batasan fitur berikut:

• AKS mendukung penskalaan hingga 5.000 simpul secara default untuk semua kluster Tingkat Standar /LTS. AKS menskalakan sarana kontrol kluster Anda pada runtime berdasarkan ukuran kluster dan pemanfaatan sumber daya server API. Jika Anda tidak dapat meningkatkan skala ke batas yang didukung, aktifkan metrik sarana kontrol (Pratinjau) dengan layanan terkelola Azure Monitor untuk Prometheus untuk memantau sarana kontrol. Untuk membantu memecahkan masalah performa atau keandalan penskalaan, lihat sumber daya berikut:
  • Panduan pemecahan masalah AKS dalam skala besar
  • Memecahkan masalah sarana kontrol Kubernetes

Catatan

Selama operasi untuk menskalakan sarana kontrol, Anda mungkin mengalami latensi atau batas waktu server API yang ditingkatkan hingga 15 menit. Jika Anda terus mengalami masalah dalam penskalaan ke batas yang didukung, buka tiket dukungan.

• Azure Network Policy Manager (Azure npm) hanya mendukung hingga 250 simpul.
• Beberapa metrik simpul AKS, termasuk penggunaan disk node, penggunaan CPU/memori simpul, dan masuk/keluar jaringan, tidak akan dapat diakses dalam metrik platform azure monitor setelah sarana kontrol ditingkatkan. Untuk mengonfirmasi apakah sarana kontrol Anda telah ditingkatkan skalanya, cari peta konfigurasi 'control-plane-scaling-status'

kubectl describe configmap control-plane-scaling-status -n kube-system

• Anda tidak dapat menggunakan fitur Hentikan dan Mulai dengan kluster yang memiliki lebih dari 100 simpul. Untuk informasi selengkapnya, lihat Menghentikan dan memulai kluster AKS.

Jaringan

Saat Anda menskalakan kluster AKS Anda ke titik skala yang lebih besar, ingatlah praktik terbaik jaringan berikut:

• Gunakan NAT Terkelola untuk keluar kluster dengan setidaknya dua IP publik di gateway NAT. Untuk informasi selengkapnya, lihat Membuat gateway NAT terkelola untuk kluster AKS Anda.
• Gunakan Azure CNI Overlay untuk menskalakan hingga 200.000 pod dan 5.000 simpul per kluster. Untuk informasi selengkapnya, lihat Mengonfigurasi jaringan Azure CNI Overlay di AKS.
• Jika aplikasi Anda memerlukan komunikasi pod-ke-pod langsung di seluruh kluster, gunakan Azure CNI dengan alokasi IP dinamis dan skalakan hingga 50.000 pod aplikasi per kluster dengan satu IP yang dapat dirutekan per pod. Untuk informasi selengkapnya, lihat Mengonfigurasi jaringan Azure CNI untuk alokasi IP dinamis di AKS.
• Saat menggunakan layanan Kubernetes internal di belakang load balancer internal, sebaiknya buat load balancer internal atau layanan di bawah skala simpul 750 untuk performa penskalaan optimal dan elastisitas load balancer.
• Azure npm hanya mendukung hingga 250 simpul. Jika Anda ingin menerapkan kebijakan jaringan untuk kluster yang lebih besar, pertimbangkan untuk menggunakan Azure CNI yang didukung oleh Cilium, yang menggabungkan sarana kontrol Azure CNI yang kuat dengan bidang data Cilium untuk menyediakan jaringan dan keamanan berkinerja tinggi.

Penskalakan kumpulan simpul

Saat Anda menskalakan kluster AKS Anda ke titik skala yang lebih besar, ingatlah praktik terbaik penskalakan kumpulan simpul berikut:

• Untuk kumpulan simpul sistem, gunakan SKU Standard_D16ds_v5 atau SKU VM inti/memori yang setara dengan disk OS ephemeral untuk menyediakan sumber daya komputasi yang memadai untuk pod sistem kube.
• Karena AKS memiliki batas 1.000 simpul per kumpulan simpul, sebaiknya buat setidaknya lima kumpulan simpul pengguna untuk menskalakan hingga 5.000 simpul.
• Saat menjalankan kluster AKS dalam skala besar, gunakan autoscaler kluster jika memungkinkan untuk memastikan penskalaan dinamis kumpulan simpul berdasarkan permintaan sumber daya komputasi. Untuk informasi selengkapnya, lihat Menskalakan kluster AKS secara otomatis untuk memenuhi permintaan aplikasi.
• Jika Anda menskalakan lebih dari 1.000 simpul dan tidak menggunakan autoscaler kluster, kami sarankan penskalaan dalam batch 500-700 simpul sekaligus. Operasi penskalanaan harus memiliki waktu tunggu dua menit hingga lima menit antara operasi peningkatan skala untuk mencegah pembatasan Azure API. Untuk informasi selengkapnya, lihat manajemen API: Kebijakan penembolokan dan pembatasan.

Pertimbangan peningkatan kluster dan praktik terbaik

• Ketika kluster mencapai batas 5.000 simpul, peningkatan kluster diblokir. Batas ini mencegah peningkatan karena tidak ada kapasitas simpul yang tersedia untuk melakukan pembaruan bergulir dalam batas properti lonjakan maksimum. Jika Anda memiliki kluster pada batas ini, sebaiknya turunkan skala kluster di bawah 3.000 simpul sebelum mencoba peningkatan kluster. Ini akan memberikan kapasitas tambahan untuk churn simpul dan meminimalkan beban pada sarana kontrol.
• Saat meningkatkan kluster dengan lebih dari 500 simpul, disarankan untuk menggunakan konfigurasi lonjakan maksimum 10-20% dari kapasitas kumpulan simpul. AKS mengonfigurasi peningkatan dengan nilai default 10% untuk lonjakan maksimum. Anda dapat menyesuaikan pengaturan lonjakan maksimum per kumpulan simpul untuk mengaktifkan trade-off antara kecepatan peningkatan dan gangguan beban kerja. Ketika Anda meningkatkan pengaturan lonjakan maksimum, proses peningkatan selesai lebih cepat, tetapi Anda mungkin mengalami gangguan selama proses peningkatan. Untuk informasi selengkapnya, lihat Menyesuaikan peningkatan lonjakan simpul.
• Untuk informasi peningkatan kluster lainnya, lihat Meningkatkan kluster AKS.