Bagikan melalui

Opsi penyimpanan untuk aplikasi di Azure Kubernetes Service (AKS)

Saat menjalankan aplikasi di Azure Kubernetes Service (AKS), Anda mungkin perlu secara aktif meningkatkan atau mengurangi jumlah sumber daya komputasi di kluster Anda. Saat anda mengubah jumlah instans aplikasi yang kamu miliki, kamu mungkin perlu mengubah jumlah node Kubernetes yang mendasar. Anda mungkin juga perlu menyediakan sejumlah besar instans aplikasi lainnya.

Artikel ini memperkenalkan konsep penskalaan aplikasi AKS inti, termasuk penskalaan pod atau simpul secara manual, menggunakan autoscaler Pod Horizontal, menggunakan autoscaler Kluster, dan terintegrasi dengan Azure Container Instances (ACI).

Menskalakan pod atau simpul secara manual

Anda dapat menskalakan replika, atau pod secara manual, dan simpul untuk menguji bagaimana aplikasi Anda merespons perubahan sumber daya dan status yang tersedia. Menskalakan sumber daya secara manual memungkinkan Anda menentukan sejumlah sumber daya yang akan digunakan, seperti jumlah simpul, untuk mempertahankan biaya tetap. Untuk menskalakan secara manual, Anda menentukan jumlah replika atau simpul. API Kubernetes kemudian menjadwalkan pembuatan lebih banyak pod atau pengurasan simpul berdasarkan jumlah replika atau simpul tersebut.

Saat Anda menurunkan skala simpul, API Kubernetes memanggil AZURE Compute API yang relevan yang terkait dengan jenis komputasi yang digunakan oleh kluster Anda. Misalnya, untuk kluster yang dibangun di Virtual Machine Scale Sets, API Virtual Machine Scale Sets menentukan simpul mana yang akan dihapus. Untuk mempelajari selengkapnya tentang bagaimana simpul dipilih untuk dihapus pada penurunan skala, lihat Tanya Jawab Umum Set Skala Komputer Virtual.

Untuk mulai menskalakan simpul secara manual, lihat menskalakan simpul secara manual di kluster AKS. Untuk menskalakan jumlah pod secara manual, lihat perintah skala kubectl.

Autoscaler pod horizontal

Kubernetes menggunakan autoscaler pod horizontal (HPA) untuk memantau permintaan sumber daya dan secara otomatis menskalakan jumlah pod. Secara default, HPA memeriksa API Metrik setiap 15 detik untuk setiap perubahan yang diperlukan dalam jumlah replika, sementara API Metrik mengambil data dari Kubelet setiap 60 detik. Akibatnya, HPA diperbarui setiap 60 detik. Ketika perubahan diperlukan, jumlah replika diskalakan sesuai. HPA bekerja dengan kluster AKS yang telah menyebarkan Metrics Server untuk Kubernetes versi 1.8 dan yang lebih tinggi.

Autoscaling pod horizontal Kubernetes

Saat mengonfigurasi HPA untuk penyebaran tertentu, Anda menentukan jumlah minimum dan maksimum replika yang dapat berjalan. Anda juga menentukan metrik untuk memantau dan menskalakan keputusan dasar, seperti penggunaan CPU.

Untuk memulai autoscaler pod horizontal di AKS, lihat Pod Autoscale di AKS.

Cooldown peristiwa penskalaan

Karena HPA diperbarui secara efektif setiap 60 detik, peristiwa skala sebelumnya mungkin tidak berhasil diselesaikan sebelum pemeriksaan lain dilakukan. Perilaku ini dapat menyebabkan HPA mengubah jumlah replika sebelum peristiwa skala sebelumnya dapat menerima beban kerja aplikasi dan permintaan sumber daya untuk menyesuaikannya.

Untuk meminimalkan peristiwa persaingan (race condition), nilai penundaan harus diatur. Nilai ini menentukan berapa lama HPA harus menunggu setelah peristiwa skala sebelum peristiwa skala lain dapat dipicu. Hal ini memungkinkan jumlah replika baru berlaku dan API Metrik untuk mencerminkan beban kerja terdistribusi. Sebagai bagian dari Kubernetes 1.12, peristiwa peningkatan skala berlangsung tanpa penundaan. Namun, penundaan default pada peristiwa penurunan skala adalah 5 menit.

Autoscaler kluster

Untuk menanggapi perubahan permintaan pod, autoscaler kluster Kubernetes menyesuaikan jumlah simpul berdasarkan sumber daya komputasi yang diminta di kumpulan simpul. Secara default, autoscaler kluster memeriksa server API metrik setiap 10 detik untuk setiap perubahan jumlah simpul yang diperlukan. Jika autoscaler kluster menentukan bahwa perubahan diperlukan, jumlah simpul di kluster AKS Anda ditingkatkan atau dikurangi. Autoscaler kluster ini bekerja dengan kluster AKS Kubernetes RBAC-enabled yang menjalankan Kubernetes 1.10.x atau yang lebih tinggi.

Autoscaler kluster Kubernetes

Autoscaler kluster biasanya digunakan bersama autoscaler pod horizontal. Jika digabungkan, autoscaler pod horizontal meningkatkan atau mengurangi jumlah pod berdasarkan permintaan aplikasi, dan autoscaler kluster menyesuaikan jumlah simpul untuk menjalankan lebih banyak pod.

Untuk mulai menggunakan autoscaler kluster di AKS, lihat Autoscaler kluster di AKS.

Peristiwa peluasan skala

Jika simpul tidak memiliki sumber daya komputasi yang memadai untuk menjalankan pod yang diminta, Pod tersebut tidak dapat melanjutkan ke proses penjadwalan. Pod tidak dapat dimulai sampai lebih banyak sumber daya komputasi tersedia di dalam node pool.

Ketika autoscaler kluster melihat pod yang tidak dapat dijadwalkan karena kendala sumber daya kumpulan simpul, jumlah simpul dalam kumpulan simpul ditingkatkan untuk menyediakan sumber daya komputasi tambahan. Ketika simpul berhasil disebarkan dan tersedia untuk digunakan dalam kumpulan simpul, pod kemudian dijadwalkan untuk berjalan pada simpul tersebut.

Jika aplikasi Anda perlu diskalakan dengan cepat, beberapa pod mungkin tetap dalam keadaan menunggu dijadwalkan hingga lebih banyak simpul yang disebarkan oleh cluster autoscaler dapat menerima pod-pod tersebut. Untuk aplikasi yang memiliki permintaan burst tinggi, Anda dapat menskalakan dengan simpul virtual dan Azure Container Instances.

Peristiwa Penyempitan Skala

Autoscaler kluster juga memantau status penjadwalan pod untuk simpul yang belum menerima permintaan penjadwalan baru akhir-akhir ini. Skenario ini menunjukkan kumpulan simpul memiliki lebih banyak sumber daya komputasi daripada yang diperlukan, dan jumlah simpul dapat dikurangi. Secara default, simpul yang melewati ambang batas tidak lagi diperlukan selama 10 menit dijadwalkan untuk dihapus. Ketika situasi ini terjadi, pod dijadwalkan untuk berjalan pada simpul lain dalam kumpulan simpul, dan autoscaler kluster mengurangi jumlah simpul.

Aplikasi Anda mungkin mengalami beberapa gangguan karena pod dijadwalkan pada node yang berbeda ketika autoscaler kluster mengurangi jumlah simpul. Untuk meminimalkan gangguan, hindari aplikasi yang menggunakan pod instans tunggal.

Autoscaling berbasis Peristiwa Kubernetes (KEDA)

Autoscaling berbasis Peristiwa Kubernetes (KEDA) adalah komponen sumber terbuka untuk penskalaan otomatis beban kerja berbasis peristiwa. Ini menskalakan beban kerja secara dinamis berdasarkan jumlah peristiwa yang diterima. KEDA memperluas Kubernetes dengan definisi sumber daya kustom (CRD), yang disebut sebagai ScaledObject, untuk menjelaskan bagaimana aplikasi harus diskalakan sebagai respons terhadap lalu lintas tertentu.

