Kube-scheduler merupakan komponen integral dari Kubernetes, yang bertanggung jawab untuk menjadwalkan pod di seluruh node sesuai dengan kebijakan yang ditentukan. Seringkali, selama pengoperasian cluster Kubernetes, kita tidak perlu memikirkan kebijakan mana yang digunakan untuk menjadwalkan pod, karena kumpulan kebijakan kube-scheduler default cocok untuk sebagian besar tugas sehari-hari. Namun, ada situasi di mana kita perlu menyempurnakan proses pengalokasian pod, dan ada dua cara untuk menyelesaikan tugas ini:
- Buat kube-scheduler dengan seperangkat aturan khusus
- Tulis penjadwal Anda sendiri dan ajarkan untuk bekerja dengan permintaan server API
Pada artikel ini, saya akan menjelaskan implementasi poin pertama untuk menyelesaikan masalah penjadwalan perapian yang tidak merata di salah satu proyek kami.
Pengenalan singkat tentang cara kerja kube-scheduler
Perlu diperhatikan fakta bahwa kube-scheduler tidak bertanggung jawab untuk menjadwalkan pod secara langsung - ia hanya bertanggung jawab untuk menentukan node tempat pod akan ditempatkan. Dengan kata lain, hasil kerja kube-scheduler adalah nama node, yang dikembalikan ke server API untuk permintaan penjadwalan, dan disitulah pekerjaannya berakhir.
Pertama, kube-scheduler mengkompilasi daftar node dimana pod dapat dijadwalkan sesuai dengan kebijakan predikat. Selanjutnya, setiap node dari daftar ini menerima sejumlah poin tertentu sesuai dengan kebijakan prioritas. Hasilnya, node dengan jumlah poin maksimum yang dipilih. Jika ada node yang memiliki skor maksimum yang sama, maka dipilih node secara acak. Daftar dan deskripsi kebijakan predikat (penyaringan) dan prioritas (penilaian) dapat ditemukan di .
Deskripsi badan masalah
Meskipun sejumlah besar cluster Kubernetes berbeda yang dikelola di Nixys, kami pertama kali mengalami masalah penjadwalan pod baru-baru ini, ketika salah satu proyek kami perlu menjalankan tugas berkala dalam jumlah besar (~100 entitas CronJob). Untuk menyederhanakan deskripsi masalah sebanyak mungkin, kami akan mengambil contoh satu layanan mikro, di mana tugas cron diluncurkan satu menit sekali, sehingga menimbulkan beban pada CPU. Untuk menjalankan tugas cron, tiga node dengan karakteristik yang benar-benar identik dialokasikan (masing-masing 24 vCPU).
Pada saat yang sama, tidak mungkin untuk mengatakan dengan akurat berapa lama waktu yang dibutuhkan CronJob untuk dieksekusi, karena volume data masukan terus berubah. Rata-rata, selama pengoperasian normal kube-scheduler, setiap node menjalankan 3-4 instance pekerjaan, yang menghasilkan ~20-30% beban pada CPU setiap node:
Masalahnya sendiri adalah terkadang pod tugas cron berhenti dijadwalkan pada salah satu dari tiga node. Artinya, pada suatu saat, tidak ada satu pod pun yang direncanakan untuk salah satu node, sementara di dua node lainnya terdapat 6-8 salinan tugas yang berjalan, sehingga menyebabkan ~40-60% beban CPU:
Masalahnya berulang dengan frekuensi yang benar-benar acak dan terkadang berkorelasi dengan saat versi baru kode tersebut diluncurkan.
Dengan meningkatkan level logging kube-scheduler ke level 10 (-v=10), kami mulai mencatat berapa banyak poin yang diperoleh setiap node selama proses evaluasi. Selama operasi perencanaan normal, informasi berikut dapat dilihat di log:
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: NodeAffinityPriority, Score: (0)
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node01: InterPodAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: TaintTolerationPriority, Score: (10)
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node02: InterPodAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: TaintTolerationPriority, Score: (10)
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node01: SelectorSpreadPriority, Score: (10)
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node03: InterPodAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: TaintTolerationPriority, Score: (10)
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node02: SelectorSpreadPriority, Score: (10)
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node03: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:781] Host Node01 => Score 100043
generic_scheduler.go:781] Host Node02 => Score 100043
generic_scheduler.go:781] Host Node03 => Score 100043Itu. dilihat dari informasi yang diperoleh dari log, masing-masing node mencetak jumlah poin akhir yang sama dan poin acak dipilih untuk perencanaan. Pada saat perencanaan bermasalah, lognya terlihat seperti ini:
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node03: InterPodAffinityPriority, Score: (0)
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node02: InterPodAffinityPriority, Score: (0)
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node01: InterPodAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: TaintTolerationPriority, Score: (10)
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node03: SelectorSpreadPriority, Score: (10)
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node02: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: TaintTolerationPriority, Score: (10)
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node01: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: TaintTolerationPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:781] Host Node03 => Score 100041
generic_scheduler.go:781] Host Node02 => Score 100041
generic_scheduler.go:781] Host Node01 => Score 100038Dari sini terlihat bahwa salah satu node memperoleh poin akhir lebih sedikit dibandingkan node lainnya, sehingga perencanaan dilakukan hanya untuk dua node yang memperoleh skor maksimal. Oleh karena itu, kami sangat yakin bahwa masalahnya justru terletak pada penjadwalan pod.
Algoritma lebih lanjut untuk menyelesaikan masalah sudah jelas bagi kami - menganalisis log, memahami prioritas apa yang tidak mencetak poin oleh node dan, jika perlu, menyesuaikan kebijakan kube-scheduler default. Namun, di sini kita dihadapkan pada dua kesulitan yang signifikan:
- Pada tingkat logging maksimum (10), poin yang diperoleh hanya untuk beberapa prioritas akan tercermin. Dalam kutipan log di atas, Anda dapat melihat bahwa untuk semua prioritas yang tercermin dalam log, node mencetak jumlah poin yang sama dalam penjadwalan normal dan masalah, namun hasil akhir dalam kasus perencanaan masalah berbeda. Dengan demikian, kita dapat menyimpulkan bahwa untuk beberapa prioritas, penilaian terjadi βdi belakang layarβ, dan kita tidak dapat memahami prioritas mana yang tidak mendapatkan poin dari node tersebut. Kami menjelaskan masalah ini secara rinci di Repositori Kubernetes di Github. Pada saat penulisan, tanggapan telah diterima dari pengembang bahwa dukungan logging akan ditambahkan di pembaruan Kubernetes v1.15,1.16, 1.17 dan XNUMX.
- Tidak ada cara mudah untuk memahami rangkaian kebijakan spesifik mana yang sedang digunakan oleh kube-scheduler. Ya, masuk daftar ini tercantum, namun tidak berisi informasi tentang bobot spesifik apa yang diberikan pada masing-masing kebijakan prioritas. Anda dapat melihat bobot atau mengedit kebijakan kube-scheduler default hanya di .
Perlu dicatat bahwa setelah kami dapat mencatat bahwa sebuah node tidak menerima poin sesuai dengan kebijakan ImageLocalityPriority, yang memberikan poin ke sebuah node jika node tersebut sudah memiliki gambar yang diperlukan untuk menjalankan aplikasi. Artinya, pada saat versi baru aplikasi diluncurkan, tugas cron berhasil dijalankan pada dua node, mengunduh gambar baru dari registri buruh pelabuhan ke node tersebut, dan dengan demikian dua node menerima skor akhir yang lebih tinggi dibandingkan node ketiga. .
Seperti yang saya tulis di atas, di log kami tidak melihat informasi tentang evaluasi kebijakan ImageLocalityPriority, jadi untuk memeriksa asumsi kami, kami membuang gambar dengan aplikasi versi baru ke node ketiga, setelah itu penjadwalan berfungsi dengan benar . Justru karena kebijakan ImageLocalityPriority, masalah penjadwalan jarang terjadi; lebih sering dikaitkan dengan hal lain. Karena fakta bahwa kami tidak dapat sepenuhnya men-debug setiap kebijakan dalam daftar prioritas kube-scheduler default, kami memerlukan manajemen kebijakan penjadwalan pod yang fleksibel.
Pernyataan masalah
Kami ingin solusi untuk masalah ini sespesifik mungkin, yaitu entitas utama Kubernetes (yang kami maksud adalah kube-scheduler default) tidak berubah. Kami tidak ingin menyelesaikan masalah di satu tempat dan menimbulkan masalah di tempat lain. Jadi, kami sampai pada dua opsi untuk menyelesaikan masalah, yang diumumkan dalam pengantar artikel - membuat penjadwal tambahan atau menulis sendiri. Persyaratan utama untuk menjadwalkan tugas cron adalah mendistribusikan beban secara merata ke tiga node. Persyaratan ini dapat dipenuhi oleh kebijakan kube-scheduler yang ada, jadi untuk menyelesaikan masalah kita tidak ada gunanya menulis penjadwal Anda sendiri.
Petunjuk untuk membuat dan menerapkan kube-scheduler tambahan dijelaskan di . Namun, bagi kami tampaknya entitas Deployment tidak cukup untuk memastikan toleransi kesalahan dalam pengoperasian layanan penting seperti kube-scheduler, jadi kami memutuskan untuk menerapkan kube-scheduler baru sebagai Pod Statis, yang akan dipantau secara langsung. oleh Kubelet. Oleh karena itu, kami memiliki persyaratan berikut untuk kube-scheduler baru:
- Layanan ini harus di-deploy sebagai Pod Statis di semua master cluster
- Toleransi kesalahan harus diberikan jika pod aktif dengan kube-scheduler tidak tersedia
- Prioritas utama saat perencanaan adalah jumlah sumber daya yang tersedia pada node (LeastRequestedPriority)
Solusi implementasi
Perlu segera dicatat bahwa kami akan melakukan semua pekerjaan di Kubernetes v1.14.7, karena Ini adalah versi yang digunakan dalam proyek ini. Mari kita mulai dengan menulis manifesto untuk kube-scheduler baru kita. Mari kita ambil manifes default (/etc/kubernetes/manifests/kube-scheduler.yaml) sebagai dasar dan membawanya ke bentuk berikut:
kind: Pod
metadata:
labels:
component: scheduler
tier: control-plane
name: kube-scheduler-cron
namespace: kube-system
spec:
containers:
- command:
- /usr/local/bin/kube-scheduler
- --address=0.0.0.0
- --port=10151
- --secure-port=10159
- --config=/etc/kubernetes/scheduler-custom.conf
- --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
- --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
- --v=2
image: gcr.io/google-containers/kube-scheduler:v1.14.7
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 8
httpGet:
host: 127.0.0.1
path: /healthz
port: 10151
scheme: HTTP
initialDelaySeconds: 15
timeoutSeconds: 15
name: kube-scheduler-cron-container
resources:
requests:
cpu: '0.1'
volumeMounts:
- mountPath: /etc/kubernetes/scheduler.conf
name: kube-config
readOnly: true
- mountPath: /etc/localtime
name: localtime
readOnly: true
- mountPath: /etc/kubernetes/scheduler-custom.conf
name: scheduler-config
readOnly: true
- mountPath: /etc/kubernetes/scheduler-custom-policy-config.json
name: policy-config
readOnly: true
hostNetwork: true
priorityClassName: system-cluster-critical
volumes:
- hostPath:
path: /etc/kubernetes/scheduler.conf
type: FileOrCreate
name: kube-config
- hostPath:
path: /etc/localtime
name: localtime
- hostPath:
path: /etc/kubernetes/scheduler-custom.conf
type: FileOrCreate
name: scheduler-config
- hostPath:
path: /etc/kubernetes/scheduler-custom-policy-config.json
type: FileOrCreate
name: policy-configSecara singkat tentang perubahan utama:
- Mengubah nama pod dan container menjadi kube-scheduler-cron
- Menentukan penggunaan port 10151 dan 10159 sebagai opsi yang ditentukan
hostNetwork: truedan kita tidak dapat menggunakan port yang sama dengan kube-scheduler default (10251 dan 10259) - Dengan menggunakan parameter --config, kami menentukan file konfigurasi yang akan digunakan untuk memulai layanan
- Pemasangan file konfigurasi (scheduler-custom.conf) dan file kebijakan penjadwalan (scheduler-custom-policy-config.json) yang dikonfigurasi dari host
Jangan lupa bahwa kube-scheduler kita akan memerlukan hak yang serupa dengan hak default. Edit peran clusternya:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Sekarang mari kita bicara tentang apa yang harus terkandung dalam file konfigurasi dan file kebijakan penjadwalan:
- File konfigurasi (scheduler-custom.conf)
Untuk mendapatkan konfigurasi kube-scheduler default, Anda harus menggunakan parameter--write-config-todari . Kami akan menempatkan konfigurasi yang dihasilkan di file /etc/kubernetes/scheduler-custom.conf dan menguranginya menjadi bentuk berikut:
apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
schedulerName: kube-scheduler-cron
bindTimeoutSeconds: 600
clientConnection:
acceptContentTypes: ""
burst: 100
contentType: application/vnd.kubernetes.protobuf
kubeconfig: /etc/kubernetes/scheduler.conf
qps: 50
disablePreemption: false
enableContentionProfiling: false
enableProfiling: false
failureDomains: kubernetes.io/hostname,failure-domain.beta.kubernetes.io/zone,failure-domain.beta.kubernetes.io/region
hardPodAffinitySymmetricWeight: 1
healthzBindAddress: 0.0.0.0:10151
leaderElection:
leaderElect: true
leaseDuration: 15s
lockObjectName: kube-scheduler-cron
lockObjectNamespace: kube-system
renewDeadline: 10s
resourceLock: endpoints
retryPeriod: 2s
metricsBindAddress: 0.0.0.0:10151
percentageOfNodesToScore: 0
algorithmSource:
policy:
file:
path: "/etc/kubernetes/scheduler-custom-policy-config.json"Secara singkat tentang perubahan utama:
- Kami menetapkan schedulerName ke nama layanan kube-scheduler-cron kami.
- Dalam parameter
lockObjectNameAnda juga perlu mengatur nama layanan kami dan memastikan parameternyaleaderElectdisetel ke true (jika Anda memiliki satu node master, Anda dapat menyetelnya ke false). - Menentukan jalur ke file dengan deskripsi kebijakan penjadwalan di parameter
algorithmSource.
Sebaiknya kita melihat lebih dekat poin kedua, di mana kita mengedit parameter untuk kuncinya leaderElection. Untuk memastikan toleransi kesalahan, kami telah mengaktifkan (leaderElect) proses memilih pemimpin (master) di antara pod-pod kube-scheduler kita menggunakan satu titik akhir untuk pod-pod tersebut (resourceLock) bernama kube-scheduler-cron (lockObjectName) di namespace kube-system (lockObjectNamespace). Bagaimana Kubernetes memastikan ketersediaan komponen utama yang tinggi (termasuk kube-scheduler) dapat ditemukan di .
- File kebijakan penjadwalan (scheduler-custom-policy-config.json)
Seperti yang saya tulis sebelumnya, kita dapat mengetahui kebijakan spesifik mana yang digunakan oleh kube-scheduler default hanya dengan menganalisis kodenya. Artinya, kita tidak bisa mendapatkan file dengan kebijakan penjadwalan untuk kube-scheduler default dengan cara yang sama seperti file konfigurasi. Mari kita jelaskan kebijakan penjadwalan yang kita minati pada file /etc/kubernetes/scheduler-custom-policy-config.json sebagai berikut:
{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
{
"name": "GeneralPredicates"
}
],
"priorities": [
{
"name": "ServiceSpreadingPriority",
"weight": 1
},
{
"name": "EqualPriority",
"weight": 1
},
{
"name": "LeastRequestedPriority",
"weight": 1
},
{
"name": "NodePreferAvoidPodsPriority",
"weight": 10000
},
{
"name": "NodeAffinityPriority",
"weight": 1
}
],
"hardPodAffinitySymmetricWeight" : 10,
"alwaysCheckAllPredicates" : false
}Oleh karena itu, kube-scheduler pertama-tama mengkompilasi daftar node dimana sebuah pod dapat dijadwalkan sesuai dengan kebijakan GeneralPredicates (yang mencakup serangkaian kebijakan PodFitsResources, PodFitsHostPorts, HostName, dan MatchNodeSelector). Dan kemudian setiap node dievaluasi sesuai dengan kumpulan kebijakan dalam susunan prioritas. Untuk memenuhi persyaratan tugas kami, kami menilai serangkaian kebijakan seperti itu akan menjadi solusi optimal. Izinkan saya mengingatkan Anda bahwa serangkaian kebijakan dengan penjelasan rincinya tersedia di . Untuk menyelesaikan tugas Anda, Anda cukup mengubah rangkaian kebijakan yang digunakan dan menetapkan bobot yang sesuai pada kebijakan tersebut.
Mari kita beri nama manifes dari kube-scheduler baru, yang kita buat di awal bab ini, kube-scheduler-custom.yaml dan letakkan di jalur berikut /etc/kubernetes/manifests pada tiga node master. Jika semuanya dilakukan dengan benar, Kubelet akan meluncurkan pod di setiap node, dan di log kube-scheduler baru kita, kita akan melihat informasi bahwa file kebijakan kita berhasil diterapkan:
Creating scheduler from configuration: {{ } [{GeneralPredicates <nil>}] [{ServiceSpreadingPriority 1 <nil>} {EqualPriority 1 <nil>} {LeastRequestedPriority 1 <nil>} {NodePreferAvoidPodsPriority 10000 <nil>} {NodeAffinityPriority 1 <nil>}] [] 10 false}
Registering predicate: GeneralPredicates
Predicate type GeneralPredicates already registered, reusing.
Registering priority: ServiceSpreadingPriority
Priority type ServiceSpreadingPriority already registered, reusing.
Registering priority: EqualPriority
Priority type EqualPriority already registered, reusing.
Registering priority: LeastRequestedPriority
Priority type LeastRequestedPriority already registered, reusing.
Registering priority: NodePreferAvoidPodsPriority
Priority type NodePreferAvoidPodsPriority already registered, reusing.
Registering priority: NodeAffinityPriority
Priority type NodeAffinityPriority already registered, reusing.
Creating scheduler with fit predicates 'map[GeneralPredicates:{}]' and priority functions 'map[EqualPriority:{} LeastRequestedPriority:{} NodeAffinityPriority:{} NodePreferAvoidPodsPriority:{} ServiceSpreadingPriority:{}]'Sekarang yang tersisa hanyalah menunjukkan dalam spesifikasi CronJob kita bahwa semua permintaan untuk menjadwalkan podnya harus diproses oleh kube-scheduler baru kita:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...Kesimpulan
Pada akhirnya, kami mendapatkan kube-scheduler tambahan dengan serangkaian kebijakan penjadwalan unik, yang pekerjaannya dipantau langsung oleh kubelet. Selain itu, kami telah menyiapkan pemilihan pemimpin baru di antara pod kube-scheduler kami jika pemimpin lama tidak tersedia karena alasan tertentu.
Aplikasi dan layanan reguler terus dijadwalkan melalui kube-scheduler default, dan semua tugas cron telah sepenuhnya ditransfer ke yang baru. Beban yang dibuat oleh tugas cron sekarang didistribusikan secara merata ke seluruh node. Mengingat sebagian besar tugas cron dijalankan pada node yang sama dengan aplikasi utama proyek, hal ini telah mengurangi risiko perpindahan pod secara signifikan karena kurangnya sumber daya. Setelah memperkenalkan kube-scheduler tambahan, masalah dengan penjadwalan tugas cron yang tidak merata tidak lagi muncul.
Baca juga artikel lainnya di blog kami:
Sumber: www.habr.com