Kube-scheduler hè un cumpunente integrale di Kubernetes, chì hè rispunsevule per scheduling pods attraversu i nodi in cunfurmità cù e pulitiche specificate. Spessu, durante l'operazione di un cluster Kubernetes, ùn avemu micca bisognu di pensà à quali pulitiche sò aduprate per pianificà pods, postu chì u settore di pulitiche di u kube-scheduler predeterminatu hè adattatu per a maiò parte di i travaglii di ogni ghjornu. Tuttavia, ci sò situazioni quandu hè impurtante per noi di sintonizà u prucessu di allocazione di pods, è ci sò duie manere di rializà stu compitu:
- Crea un kube-scheduler cù un set di reguli persunalizati
- Scrivite u vostru propiu pianificatore è insegnallu à travaglià cù e dumande di u servitore API
In questu articulu, descriveraghju l'implementazione di u primu puntu per risolve u prublema di a pianificazione irregulare di i fugliali nantu à unu di i nostri prughjetti.
Una breve introduzione à cumu funziona u kube-scheduler
Hè da nutà soprattuttu u fattu chì u kube-scheduler ùn hè micca rispunsevuli di scheduling direttamente pods - hè solu rispunsevuli di determinà u node nantu à quale si mette u pod. In altri palori, u risultatu di u travagliu di kube-scheduler hè u nome di u node, chì torna à u servitore API per una dumanda di scheduling, è hè quì chì u so travagliu finisci.
Prima, kube-scheduler compila una lista di nodi nantu à quale u pod pò esse pianificatu in cunfurmità cù e pulitiche di predicati. Dopu, ogni node da sta lista riceve un certu numaru di punti in cunfurmità cù e pulitiche di priorità. In u risultatu, u node cù u massimu di punti hè sceltu. Se ci sò nodi chì anu u listessu puntuatu massimu, hè sceltu un aleatoriu. Una lista è una descrizzione di e pulitiche di predicati (filtrazione) è di priorità (score) ponu esse truvate in .
Descrizzione di u corpu prublema
Malgradu u gran numaru di diversi clusters Kubernetes chì sò stati manteni in Nixys, avemu scontru prima u prublema di scheduling pods solu di pocu tempu, quandu unu di i nostri prughjetti avia bisognu di eseguisce un gran numaru di attività periodiche (~ 100 entità CronJob). Per simplificà a descrizzione di u prublema quant'è pussibule, pigliemu cum'è un esempiu un microserviziu, in u quale un compitu cron hè lanciatu una volta per minutu, creendu una carica nantu à u CPU. Per eseguisce u compitu cron, sò stati attribuiti trè nodi cù caratteristiche assolutamente identiche (24 vCPU per ognunu).
À u listessu tempu, hè impussibile di dì cù precisione quantu tempu u CronJob duverà esse eseguitu, postu chì u voluminu di dati di input hè in constantemente cambiante. In media, durante l'operazione normale di kube-scheduler, ogni nodu esegue 3-4 casi di travagliu, chì creanu ~ 20-30% di a carica nantu à u CPU di ogni nodu:
U prublema stessu hè chì qualchì volta i pods di attività cron anu cessatu di esse pianificatu nantu à unu di i trè nodi. Vale à dì, in un certu puntu in u tempu, ùn era micca pianificatu un solu pod per unu di i nodi, mentre chì in l'altri dui nodi 6-8 copie di u compitu eranu in esecuzione, creendu ~ 40-60% di a carica di CPU:
U prublema si ripresentò cù una frequenza assolutamente aleatoria è in ocasioni correlate cù u mumentu chì una nova versione di u codice hè stata liberata.
Aumentendu u livellu di logu di u kube-scheduler à u nivellu 10 (-v = 10), avemu cuminciatu à registrà quanti punti ogni node guadagnatu durante u prucessu di valutazione. Durante l'operazione di pianificazione normale, l'infurmazioni seguenti ponu esse vistu in i logs:
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 100043Quelli. à ghjudicà da l'infurmazioni ottenute da i logs, ognuna di i nodi hà puntuatu un numeru uguale di punti finali è un aleatoriu hè statu sceltu per a pianificazione. À u mumentu di a pianificazione problematica, i logs parevanu cusì:
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 100038Da quale si pò vede chì unu di i nodi hà puntuatu menu punti finali cà l'altri, è dunque a pianificazione hè stata realizata solu per i dui nodi chì anu puntuatu u puntu massimu. Cusì, eramu definitu cunvinta chì u prublema si trova precisamente in a scheduling of the pods.
L'algoritmu ulteriore per risolve u prublema era evidenti per noi - analizà i logs, capisce da quale priorità u node ùn hà micca puntuatu punti è, se ne necessariu, aghjustate e pulitiche di u kube-scheduler predeterminatu. In ogni casu, quì ci hè affruntatu cù duie difficultà impurtanti:
- À u livellu massimu di logging (10), i punti guadagnati solu per alcune priorità sò riflessi. In l'estrattu sopra di i logs, pudete vede chì per tutte e priurità riflesse in i logs, i nodi puntuanu u listessu numaru di punti in a pianificazione normale è di prublema, ma u risultatu finali in u casu di a pianificazione di u prublema hè diversu. Cusì, pudemu cuncludi chì per certi priurità, u puntuazione si trova "darreri à l'scena", è ùn avemu micca manera di capisce per quale priorità u node ùn hà micca ottinutu punti. Avemu descrittu stu prublema in detail in Repository Kubernetes nantu à Github. À u mumentu di a scrittura, una risposta hè stata ricevuta da i sviluppatori chì u supportu di logu serà aghjuntu in l'aghjurnamenti Kubernetes v1.15,1.16, 1.17 è XNUMX.
- Ùn ci hè micca un modu faciule per capisce quale settore specificu di pulitiche cube-scheduler travaglia attualmente. Iè, in sta lista hè listata, ma ùn cuntene infurmazione nantu à quali pesi specifichi sò attribuiti à ognuna di e pulitiche di priorità. Pudete vede i pesi o edità e pulitiche di u kube-scheduler predeterminatu solu in .
Hè da nutà chì una volta avemu pussutu registrà chì un node ùn hà micca ricevutu punti secondu a pulitica ImageLocalityPriority, chì attribuisce punti à un node s'ellu hà digià l'imaghjini necessarii per eseguisce l'applicazione. Vale à dì, à u mumentu chì una nova versione di l'applicazione hè stata lanciata, u compitu di cron hà sappiutu di eseguisce nantu à dui nodi, scarichendu una nova maghjina da u registru docker à elli, è cusì dui nodi anu ricivutu un puntu finale più altu in quantu à u terzu. .
Cumu l'aghju scrittu sopra, in i logs ùn vedemu micca infurmazione nantu à a valutazione di a pulitica ImageLocalityPriority, cusì per verificà a nostra supposizione, avemu scaricatu l'imaghjini cù a nova versione di l'applicazione nantu à u terzu node, dopu chì a pianificazione hà travagliatu bè. . Hè stata precisamente per via di a pulitica ImageLocalityPriority chì u prublema di scheduling hè statu osservatu abbastanza raramente; più spessu era assuciatu cù qualcosa d'altru. A causa di u fattu chì ùn pudemu micca debug cumplettamente ognuna di e pulitiche in a lista di priorità di u kube-scheduler predeterminatu, avemu avutu bisognu di una gestione flessibile di e pulitiche di pianificazione di pod.
Formulazione di u prublema
Vulemu chì a suluzione à u prublema sia u più specifica pussibule, vale à dì, l'entità principali di Kubernetes (quì significhemu u kube-scheduler predeterminatu) ùn deve esse micca cambiatu. Ùn vulemu micca risolve un prublema in un locu è creà in un altru. Cusì, avemu ghjuntu à duie opzioni per risolve u prublema, chì sò stati annunziati in l'intruduzioni à l'articulu - creà un pianificatore supplementu o scrive u vostru propiu. U requisitu principalu per a pianificazione di e funzioni cron hè di distribuisce a carica uniformemente in trè nodi. Questa esigenza pò esse soddisfatta da e pulitiche di kube-scheduler esistenti, cusì per risolve u nostru prublema ùn ci hè nunda di scrive u vostru propiu pianificatore.
Istruzzioni per a creazione è l'implementazione di un kube-scheduler supplementu sò descritte in . Tuttavia, ci pareva chì l'entità di Deployment ùn era micca abbastanza per assicurà a tolleranza di difetti in l'operazione di un serviziu cusì criticu cum'è kube-scheduler, cusì avemu decisu di implementà un novu kube-scheduler cum'è un Static Pod, chì seria monitoratu direttamente. da Kubelet. Cusì, avemu i seguenti requisiti per u novu kube-scheduler:
- U serviziu deve esse implementatu cum'è Pod Static in tutti i maestri di cluster
- A tolleranza di difetti deve esse furnita in casu chì u pod attivu cù u kube-scheduler ùn hè micca dispunibule
- A priorità principale quandu a pianificazione deve esse u numeru di risorse dispunibili nantu à u node (LeastRequestedPriority)
Implementazione di suluzione
Hè da nutà subitu chì avemu da fà tuttu u travagliu in Kubernetes v1.14.7, perchè Questa hè a versione chì hè stata utilizata in u prugettu. Cuminciamu scrivendu un manifestu per u nostru novu kube-scheduler. Pigliemu u manifestu predeterminatu (/etc/kubernetes/manifests/kube-scheduler.yaml) cum'è una basa è purtemu à a forma seguente:
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-configIn breve nantu à i cambiamenti principali:
- Cambiatu u nome di u pod è u containeru in kube-scheduler-cron
- Specificatu l'usu di i porti 10151 è 10159 cum'è l'opzione hè stata definita
hostNetwork: trueè ùn pudemu micca aduprà i stessi porti cum'è u kube-scheduler predeterminatu (10251 è 10259) - Utilizendu u paràmetru --config, avemu specificatu u schedariu di cunfigurazione cù quale u serviziu deve esse cuminciatu
- Muntamentu cunfiguratu di u schedariu di cunfigurazione (scheduler-custom.conf) è u schedariu di pulitica di pianificazione (scheduler-custom-policy-config.json) da l'ospite
Ùn vi scurdate chì u nostru kube-scheduler hà bisognu di diritti simili à u predeterminatu. Edite u so rolu di cluster:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Avà parlemu di ciò chì deve esse cuntenutu in u schedariu di cunfigurazione è u schedariu di pulitica di pianificazione:
- File di cunfigurazione (scheduler-custom.conf)
Per ottene a cunfigurazione predeterminata di kube-scheduler, duvete aduprà u paràmetru--write-config-toиз . Puderemu a cunfigurazione resultanti in u schedariu /etc/kubernetes/scheduler-custom.conf è a riduzzione à a seguente forma:
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"In breve nantu à i cambiamenti principali:
- Avemu stabilitu schedulerName à u nome di u nostru serviziu kube-scheduler-cron.
- In u paràmetru
lockObjectNamevi dinù bisognu di definisce u nomu di u nostru serviziu è verificate chì u paràmetruleaderElectstabilitu à veru (se avete un nodu maestru, pudete stabilisce à false). - Specificatu u percorsu à u schedariu cù una descrizzione di e pulitiche di pianificazione in u paràmetru
algorithmSource.
Hè vale a pena piglià un ochju più vicinu à u sicondu puntu, induve edità i paràmetri per a chjave leaderElection. Per assicurà a tolleranza di difetti, avemu attivatu (leaderElect) u prucessu di selezziunà un capu (maestru) trà i pods di u nostru kube-scheduler usendu un unicu endpoint per elli (resourceLock) chjamatu kube-scheduler-cron (lockObjectName) in u spaziu di nomi kube-system (lockObjectNamespace). Cumu Kubernetes assicura una alta dispunibilità di i cumpunenti principali (cumpresu u kube-scheduler) pò esse truvatu in .
- File di pulitica di pianificazione (scheduler-custom-policy-config.json)
Cum'è aghju scrittu prima, pudemu scopre quali pulitiche specifiche u kube-scheduler predeterminatu travaglia solu analizendu u so codice. Questu hè, ùn pudemu micca ottene un schedariu cù pulitiche di pianificazione per u kube-scheduler predeterminatu in u listessu modu cum'è un schedariu di cunfigurazione. Descrivimu e pulitiche di pianificazione chì ci interessanu in u schedariu /etc/kubernetes/scheduler-custom-policy-config.json cum'è seguente:
{
"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
}Cusì, kube-scheduler prima compila una lista di nodi à quale un pod pò esse pianificatu secondu a pulitica GeneralPredicates (chì include un settore di e pulitiche PodFitsResources, PodFitsHostPorts, HostName è MatchNodeSelector). E poi ogni node hè evaluatu in cunfurmità cù l'inseme di pulitiche in l'array di priorità. Per cumpiendu e cundizioni di u nostru compitu, avemu cunsideratu chì un tali settore di pulitiche seria a suluzione ottima. Lasciami ricurdà chì un inseme di pulitiche cù e so descrizzioni dettagliate hè dispunibule in . Per fà u vostru compitu, pudete solu cambià l'inseme di pulitiche utilizati è assignà pesi adatti à elli.
Chjamemu u manifestu di u novu kube-scheduler, chì avemu creatu à u principiu di u capitulu, kube-scheduler-custom.yaml è u postu in u percorsu seguenti /etc/kubernetes/manifests nantu à trè nodi maestri. Se tuttu hè fattu bè, Kubelet lanciarà un pod in ogni nodu, è in i logs di u nostru novu kube-scheduler vedemu l'infurmazioni chì u nostru schedariu di pulitica hè stata applicata bè:
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:{}]'Avà tuttu ciò chì resta hè di indicà in a specificazione di u nostru CronJob chì tutte e dumande per a pianificazione di i so pods deve esse trattate da u nostru novu kube-scheduler:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...cunchiusioni
In ultimamente, avemu un kube-scheduler supplementu cù un inseme unicu di pulitiche di pianificazione, u travagliu di quale hè monitoratu direttamente da u kubelet. Inoltre, avemu stabilitu l'elezzione di un novu capu trà i baccelli di u nostru kube-scheduler in casu chì u vechju capu diventa indisponibile per una certa ragione.
L'applicazioni è i servizii rigulari cuntinueghjanu à esse pianificati per mezu di u kube-scheduler predeterminatu, è tutti i travaglii cron sò stati completamente trasferiti à u novu. A carica creata da i travaglii cron hè avà distribuitu uniformemente in tutti i nodi. Cunsiderendu chì a maiò parte di e funzioni cron sò eseguite nantu à i stessi nodi cum'è l'applicazioni principali di u prugettu, questu hà riduciutu significativamente u risicu di muvimenti pods per mancanza di risorse. Dopu l'introduzione di u kube-scheduler supplementu, i prublemi cù una pianificazione irregolare di e funzioni cron ùn sò più sorgi.
Leghjite ancu altri articuli nantu à u nostru blog:
Source: www.habr.com