Penskalaan KEDA berguna dalam skenario di mana beban kerja menerima ledakan lalu lintas atau menangani data dalam volume tinggi. KEDA berbeda dari Autoscaler Pod Horizontal karena KEDA digerakkan oleh peristiwa dan diskalakan berdasarkan jumlah peristiwa, sementara HPA digerakkan oleh metrik berdasarkan pemanfaatan sumber daya (misalnya, CPU dan memori).

Untuk mulai menggunakan add-on KEDA di AKS, lihat Gambaran umum KEDA.

Provisi Otomatis Node

Provisi otomatis simpul (pratinjau) (NAP), menggunakan proyek Karpenter sumber terbuka yang secara otomatis menyebarkan, mengonfigurasi, dan mengelola Karpenter pada kluster AKS Anda. NAP secara dinamis menyediakan node berdasarkan persyaratan sumber daya pod yang tertunda; secara otomatis akan memilih SKU komputer virtual (VM) yang optimal dan kuantitas untuk memenuhi permintaan waktu nyata.

NAP mengambil daftar SKU VM yang telah ditentukan sebelumnya sebagai titik awal untuk memutuskan SKU mana yang paling cocok untuk beban kerja yang tertunda. Untuk kontrol yang lebih tepat, pengguna dapat menentukan batas atas sumber daya yang digunakan oleh kumpulan simpul dan preferensi tempat beban kerja harus dijadwalkan jika ada beberapa kumpulan simpul.

Burst ke Azure Container Instances (ACI)

Untuk menskalakan kluster AKS dengan cepat, Anda dapat berintegrasi dengan Azure Container Instances (ACI). Kubernetes memiliki komponen bawaan untuk menskalakan jumlah replika dan simpul. Namun, jika aplikasi Anda perlu menskalakan dengan cepat, autoscaler pod horizontal mungkin akan menjadwalkan lebih banyak pod daripada yang dapat didukung oleh sumber daya komputasi yang ada di kumpulan simpul. Jika dikonfigurasi, skenario ini kemudian akan mengaktifkan autoscaler kluster untuk menambah simpul di dalam kumpulan simpul, tetapi mungkin perlu beberapa menit agar simpul tersebut berhasil disediakan dan memungkinkan penjadwal Kubernetes untuk menjalankan pod di atasnya.

Penskalaan lonjakan Kubernetes ke ACI

ACI memungkinkan Anda dengan cepat menyebarkan instans kontainer tanpa overhead infrastruktur tambahan. Ketika terhubung dengan AKS, ACI menjadi ekstensi logis yang aman dari klaster AKS Anda. Komponen simpul virtual, yang didasarkan pada Kubelet virtual, diinstal di kluster AKS Anda yang menyajikan ACI sebagai simpul Kubernetes virtual. Kubernetes kemudian dapat menjadwalkan pod yang berjalan sebagai instance ACI melalui simpul virtual, bukan sebagai pod pada simpul komputer virtual langsung di klaster AKS Anda.

Aplikasi Anda tidak memerlukan modifikasi untuk menggunakan simpul virtual. Penyebaran Anda dapat menskalakan di seluruh AKS dan ACI dan tanpa penundaan karena autoscaler kluster menyebarkan simpul baru di kluster AKS Anda.

Simpul virtual disebarkan ke subnet lain di jaringan virtual yang sama dengan kluster AKS Anda. Konfigurasi jaringan virtual ini mengamankan lalu lintas antara ACI dan AKS. Seperti kluster AKS, instans ACI adalah sumber daya komputasi logis yang aman dan terisolasi dari pengguna lain.

Langkah berikutnya

Untuk mulai menskalakan aplikasi, lihat sumber daya berikut:

Untuk informasi lebih lanjut mengenai konsep pokok Kube dan AKS, lihat artikel berikut: