Opsi penyimpanan untuk aplikasi di Azure Kubernetes Service (AKS)

  • Artikel

Saat menjalankan aplikasi di Azure Kubernetes Service (AKS), Anda mungkin perlu meningkatkan atau mengurangi jumlah sumber daya komputasi. Saat Anda mengubah jumlah instans aplikasi yang Anda miliki, Anda mungkin perlu mengubah jumlah simpul 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 untuk mempertahankan biaya tetap, seperti jumlah simpul. Untuk menskalakan secara manual, Anda harus menentukan jumlah replika atau simpul. API Kubernetes kemudian menjadwalkan pembuatan lebih banyak pod atau pengurasan simpul berdasarkan jumlah replika atau simpul tersebut.

Saat scale down, API Kubernetes memanggil API Azure Compute 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, dan API Metrik mengambil data dari Kubelet setiap 60 detik. Jadi, HPA diperbarui setiap 60 detik. Ketika perubahan diperlukan, jumlah replika ditingkatkan atau menurun sesuai kebutuhan. HPA bekerja dengan kluster AKS yang menyebarkan Metrics Server untuk Kubernetes versi 1.8 dan yang lebih tinggi.

Kubernetes horizontal pod autoscaling

Saat mengonfigurasi HPA untuk penyebaran tertentu, Anda menentukan jumlah minimum dan maksimum replika yang dapat berjalan. Anda juga menentukan metrik untuk memantau dan mendasari keputusan penskalaan, misal, 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. Tidak ada penundaan untuk peristiwa peningkatan skala pada Kubernetes 1.12, 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 kecuali lebih banyak sumber daya komputasi tersedia dalam kumpulan simpul.

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 menskalakan dengan cepat, beberapa pod mungkin tetap dalam keadaan menunggu untuk dijadwalkan hingga lebih banyak simpul yang disebarkan oleh autoscaler kluster dapat menerima pod terjadwal. 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 ketika pod dijadwalkan pada simpul 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. Ini berbeda dari Horizontal Pod Autoscaler, karena KEDA digerakkan oleh peristiwa dan menskalakan 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.

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 dapat menjadwalkan lebih banyak pod daripada yang dapat disediakan oleh sumber daya komputasi yang ada di kumpulan simpul. Jika dikonfigurasi, skenario ini kemudian akan memicu autoscaler kluster untuk menyebarkan lebih banyak simpul di kumpulan simpul, tetapi mungkin perlu beberapa menit agar simpul tersebut berhasil menyediakan dan memungkinkan penjadwal Kubernetes untuk menjalankan pod pada mereka.

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: