Penjadwalan ulang adalah proses menjadwalkan ulang pod yang memenuhi aturan pengusiran dari satu node ke node lain. Dalam skenario seperti ketidakseimbangan sumber daya kluster atau kegagalan penjadwalan pod akibat perubahan atribut node, Anda dapat menggunakan penjadwalan ulang untuk mengoptimalkan penggunaan sumber daya dan menjadwalkan pod ke node optimal. Hal ini memastikan ketersediaan tinggi dan efisiensi beban kerja dalam kluster.
Sebelum Anda mulai
Perhatikan hal-hal berikut sebelum menggunakan fitur penjadwalan ulang:
Pelajari cara Kubernetes Scheduler bekerja serta istilah terkait kebijakan penjadwalan asli Kubernetes, termasuk taint dan toleration dan afinitas dan anti-afinitas.
Lihat ack-koordinator (ack-slo-manager) untuk mempelajari arsitektur dan fitur dari ack-koordinator.
Pelajari cara Container Service for Kubernetes (ACK) memprioritaskan node dengan beban rendah saat menjadwalkan pod melalui penjadwalan berbasis beban.
Setelah membaca topik ini, Anda akan memahami informasi berikut tentang penjadwalan ulang:
Skenario penggunaan penjadwalan ulang.
Alur kerja penjadwalan ulang.
Istilah terkait penjadwalan ulang, termasuk templat penjadwalan ulang, kebijakan Deschedule dan Balance, serta evictor DefaultEvictor dan MigrationController.
Mengapa penjadwalan ulang penting
Kubernetes Scheduler menjadwalkan pod ke node yang sesuai berdasarkan status kluster saat ini. Namun, status kluster terus berubah. Dalam beberapa kasus, Anda mungkin perlu memigrasi pod yang sedang berjalan ke node lain. Contohnya:
Distribusi beban kerja dalam kluster tidak merata. Beberapa node kelebihan beban, sehingga performanya terganggu.
Pemanfaatan sumber daya keseluruhan kluster rendah. Untuk menghemat biaya, Anda ingin menghapus beberapa node. Untuk melakukannya, migrasikan pod pada node tersebut ke node lain terlebih dahulu.
Kluster memiliki banyak fragmen sumber daya. Akibatnya, sebuah node mungkin tidak memiliki sumber daya idle yang cukup meskipun total sumber daya dalam kluster masih mencukupi. Dalam skenario ini, pod yang meminta jumlah sumber daya besar gagal dijadwalkan, meningkatkan biaya sumber daya kluster.
Taint atau label ditambahkan atau dihapus dari sebuah node. Dalam skenario ini, beberapa pod pada node tersebut tidak lagi sesuai dengan aturan afinitas dan harus dimigrasi ke node yang sesuai.
Sebagai contoh, aplikasi dengan beban kerja fluktuatif dapat menyebabkan node hotspot selama jam puncak, yang mengganggu kualitas layanan. Fitur penjadwalan ulang dapat mengusir pod abnormal untuk mengurangi beban node hotspot dan memastikan kualitas layanan.
Untuk mencapai tujuan ini, ack-koordinator menyediakan modul penjadwalan ulang bernama Koordinator Descheduler, yang berjalan sebagai Deployment pada node. Koordinator Descheduler dikembangkan berdasarkan Kerangka Kerja Penjadwalan Ulang dari Kubernetes Descheduler. Modul ini kompatibel dengan semua kebijakan penjadwalan ulang Kubernetes Descheduler dan mengoptimalkan penjadwalan ulang pod dalam hal kebijakan, metode pengusiran, kontrol lalu lintas, dan proses pengusiran. Untuk informasi lebih lanjut tentang perbedaan antara Koordinator Descheduler dan Kubernetes Descheduler, lihat Koordinator Descheduler dan Kubernetes Descheduler.
Alur kerja penjadwalan ulang
Koordinator Descheduler bekerja secara berkala. Anda dapat mengonfigurasi kebijakan penjadwalan ulang untuk memfilter, memeriksa, dan mengusir pod yang memenuhi kondisi pengusiran. Gambar berikut menunjukkan cara kerja Koordinator Descheduler.
Menelusuri templat penjadwalan ulang dan menjalankan kebijakan Deschedule yang diaktifkan dalam setiap templat secara berurutan.
Mendapatkan informasi tentang node, beban kerja, dan pod.
Membandingkan pod dengan aturan Deschedule.
Memfilter, memeriksa, dan mengurutkan pod yang memenuhi aturan pengusiran.
Pod evictor yang diaktifkan dalam templat penjadwalan ulang mengirim permintaan pengusiran pod.
Menelusuri templat penjadwalan ulang lagi dan menjalankan kebijakan Balance yang diaktifkan dalam setiap templat secara berurutan. Alur kerja serupa dengan Langkah 1.
Berikut ini adalah deskripsi istilah yang digunakan dalam alur kerja penjadwalan ulang.
Templat penjadwalan ulang
Anda dapat mengonfigurasi satu atau lebih templat penjadwalan ulang untuk memenuhi kebutuhan penjadwalan ulang yang berbeda. Setiap templat dapat menentukan kebijakan penjadwalan ulang, pod evictor, ruang lingkup yang berlaku, dan parameter lanjutan untuk jenis pod tertentu.
Menggunakan kebijakan penjadwalan ulang memungkinkan Anda menerapkan kebijakan pengusiran pod yang berbeda dalam skenario yang berbeda. Misalnya, untuk mengusir pod kedaluwarsa dengan TTL berbeda di namespace yang berbeda, Anda dapat mengonfigurasi beberapa templat penjadwalan ulang dan menetapkan ambang batas untuk TTL pod di setiap namespace.
Selama proses penjadwalan ulang, Koordinator Descheduler menelusuri semua templat penjadwalan ulang dan menjalankan kebijakan Deschedule dalam setiap templat. Setelah semua kebijakan Deschedule dijalankan, Koordinator Descheduler menelusuri templat lagi dan menjalankan kebijakan Balance dalam setiap templat.
Kebijakan penjadwalan ulang: Deschedule dan Balance
Dua kebijakan penjadwalan ulang tersedia: Deschedule dan Balance. Kebijakan ini digunakan untuk mencocokkan pod yang akan diusir. Untuk informasi lebih lanjut tentang cara mengonfigurasi kebijakan penjadwalan ulang dan fitur yang didukung oleh setiap kebijakan, lihat Konfigurasikan Plugin Kebijakan.
Deschedule: Koordinator Descheduler mencocokkan setiap pod dengan kendala penjadwalan saat ini dan mengusir pod yang cocok secara berurutan. Sebagai contoh, Koordinator Descheduler mengusir pod yang tidak sesuai dengan aturan afinitas atau anti-afinitas node satu per satu.
Balance: Koordinator Descheduler mengoptimalkan distribusi pod tertentu atau semua pod dalam kluster, kemudian memutuskan pod yang akan diusir. Sebagai contoh, Koordinator Descheduler mengusir pod dari node hotspot berdasarkan pemanfaatan sumber daya node.
Kebijakan penjadwalan ulang bersifat independen satu sama lain. Koordinator Descheduler menjalankan setiap kebijakan untuk mengusir pod berdasarkan aturan pengusiran kebijakan tersebut, kemudian memfilter, memeriksa, dan mengurutkan pod yang cocok. Kendala seperti kapasitas kluster, pemanfaatan sumber daya, dan jumlah replika dipertimbangkan saat pod dicocokkan dengan aturan pengusiran. Setelah Koordinator Descheduler memutuskan pod yang akan diusir, ia mengirim permintaan ke pod evictor untuk mengusir pod tersebut.
Evictor dan kontrol pengusiran
Evictor dalam Koordinator Descheduler digunakan untuk mengusir pod. Evictor yang tersedia adalah DefaultEvictor dan MigrationController.
DefaultEvictor: evictor pod dasar yang memungkinkan Anda membatasi jumlah maksimum pod yang akan diusir. Anda dapat menggunakan dan mengonfigurasi DefaultEvictor dengan cara yang sama seperti pada Kubernetes Descheduler. Untuk informasi lebih lanjut, lihat DefaultEvictor.
MigrationController: memungkinkan Anda mengusir dan memigrasi pod dengan cara yang aman serta melacak pengusiran pod. Untuk informasi lebih lanjut tentang parameter, lihat Konfigurasikan Plugin Evictor.
Untuk informasi lebih lanjut tentang perbedaan antara kedua evictor, lihat Perbandingan.
Aktifkan penjadwalan ulang
Untuk informasi lebih lanjut tentang cara menginstal komponen ack-koordinator dan mengaktifkan penjadwalan ulang, lihat Aktifkan Fitur Penjadwalan Ulang.
Anda juga dapat mengonfigurasi parameter lanjutan untuk Koordinator Descheduler, templat penjadwalan ulang, plugin kebijakan penjadwalan ulang, dan plugin evictor dalam ConfigMap. Untuk informasi lebih lanjut, lihat Konfigurasikan Parameter Lanjutan.
Referensi
Jika Anda menggunakan Kubernetes Descheduler, kami menyarankan Anda bermigrasi ke Koordinator Descheduler. Untuk informasi lebih lanjut tentang perbedaan dan cara bermigrasi ke Koordinator Descheduler, lihat Perbandingan antara Koordinator Descheduler dan Kubernetes Descheduler.
Fitur penjadwalan ulang dikembangkan berdasarkan Koordinator Descheduler dari komponen ack-koordinator. Anda dapat menginstal dan menggunakan komponen ack-koordinator secara gratis. Namun, komponen ini mungkin dikenakan biaya dalam skenario tertentu. Untuk informasi lebih lanjut, lihat Penagihan.