Kube-scheduler is in yntegraal ûnderdiel fan Kubernetes, dy't ferantwurdlik is foar it plannen fan pods oer knopen yn oerienstimming mei spesifisearre belied. Faak hoege wy by de wurking fan in Kubernetes-kluster net nei te tinken oer hokker belied wurdt brûkt om pods te plannen, om't de set fan belied fan 'e standert kube-scheduler geskikt is foar de measte deistige taken. D'r binne lykwols situaasjes wêryn it wichtich is foar ús om it proses fan it tawizen fan pods te fine, en d'r binne twa manieren om dizze taak út te fieren:
- Meitsje in kube-scheduler mei in oanpaste set regels
- Skriuw jo eigen planner en lear it om te wurkjen mei API-tsjinneroanfragen
Yn dit artikel sil ik de útfiering fan it earste punt beskriuwe om it probleem op te lossen fan unjildich skema fan herten op ien fan ús projekten.
In koarte ynlieding oer hoe't kube-scheduler wurket
It is it wurdich foaral op te merken dat kube-scheduler net ferantwurdelik is foar it direkt plannen fan pods - it is allinich ferantwurdlik foar it bepalen fan it knooppunt wêrop de pod pleatst wurdt. Mei oare wurden, it resultaat fan kube-scheduler's wurk is de namme fan 'e knooppunt, dy't it weromkomt nei de API-tsjinner foar in scheduling-fersyk, en dat is wêr't syn wurk einiget.
Earst kompilearret kube-scheduler in list mei knopen wêrop de pod kin wurde pland yn oerienstimming mei it predikaatbelied. Dêrnei krijt elke knooppunt fan dizze list in bepaald oantal punten yn oerienstimming mei it prioriteitsbelied. As gefolch, de knooppunt mei it maksimum oantal punten wurdt selektearre. As d'r knopen binne dy't deselde maksimale skoare hawwe, wurdt in willekeurige selektearre. In list en beskriuwing fan it belied foar predikaten (filtering) en prioriteiten (skoare) is te finen yn .
Beskriuwing fan it probleem lichem
Nettsjinsteande it grutte oantal ferskate Kubernetes-klusters dat by Nixys wurdt ûnderhâlden, tsjinkamen wy earst it probleem fan it plannen fan pods pas koartlyn, doe't ien fan ús projekten in grut oantal periodike taken moast útfiere (~ 100 CronJob-entiteiten). Om de beskriuwing fan it probleem safolle mooglik te ferienfâldigjen, sille wy as foarbyld ien mikrotsjinst nimme, wêryn ien kear yn 'e minút in cron-taak wurdt lansearre, wat in lading op' e CPU skept. Om de cron-taak út te fieren, waarden trije knopen mei absolút identike skaaimerken tawiisd (24 vCPU's op elk).
Tagelyk is it ûnmooglik om mei krektens te sizzen hoe lang de CronJob sil nimme om út te fieren, om't it folume fan ynfiergegevens konstant feroaret. Yn trochsneed, tidens normale wurking fan kube-scheduler, rint elke knooppunt 3-4 taakynstânsjes, dy't ~20-30% fan 'e lading op' e CPU fan elke knooppunt meitsje:
It probleem sels is dat soms cron-taakpods ophâlde te planen op ien fan 'e trije knopen. Dat is, op in stuit wie net ien pod pland foar ien fan 'e knooppunten, wylst op' e oare twa knooppunten 6-8 kopyen fan 'e taak rinnen, wêrtroch ~ 40-60% fan 'e CPU-lading ûntstie:
It probleem kaam werom mei absolút willekeurige frekwinsje en soms korrelearre mei it momint dat in nije ferzje fan de koade waard útrôle.
Troch it kube-scheduler-loggingnivo te ferheegjen nei nivo 10 (-v = 10), begûnen wy op te nimmen hoefolle punten elk knooppunt krige tidens it evaluaasjeproses. Tidens normale planningsoperaasje koe de folgjende ynformaasje wurde sjoen yn 'e 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 100043Dy. beoardielje troch de ynformaasje krigen út de logs, elk fan de knopen skoarde in gelikense oantal lêste punten en in willekeurich ien waard selektearre foar planning. Op it momint fan problematyske planning seagen de logs der sa út:
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 100038Dêrút is te sjen dat ien fan de knopen minder einpunten skoarde as de oaren, en dêrom waard der allinnich plannen útfierd foar de twa knopen dy't de maksimale skoare skoarden. Sa wiene wy der wis fan oertsjûge dat it probleem krekt yn it skema fan de podden leit.
It fierdere algoritme foar it oplossen fan it probleem wie foar ús fanselssprekkend - analysearje de logs, begryp troch hokker prioriteit de knooppunt gjin punten skoarde en, as nedich, oanpasse it belied fan 'e standert kube-scheduler. Lykwols, hjir binne wy konfrontearre mei twa wichtige swierrichheden:
- Op it maksimale loggingsnivo (10) wurde punten wûn allinich foar guon prioriteiten. Yn it boppesteande úttreksel fan logs, kinne jo sjen dat foar alle prioriteiten wjerspegele yn de logs, knooppunten skoare itselde oantal punten yn normale en probleem scheduling, mar it einresultaat yn it gefal fan probleem planning is oars. Sa kinne wy konkludearje dat foar guon prioriteiten it skoaren "efter de skermen" foarkomt, en wy hawwe gjin manier om te begripen foar hokker prioriteit it knooppunt gjin punten krige. Wy beskreaun dit probleem yn detail yn Kubernetes repository op Github. Op it momint fan skriuwen waard in antwurd ûntfongen fan 'e ûntwikkelders dat logging-stipe sil wurde tafoege yn' e Kubernetes v1.15,1.16, 1.17 en XNUMX updates.
- D'r is gjin maklike manier om te begripen mei hokker spesifike set fan belied kube-scheduler op it stuit wurket. Ja, yn dizze list is listed, mar it befettet gjin ynformaasje oer hokker spesifike gewichten wurde tawiisd oan elk fan 'e prioriteiten belied. Jo kinne de gewichten sjen of it belied fan 'e standert kube-scheduler allinich yn .
It is de muoite wurdich op te merken dat wy ienris koenen opnimme dat in knooppunt gjin punten krige neffens it ImageLocalityPriority-belied, dat punten oan in knooppunt takent as it al de ôfbylding hat dy't nedich is om de applikaasje út te fieren. Dat is, op it momint dat in nije ferzje fan 'e applikaasje waard útrôle, koe de cron-taak op twa knooppunten rinne, in nije ôfbylding downloade fan it docker-register nei har, en dus krigen twa knooppunten in hegere einskoare relatyf oan de tredde .
Lykas ik hjirboppe skreau, sjogge wy yn 'e logs gjin ynformaasje oer de evaluaasje fan it ImageLocalityPriority-belied, dus om ús oanname te kontrolearjen, dumpten wy de ôfbylding mei de nije ferzje fan' e applikaasje op 'e tredde knooppunt, wêrnei't skema goed wurke . It wie krekt fanwege it ImageLocalityPriority-belied dat it schedulingprobleem frij seldsum waard waarnommen; faker waard it ferbûn mei wat oars. Fanwege it feit dat wy elk fan 'e belied yn' e list mei prioriteiten fan 'e standert kube-scheduler net folslein debuggen koene, hiene wy ferlet fan fleksibel behear fan pod-scheduling-belied.
Probleemintwurding
Wy woenen dat de oplossing foar it probleem sa spesifyk mooglik wie, dat is, de wichtichste entiteiten fan Kubernetes (hjir bedoele wy de standert kube-scheduler) moatte net feroare wurde. Wy woenen net op it iene plak in probleem oplosse en op in oar plak meitsje. Sa kamen wy by twa opsjes foar it oplossen fan it probleem, dy't waarden oankundige yn 'e ynlieding fan it artikel - it meitsjen fan in ekstra planner of it skriuwen fan jo eigen. De wichtichste eask foar it plannen fan cron-taken is om de lading gelyk te ferdielen oer trije knopen. Dizze eask kin foldien wurde troch besteande kube-scheduler-belied, dus om ús probleem op te lossen hat it gjin punt om jo eigen planner te skriuwen.
Ynstruksjes foar it meitsjen en ynsetten fan in ekstra kube-scheduler wurde beskreaun yn . It like ús lykwols dat de Deployment-entiteit net genôch wie om fouttolerânsje te garandearjen yn 'e wurking fan sa'n krityske tsjinst as kube-scheduler, dus wy besletten om in nije kube-scheduler yn te setten as in Static Pod, dy't direkt kontrolearre wurde soe by Kubelet. Sa hawwe wy de folgjende easken foar de nije kube-scheduler:
- De tsjinst moat wurde ynset as in Static Pod op alle klustermasters
- Fouttolerânsje moat wurde levere yn gefal dat de aktive pod mei kube-scheduler net beskikber is
- De haadprioriteit by planning moat it oantal beskikbere boarnen op it knooppunt wêze (LeastRequestedPriority)
Implementaasje oplossings
It is de muoite wurdich op te merken dat wy alle wurken sille útfiere yn Kubernetes v1.14.7, om't Dit is de ferzje dy't brûkt waard yn it projekt. Litte wy begjinne mei it skriuwen fan in manifest foar ús nije kube-scheduler. Litte wy it standertmanifest (/etc/kubernetes/manifests/kube-scheduler.yaml) as basis nimme en it nei de folgjende foarm bringe:
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-configKoartsein oer de wichtichste feroarings:
- De namme fan de pod en kontener feroare yn kube-scheduler-cron
- Spesifisearre it gebrûk fan havens 10151 en 10159 as de opsje waard definiearre
hostNetwork: trueen wy kinne deselde havens net brûke as de standert kube-scheduler (10251 en 10259) - Mei de parameter --config hawwe wy it konfiguraasjetriem oanjûn wêrmei't de tsjinst begon wurde moat
- Ynstelde mounting fan it konfiguraasjetriem (scheduler-custom.conf) en skemabeliedsbestân (scheduler-custom-policy-config.json) fan 'e host
Ferjit net dat ús kube-scheduler rjochten nedich is lykas de standert. Syn klusterrol bewurkje:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Litte wy no prate oer wat moat wurde befette yn it konfiguraasjetriem en it skemabeliedsbestân:
- Konfiguraasjetriem (scheduler-custom.conf)
Om de standert kube-scheduler-konfiguraasje te krijen, moatte jo de parameter brûke--write-config-tofan . Wy pleatse de resultearjende konfiguraasje yn it bestân /etc/kubernetes/scheduler-custom.conf en ferminderje it nei it folgjende formulier:
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"Koartsein oer de wichtichste feroarings:
- Wy sette schedulerName op de namme fan ús kube-scheduler-cron-tsjinst.
- Yn parameter
lockObjectNamejo moatte ek de namme fan ús tsjinst ynstelle en soargje derfoar dat de parameterleaderElectynsteld op wier (as jo ien masterknooppunt hawwe, kinne jo it ynstelle op falsk). - Spesifisearre it paad nei it bestân mei in beskriuwing fan it skemabelied yn 'e parameter
algorithmSource.
It is it wurdich om in tichterby te sjen op it twadde punt, wêr't wy de parameters foar de kaai bewurkje leaderElection. Om fouttolerânsje te garandearjen, hawwe wy ynskeakele (leaderElect) it proses fan it selektearjen fan in lieder (master) tusken de pods fan ús kube-scheduler mei ien einpunt foar har (resourceLock) neamd kube-scheduler-cron (lockObjectName) yn de kube-systeem nammeromte (lockObjectNamespace). Hoe Kubernetes soarget foar hege beskikberens fan 'e haadkomponinten (ynklusyf kube-scheduler) is te finen yn .
- Planningsbeliedsbestân (scheduler-custom-policy-config.json)
Lykas ik earder skreau, kinne wy útfine hokker spesifike belied de standert kube-scheduler wurket mei allinich troch syn koade te analysearjen. Dat is, wy kinne gjin bestân krije mei skemabelied foar de standert kube-scheduler op deselde wize as in konfiguraasjetriem. Litte wy it skemabelied beskriuwe wêryn wy ynteressearre binne yn it bestân /etc/kubernetes/scheduler-custom-policy-config.json as folget:
{
"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
}Sa, kube-scheduler kompilearret earst in list mei knooppunten dêr't in pod kin wurde pland neffens it GeneralPredicates-belied (dat omfettet in set fan PodFitsResources, PodFitsHostPorts, HostName, en MatchNodeSelector-belied). En dan wurdt elke knooppunt evaluearre yn oerienstimming mei de set fan belied yn 'e prioriteitenarray. Om de betingsten fan ús taak te ferfoljen, hawwe wy beskôge dat sa'n set fan belied de optimale oplossing wêze soe. Lit my jo herinnerje dat in set fan belied mei har detaillearre beskriuwingen beskikber is yn . Om jo taak te foltôgjen, kinne jo gewoan de set fan brûkte belied feroarje en passende gewichten oan har tawize.
Litte wy it manifest fan 'e nije kube-scheduler, dy't wy oan it begjin fan it haadstik makke hawwe, neame kube-scheduler-custom.yaml en pleatse it yn it folgjende paad /etc/kubernetes/manifests op trije masterknooppunten. As alles goed is dien, sil Kubelet in pod op elke knooppunt lansearje, en yn 'e logs fan ús nije kube-scheduler sille wy ynformaasje sjen dat ús beliedsbestân mei sukses tapast is:
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:{}]'No bliuwt alles oer om yn 'e spec fan ús CronJob oan te jaan dat alle oanfragen foar it plannen fan syn pods moatte wurde ferwurke troch ús nije kube-scheduler:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...konklúzje
Uteinlik krigen wy in ekstra kube-scheduler mei in unike set fan planningbelied, wêrfan it wurk direkt wurdt kontrolearre troch de kubelet. Dêrnjonken hawwe wy de ferkiezing fan in nije lieder ynsteld tusken de podden fan ús kube-scheduler foar it gefal dat de âlde lieder om ien of oare reden net beskikber wurdt.
Reguliere applikaasjes en tsjinsten wurde fierder pland fia de standert kube-scheduler, en alle cron-taken binne folslein oerbrocht nei de nije. De lading makke troch cron-taken is no lyklik ferdield oer alle knopen. Yn betinken nommen dat de measte cron-taken wurde útfierd op deselde knopen as de haadapplikaasjes fan it projekt, hat dit it risiko fan it ferpleatsen fan pods signifikant fermindere fanwegen gebrek oan boarnen. Nei it yntrodusearjen fan de ekstra kube-scheduler, ûntstiene problemen mei unjildich skema fan cron-taken net mear.
Lês ek oare artikels op ús blog:
Boarne: www.habr.com