Container Service for Kubernetes:Ikhtisar penjadwalan

Kebijakan

Deskripsi

Skenario

nodeSelector

Beri label node dengan pasangan kunci-nilai, lalu gunakan nodeSelector untuk menjadwalkan pod ke node yang sesuai.

Contohnya, jadwalkan pod ke node tertentu atau jadwalkan pod ke kelompok node tertentu.

Metode pemilihan node dasar yang tidak mendukung fitur penjadwalan lebih kompleks, seperti aturan penjadwalan soft.

nodeAffinity

Lebih fleksibel dan detail halus daripada nodeSelector. Misalnya, aturan penjadwalan ketat requiredDuringSchedulingIgnoredDuringExecution dan aturan penjadwalan lunak preferredDuringSchedulingIgnoredDuringExecution.

Jadwalkan pod ke node dengan karakteristik tertentu, seperti wilayah, tipe perangkat, dan perangkat keras. Aturan anti-afinitas menyebarkan pod di berbagai node.

Taints and tolerations

Taint terdiri atas kunci, nilai, dan efek (efek umum: NoSchedule, PreferNoSchedule, NoExecute). Hanya pod dengan toleransi yang sesuai yang dijadwalkan ke node yang memiliki taint.

• Reservasi sumber daya node khusus untuk aplikasi tertentu, seperti node berakselerasi GPU untuk workload AI atau ML.

• Tambahkan taint atau label ke kelompok node untuk menjadwalkan pod aplikasi ke kelompok tertentu. Lihat Buat dan kelola kelompok node dan Ubah kelompok node.

• Mengusir Pod berdasarkan taint dan Toleransi. Misalnya, tambahkan taint ke node yang tidak sehat dan atur efeknya ke NoExecute.

Inter-pod affinity and anti-affinity

Label pod menentukan penjadwalan pod ke node. Mendukung aturan afinitas requiredDuringSchedulingIgnoredDuringExecution dan aturan anti-afinitas preferredDuringSchedulingIgnoredDuringExecution.

• Tempatkan pod kolaboratif bersama di node yang sama atau berdekatan untuk mengurangi latensi jaringan.

• Sebarkan pod aplikasi kritis di berbagai node atau domain kesalahan.

Kebijakan

Deskripsi

Skenario

Referensi

Penjadwalan sumber daya berbasis prioritas kustom

Tentukan nilai ResourcePolicy kustom selama rilis atau scaling untuk menentukan urutan pemilihan sumber daya node. Contohnya, utamakan Instance ECS subscription, lalu Instance ECS pay-as-you-go, kemudian instance kontainer elastis.

Scale-in membalik urutan ini: instance kontainer elastis terlebih dahulu, lalu Instance ECS pay-as-you-go, kemudian Instance ECS subscription.

• Tentukan node yang diprioritaskan atau dihindari untuk menyeimbangkan penggunaan sumber daya kluster.

• Pod aplikasi berkinerja-tinggi diutamakan dijadwalkan ke node berkinerja-tinggi.

• Pod yang tidak kritis terhadap kinerja diutamakan dijadwalkan ke instans preemptible atau node dengan sumber daya menganggur, sehingga mengurangi biaya.

Penjadwalan prioritas kustom untuk sumber daya elastis

Kebijakan

Deskripsi

Skenario

Referensi

Gang Scheduling

Semua pod terkait dijadwalkan bersama atau tidak sama sekali, mencegah proses abnormal menghambat grup.

• Pekerjaan batch: Satu pekerjaan berisi beberapa tugas saling bergantung yang harus diproses secara bersamaan.

• Komputasi terdistribusi: Pekerjaan pelatihan pembelajaran mesin atau aplikasi terdistribusi lain yang harus berjalan secara simultan.

• Komputasi berkinerja-tinggi: Suatu pekerjaan mungkin memerlukan semua sumber daya tersedia secara bersamaan sebelum eksekusi.

Gunakan Gang scheduling

Capacity Scheduling

Reservasi sumber daya untuk namespace atau kelompok pengguna tertentu, serta tingkatkan pemanfaatan melalui berbagi sumber daya saat sumber daya kluster terbatas.

Pada kluster multi-tenant, siklus hidup dan pola penggunaan sumber daya yang bervariasi menyebabkan pemanfaatan rendah. Berbagi dan mereklaim sumber daya meningkatkan pemanfaatan keseluruhan.

Bekerja dengan capacity scheduling

Deskripsi

Skenario

Referensi

Penjadwal menggunakan label gang scheduling untuk memastikan semua permintaan sumber daya pod terpenuhi secara bersamaan. Penjadwalan berbasis topologi melakukan iterasi melalui domain topologi untuk menemukan satu domain yang memenuhi semua persyaratan pod.

Asosiasikan kelompok node dengan deployment sets untuk menjadwalkan pod ke Instance ECS dalam deployment set berlatensi rendah yang sama guna meningkatkan kinerja pekerjaan.

Pada pekerjaan pembelajaran mesin atau data besar, pod memerlukan komunikasi sering. Penjadwal melakukan iterasi melalui domain topologi untuk menemukan satu domain yang memenuhi semua persyaratan pod, sehingga mengurangi waktu penyelesaian pekerjaan.

• Penjadwalan berbasis topologi

• Praktik terbaik untuk deployment sets dalam kelompok node

Deskripsi

Skenario

Referensi

Penjadwal ACK memantau riwayat beban node dan memperkirakan penggunaan sumber daya pod baru untuk menjadwalkan pod ke node dengan beban lebih rendah, mencegah crash akibat node kelebihan beban.

