Kube-skeduleerder is 'n integrale komponent van Kubernetes, wat verantwoordelik is vir die skedulering van peule oor nodusse in ooreenstemming met gespesifiseerde beleide. Dikwels, tydens die werking van 'n Kubernetes-kluster, hoef ons nie te dink oor watter beleide gebruik word om peule te skeduleer nie, aangesien die stel beleide van die verstekkube-skeduleerder geskik is vir die meeste alledaagse take. Daar is egter situasies wanneer dit vir ons belangrik is om die proses van die toekenning van peule fyn in te stel, en daar is twee maniere om hierdie taak uit te voer:
- Skep 'n kube-skeduleerder met 'n pasgemaakte stel reëls
- Skryf jou eie skeduleerder en leer dit om met API-bedienerversoeke te werk
In hierdie artikel sal ek die implementering van die eerste punt beskryf om die probleem van ongelyke skedulering van vuurherde op een van ons projekte op te los.
'n Kort inleiding tot hoe kube-skeduleerder werk
Dit is veral die moeite werd om te let op die feit dat kube-skeduleerder nie verantwoordelik is vir die direk skedulering van peule nie - dit is slegs verantwoordelik vir die bepaling van die nodus waarop die peul geplaas moet word. Met ander woorde, die resultaat van kube-skeduleerder se werk is die naam van die nodus, wat dit na die API-bediener terugstuur vir 'n skeduleringversoek, en dit is waar sy werk eindig.
Eerstens stel kube-skeduleerder 'n lys van nodusse saam waarop die peul geskeduleer kan word in ooreenstemming met die predikaatbeleide. Vervolgens ontvang elke nodus van hierdie lys 'n sekere aantal punte in ooreenstemming met die prioriteitsbeleide. As gevolg hiervan word die nodus met die maksimum aantal punte gekies. As daar nodusse is wat dieselfde maksimum telling het, word 'n ewekansige een gekies. 'n Lys en beskrywing van die predikate (filtrering) en prioriteite (telling) beleide kan gevind word in .
Beskrywing van die probleemliggaam
Ten spyte van die groot aantal verskillende Kubernetes-klusters wat by Nixys in stand gehou word, het ons eers onlangs die probleem ondervind om peule te skeduleer, toe een van ons projekte 'n groot aantal periodieke take moes uitvoer (~ 100 CronJob-entiteite). Om die beskrywing van die probleem soveel as moontlik te vereenvoudig, sal ons as voorbeeld een mikrodiens neem, waarbinne 'n cron-taak een keer per minuut geloods word, wat 'n mate van las op die SVE skep. Om die cron-taak uit te voer, is drie nodusse met absoluut identiese eienskappe toegeken (24 vCPU's op elk).
Terselfdertyd is dit onmoontlik om met akkuraatheid te sê hoe lank die CronJob sal neem om uit te voer, aangesien die volume insetdata voortdurend verander. Gemiddeld, tydens normale werking van kube-skeduleerder, loop elke nodus 3-4 werkgevalle, wat ~20-30% van die las op die SVE van elke nodus skep:
Die probleem self is dat cron-taakpeule soms nie meer op een van die drie nodusse geskeduleer is nie. Dit wil sê, op 'n sekere tydstip is nie 'n enkele peul vir een van die nodusse beplan nie, terwyl op die ander twee nodusse 6-8 kopieë van die taak aan die gang was, wat ~40-60% van die SVE-lading geskep het:
Die probleem het met absoluut ewekansige frekwensie herhaal en soms gekorreleer met die oomblik dat 'n nuwe weergawe van die kode ontplooi is.
Deur die kube-skeduleerder-logvlak na vlak 10 (-v=10) te verhoog, het ons begin om aan te teken hoeveel punte elke nodus tydens die evalueringsproses verwerf het. Tydens normale beplanning kan die volgende inligting in die logboeke gesien word:
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 100043Dié. te oordeel aan die inligting wat uit die logboeke verkry is, het elk van die nodusse 'n gelyke aantal finale punte behaal en 'n ewekansige een is vir beplanning gekies. Ten tyde van problematiese beplanning het die logs soos volg gelyk:
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 100038Waaruit gesien kan word dat een van die nodusse minder finale punte as die ander behaal het, en daarom is beplanning slegs uitgevoer vir die twee nodusse wat die maksimum telling behaal het. Ons was dus beslis oortuig dat die probleem juis in die skedulering van die peule lê.
Die verdere algoritme om die probleem op te los was vir ons voor die hand liggend - ontleed die logs, verstaan met watter prioriteit die nodus nie punte behaal het nie en, indien nodig, pas die beleid van die verstek kube-skeduleerder aan. Hier kom ons egter voor twee beduidende probleme te staan:
- Op die maksimum logvlak (10) word punte wat slegs vir sekere prioriteite behaal is, weerspieël. In die bogenoemde uittreksel van logs, kan jy sien dat vir alle prioriteite wat in die logs weerspieël word, nodusse dieselfde aantal punte in normale en probleemskedulering behaal, maar die finale resultaat in die geval van probleembeplanning is anders. Ons kan dus tot die gevolgtrekking kom dat vir sommige prioriteite telling "agter die skerms" plaasvind, en ons het geen manier om te verstaan vir watter prioriteit die nodus nie punte gekry het nie. Ons het hierdie probleem in detail beskryf in Kubernetes-bewaarplek op Github. Met die skryf hiervan is 'n antwoord van die ontwikkelaars ontvang dat aantekenondersteuning bygevoeg sal word in die Kubernetes v1.15,1.16, 1.17 en XNUMX-opdaterings.
- Daar is geen maklike manier om te verstaan met watter spesifieke stel beleide kube-skeduleerder tans werk nie. Ja, in hierdie lys is gelys, maar dit bevat nie inligting oor watter spesifieke gewigte aan elk van die prioriteitsbeleide toegeken word nie. Jy kan die gewigte sien of die beleide van die verstek kube-skeduleerder wysig slegs in .
Dit is opmerklik dat ons een keer kon aanteken dat 'n nodus nie punte ontvang het volgens die ImageLocalityPriority-beleid nie, wat punte aan 'n nodus toeken as dit reeds die beeld het wat nodig is om die toepassing te laat loop. Dit wil sê, toe 'n nuwe weergawe van die toepassing ontplooi is, het die cron-taak daarin geslaag om op twee nodusse te hardloop, 'n nuwe prent vanaf die docker-register na hulle af te laai, en dus het twee nodusse 'n hoër finale telling gekry in vergelyking met die derde .
Soos ek hierbo geskryf het, sien ons nie in die logboeke inligting oor die evaluering van die ImageLocalityPriority-beleid nie, so om ons aanname na te gaan, het ons die prent met die nuwe weergawe van die toepassing op die derde nodus gegooi, waarna skedulering korrek gewerk het . Dit was juis as gevolg van die ImageLocalityPriority-beleid dat die skeduleringsprobleem redelik selde waargeneem is; meer dikwels is dit met iets anders geassosieer. Weens die feit dat ons nie elk van die beleide in die lys van prioriteite van die verstek kube-skeduleerder ten volle kon ontfout nie, het ons 'n behoefte gehad aan buigsame bestuur van pod-skeduleringbeleide.
Probleemstelling
Ons wou hê die oplossing vir die probleem moet so spesifiek as moontlik wees, dit wil sê die hoofentiteite van Kubernetes (hier bedoel ons die verstek kube-skeduleerder) moet onveranderd bly. Ons wou nie 'n probleem op een plek oplos en dit op 'n ander skep nie. Ons het dus by twee opsies gekom om die probleem op te los, wat in die inleiding tot die artikel aangekondig is - die skep van 'n bykomende skeduleerder of skryf u eie. Die hoofvereiste vir die skedulering van cron-take is om die las eweredig oor drie nodusse te versprei. Hierdie vereiste kan deur bestaande kube-skeduleerderbeleide bevredig word, so om ons probleem op te los is dit geen sin om jou eie skeduleerder te skryf nie.
Instruksies vir die skep en ontplooiing van 'n bykomende kube-skeduleerder word beskryf in . Dit het egter vir ons gelyk of die Ontplooiingsentiteit nie genoeg was om fouttoleransie in die werking van so 'n kritieke diens soos kube-skeduleerder te verseker nie, daarom het ons besluit om 'n nuwe kube-skeduleerder as 'n Static Pod te ontplooi, wat direk gemonitor sou word deur Kubelet. Ons het dus die volgende vereistes vir die nuwe kube-skeduleerder:
- Die diens moet as 'n Static Pod op alle klustermeesters ontplooi word
- Foutverdraagsaamheid moet verskaf word ingeval die aktiewe peul met kube-skeduleerder nie beskikbaar is nie
- Die hoofprioriteit by beplanning moet die aantal beskikbare hulpbronne op die nodus wees (LeastRequestedPriority)
Implementering oplossings
Dit is die moeite werd om dadelik daarop te let dat ons alle werk in Kubernetes v1.14.7 sal uitvoer, want Dit is die weergawe wat in die projek gebruik is. Kom ons begin deur 'n manifes vir ons nuwe kube-skeduleerder te skryf. Kom ons neem die verstekmanifes (/etc/kubernetes/manifests/kube-scheduler.yaml) as basis en bring dit na die volgende vorm:
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-configKortliks oor die belangrikste veranderinge:
- Het die naam van die peul en houer verander na kube-scheduler-cron
- Spesifiseer die gebruik van poorte 10151 en 10159 soos die opsie gedefinieer is
hostNetwork: trueen ons kan nie dieselfde poorte gebruik as die verstek kube-skeduleerder (10251 en 10259) - Met die --config-parameter het ons die konfigurasielêer gespesifiseer waarmee die diens begin moet word
- Gekonfigureerde montering van die konfigurasielêer (skeduler-custom.conf) en skeduleringsbeleidlêer (skeduler-custom-policy-config.json) vanaf die gasheer
Moenie vergeet dat ons kube-skeduleerder regte soortgelyk aan die verstek een sal benodig nie. Wysig sy groeprol:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Kom ons praat nou oor wat in die konfigurasielêer en die skeduleringsbeleidlêer vervat moet word:
- Konfigurasielêer (skeduler-custom.conf)
Om die verstek kube-skeduleerder-konfigurasie te verkry, moet jy die parameter gebruik--write-config-tovan . Ons sal die gevolglike konfigurasie in die lêer /etc/kubernetes/scheduler-custom.conf plaas en dit na die volgende vorm verminder:
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"Kortliks oor die belangrikste veranderinge:
- Ons stel skeduleerderNaam op die naam van ons kube-skeduler-cron-diens.
- In die parameter
lockObjectNamejy moet ook die naam van ons diens stel en seker maak dat die parameterleaderElectstel op waar (as jy een hoofnodus het, kan jy dit op vals stel). - Spesifiseer die pad na die lêer met 'n beskrywing van die skeduleringsbeleide in die parameter
algorithmSource.
Dit is die moeite werd om die tweede punt nader te kyk, waar ons die parameters vir die sleutel wysig leaderElection. Om fouttoleransie te verseker, het ons (leaderElect) die proses om 'n leier (meester) tussen die peule van ons kube-skeduleerder te kies deur 'n enkele eindpunt daarvoor te gebruik (resourceLock) genaamd kube-skeduleerder-cron (lockObjectName) in die kube-stelsel naamruimte (lockObjectNamespace). Hoe Kubernetes hoë beskikbaarheid van die hoofkomponente (insluitend kube-skeduleerder) verseker, kan gevind word in .
- Skeduleringbeleidlêer (skeduler-custom-policy-config.json)
Soos ek vroeër geskryf het, kan ons uitvind met watter spesifieke beleide die standaard kube-skeduleerder werk slegs deur sy kode te analiseer. Dit wil sê, ons kan nie 'n lêer kry met skeduleringsbeleide vir die verstek kube-skeduleerder op dieselfde manier as 'n konfigurasielêer nie. Kom ons beskryf die skeduleringsbeleide waarin ons belangstel in die /etc/kubernetes/scheduler-custom-policy-config.json-lêer soos volg:
{
"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
}Kube-skeduleerder stel dus eers 'n lys nodusse saam waarheen 'n peul geskeduleer kan word volgens die GeneralPredicates-beleid (wat die stel PodFitsResources-, PodFitsHostPorts-, HostName- en MatchNodeSelector-beleide insluit). En dan word elke nodus geëvalueer in ooreenstemming met die stel beleide in die prioriteitsskikking. Om aan die voorwaardes van ons taak te voldoen, het ons van mening dat so 'n stel beleide die optimale oplossing sou wees. Laat ek jou daaraan herinner dat 'n stel beleide met hul gedetailleerde beskrywings beskikbaar is in . Om jou taak uit te voer, kan jy eenvoudig die stel beleide wat gebruik word verander en toepaslike gewigte daaraan toeken.
Kom ons noem die manifes van die nuwe kube-skeduleerder, wat ons aan die begin van die hoofstuk geskep het, kube-scheduler-custom.yaml en plaas dit in die volgende pad /etc/kubernetes/manifests op drie meesternodusse. As alles korrek gedoen word, sal Kubelet 'n pod op elke nodus begin, en in die logs van ons nuwe kube-skeduleerder sal ons inligting sien dat ons beleidlêer suksesvol toegepas 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:{}]'Al wat nou oorbly, is om in die spesifikasie van ons CronJob aan te dui dat alle versoeke vir die skedulering van sy peule deur ons nuwe kube-skeduleerder verwerk moet word:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...Gevolgtrekking
Uiteindelik het ons 'n bykomende kube-skeduleerder gekry met 'n unieke stel skeduleringsbeleide, waarvan die werk direk deur die kubelet gemonitor word. Daarbenewens het ons die verkiesing van 'n nuwe leier tussen die peule van ons kube-skeduleerder opgestel ingeval die ou leier om een of ander rede onbeskikbaar raak.
Gereelde toepassings en dienste word steeds geskeduleer deur die verstek kube-skeduleerder, en alle cron-take is heeltemal na die nuwe een oorgedra. Die las wat deur cron-take geskep word, is nou eweredig oor alle nodusse versprei. As in ag geneem word dat die meeste van die cron-take op dieselfde nodusse as die hooftoepassings van die projek uitgevoer word, het dit die risiko om peule te verskuif aansienlik verminder weens 'n gebrek aan hulpbronne. Nadat die bykomende kube-skeduleerder bekendgestel is, het probleme met ongelyke skedulering van cron-take nie meer ontstaan nie.
Lees ook ander artikels op ons blog:
Bron: will.com