Aplikasi yang sensitif terhadap beban, latensi akses, atau QoS sumber daya.

Gunakan penjadwalan berbasis beban

Kebijakan

Deskripsi

Skenario

Referensi

CPU Burst

Sistem operasi dapat melakukan throttle penggunaan CPU kontainer dalam satu siklus (CPU throttling). CPU Burst memungkinkan kontainer menganggur mengakumulasi time slice CPU dan melebihi batas CPU selama lonjakan permintaan, sehingga meningkatkan kinerja dan mengurangi latensi.

• Kontainer yang mengonsumsi CPU tinggi saat startup dan loading tetapi hanya memerlukan CPU biasa setelahnya.

• Aplikasi dengan lonjakan CPU tiba-tiba, seperti e-commerce, game, dan layanan web lain, yang harus merespons cepat terhadap lonjakan trafik.

Aktifkan kebijakan optimasi kinerja CPU Burst

Penjadwalan CPU berbasis topologi

Patok pod sensitif CPU ke core CPU tertentu untuk menghindari degradasi kinerja akibat context switching sering dan akses memori lintas-NUMA.

• Aplikasi yang belum disesuaikan dengan lingkungan cloud-native—misalnya, jumlah thread berdasarkan core fisik alih-alih spesifikasi kontainer—menyebabkan degradasi kinerja.

• Aplikasi pada Instance Mesin Fisik ECS multi-core dengan CPU Intel atau AMD yang mengalami degradasi kinerja akibat akses memori lintas-NUMA.

• Aplikasi yang sangat sensitif terhadap context switching CPU dan tidak dapat mentolerir fluktuasi kinerja.

Aktifkan penjadwalan CPU berbasis topologi

Penjadwalan GPU berbasis topologi

Saat beberapa pod intensif GPU berjalan bersamaan, mereka dapat bersaing untuk sumber daya GPU dan berganti-ganti antar GPU atau node NUMA, sehingga menurunkan kinerja. Penjadwalan GPU berbasis topologi menetapkan workload ke GPU tertentu, mengurangi akses memori lintas-NUMA dan meningkatkan kinerja.

• Komputasi terdistribusi skala besar yang memerlukan transfer data efisien, seperti komputasi berkinerja-tinggi.

• Workload pembelajaran mesin dan pembelajaran mendalam yang memerlukan sumber daya GPU ekstensif serta alokasi tepat pekerjaan pelatihan di berbagai GPU.

• Rendering grafis dan pengembangan game yang memerlukan alokasi efisien pekerjaan rendering di berbagai GPU.

• Penjadwalan GPU berbasis topologi

• Aktifkan penjadwalan berbasis topologi NUMA

Overcommitment sumber daya dinamis

Reklaim sumber daya yang dialokasikan tetapi tidak digunakan oleh pod dan jadwalkan ke pekerjaan prioritas rendah untuk overcommitment. Gunakan kebijakan QoS single-node berikut secara bersamaan untuk mencegah aplikasi saling memengaruhi:

• CPU Suppress: Batasi sumber daya CPU yang tersedia untuk pod prioritas rendah saat penggunaan node secara keseluruhan di bawah ambang batas, memastikan stabilitas kontainer.

• CPU QoS: Pastikan alokasi CPU yang cukup untuk aplikasi prioritas tinggi.

• Memory QoS: Pastikan alokasi memori yang cukup untuk aplikasi prioritas tinggi dan tunda reclaiming memori.

• Isolasi sumber daya berdasarkan cache L3 dan Memory Bandwidth Allocation (MBA): Utamakan cache L3 dan MBA untuk aplikasi prioritas tinggi.

Tingkatkan pemanfaatan sumber daya kluster melalui colocation. Skenario khas meliputi pelatihan dan inferensi model ML, pemrosesan batch dan analisis data besar, layanan online, serta backup offline.

• Aktifkan overcommitment sumber daya dinamis

• Aktifkan CPU Suppress

• Aktifkan CPU QoS untuk kontainer

• Memory QoS

• Aktifkan isolasi sumber daya berdasarkan cache L3 dan MBA

• Praktik terbaik untuk colocation

Ubah parameter sumber daya pod secara dinamis

Pada Kubernetes 1.27 atau lebih awal, mengubah parameter kontainer memerlukan penghapusan dan pembuatan ulang pod. ACK memungkinkan Anda mengubah batas CPU, memori, dan IOPS disk tanpa me-restart pod.

Penyesuaian sementara sumber daya CPU atau memori.

Ubah parameter sumber daya pod secara dinamis

Kebijakan

Deskripsi

Skenario

Referensi

Descheduling

Jadwalkan ulang pod yang salah tempat ke node optimal saat hotspot terbentuk akibat penggunaan sumber daya tidak merata atau perubahan atribut node, memastikan ketersediaan tinggi dan efisiensi workload.

• Distribusi workload tidak merata dengan node kelebihan beban, misalnya dalam skenario colocation.

• Pemanfaatan sumber daya kluster rendah sehingga perlu menghapus node untuk mengurangi biaya.

• Fragmentasi sumber daya mencegah node individual memiliki sumber daya cukup meskipun kapasitas kluster secara keseluruhan memadai.

• Taint atau label ditambahkan atau dihapus dari suatu node.

• Descheduling

• Aktifkan fitur descheduling

Bekerja dengan load-aware hotspot descheduling

Kombinasikan penjadwalan berbasis beban dan descheduling hotspot untuk memantau beban node dan secara otomatis menyeimbangkan ulang node yang melebihi ambang batas beban.

Load-aware hotspot descheduling