Kube-scheduler Kubernetes-en osagai integrala da, nodoetan pods-ak zehaztutako politiken arabera antolatzeaz arduratzen dena. Askotan, Kubernetes kluster baten funtzionamenduan zehar, ez dugu pentsatu behar zein politika erabiltzen diren pod-ak programatzeko, kube-scheduler lehenetsiaren politika multzoa eguneroko zeregin gehienetarako egokia baita. Hala ere, badaude lekak esleitzeko prozesua finkatzea garrantzitsua zaigun egoerak, eta zeregin hori betetzeko bi modu daude:
- Sortu kube-scheduler arau multzo pertsonalizatu batekin
- Idatzi zure programatzailea eta irakatsi API zerbitzariaren eskaerekin lan egiten
Artikulu honetan, lehen puntuaren ezarpena deskribatuko dut gure proiektuetako batean sutegien programazio irregularren arazoa konpontzeko.
Kube-scheduler-ek nola funtzionatzen duen ezagutzeko sarrera laburra
Nabarmentzekoa da bereziki kube-scheduler-ek ez duela lekak zuzenean antolatzeaz arduratzen; baizik eta lekak jartzeko nodoa zehazteaz arduratzen da. Beste era batera esanda, kube-scheduler-en lanaren emaitza nodoaren izena da, API zerbitzariari itzultzen diona programazio eskaera baterako, eta hor amaitzen da bere lana.
Lehenik eta behin, kube-scheduler-ek nodoen zerrenda bat osatzen du, zeinetan pod-a programatu daitekeen predikatuen politiken arabera. Ondoren, zerrenda honetako nodo bakoitzak puntu kopuru jakin bat jasotzen du lehentasunen politiken arabera. Ondorioz, puntu kopuru handiena duen nodoa hautatzen da. Puntuazio maximo bera duten nodoak badaude, ausazko bat hautatzen da. Predikatuen (iragazkia) eta lehentasunen (puntuazioa) politiken zerrenda eta deskribapena hemen aurki daitezke .
Arazoaren gorputzaren deskribapena
Nixys-en Kubernetes kluster asko mantentzen diren arren, duela gutxi aurkitu genuen pod-ak antolatzeko arazoa, gure proiektuetako batek aldizkako zeregin ugari exekutatu behar zituenean (~ 100 CronJob entitate). Arazoaren deskribapena ahalik eta gehien sinplifikatzeko, mikrozerbitzu bat hartuko dugu adibide gisa, zeinaren barruan cron ataza bat minutuan behin abiarazten den, CPUan kargaren bat sortuz. Cron zeregina exekutatzeko, ezaugarri guztiz berdinak dituzten hiru nodo esleitu ziren (24 vCPU bakoitzean).
Aldi berean, ezinezkoa da zehaztasunez esan CronJob-ek zenbat denbora beharko duen exekutatzeko, sarrerako datuen bolumena etengabe aldatzen ari baita. Batez beste, kube-scheduler-en funtzionamendu arruntean, nodo bakoitzak 3-4 lan-instantzia exekutatzen ditu, eta horrek kargaren % 20-30 sortzen du nodo bakoitzaren CPUan:
Arazoa bera da batzuetan cron task pods-ek hiru nodoetako batean programatzeari uzten diotela. Hau da, denboraren batean, ez zen pod bakar bat planifikatu nodoetako batean, beste bi nodoetan zereginaren 6-8 kopia exekutatzen ari ziren bitartean, CPU kargaren % 40-60 sortuz:
Arazoa guztiz ausazko maiztasunarekin errepikatu zen eta noizean behin kodearen bertsio berri bat zabaldu zen momentuarekin erlazionatu zen.
Kube-scheduler erregistro-maila 10. mailara igoz (-v=10), ebaluazio-prozesuan nodo bakoitzak zenbat puntu irabazi zituen erregistratzen hasi ginen. Plangintza-eragiketa arruntean, informazio hau ikus zitekeen erregistroetan:
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 100043Horiek. Erregistroetatik lortutako informazioa ikusita, nodo bakoitzak azken puntu kopuru berdina lortu zuen eta ausazko bat aukeratu zen plangintzarako. Plangintza arazotsuaren garaian, erregistroak honelakoak ziren:
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 100038Hortik ikusten da nodoetako batek besteek baino azken puntu gutxiago lortu zituela, eta, beraz, planifikazioa gehienezko puntuazioa lortu zuten bi nodoentzat bakarrik egin zen. Horrela, zalantzarik gabe sinetsita geunden arazoa leken programazioan dagoela.
Arazoa konpontzeko algoritmo gehiago begi-bistakoa zen guretzat: erregistroak aztertu, nodoak zein lehentasunen arabera lortu ez zituen puntuak eta, behar izanez gero, kube-scheduler lehenetsiaren politikak egokitu. Dena den, hemen bi zailtasun nabarmen ditugu:
- Erregistro gehieneko mailan (10), lehentasun batzuetarako soilik lortutako puntuak islatzen dira. Erregistroen goiko zatian, erregistroetan islatutako lehentasun guztientzat, nodoek puntu kopuru bera lortzen dutela normalean eta arazoen planifikazioan, baina arazoen plangintzaren kasuan, azken emaitza desberdina da. Horrela, ondoriozta dezakegu lehentasun batzuetarako puntuazioa "eszenaren atzean" gertatzen dela, eta ez dugula nodoak zein lehentasuntarako punturik lortu ez duen ulertzeko modurik. Arazo hau xehetasunez deskribatu dugu Kubernetes biltegia Github-en. Idazteko unean, garatzaileen erantzuna jaso zen Kubernetes v1.15,1.16, 1.17 eta XNUMX eguneraketetan erregistro-laguntza gehituko dela.
- Ez dago modu errazik kube-scheduler-ek zein politika multzo zehatzekin lan egiten duen ulertzeko. Bai, barruan zerrenda hori zerrendatuta dago, baina ez du lehentasunen politika bakoitzari zein pisu zehatz esleitzen zaizkion buruzko informaziorik. Kube-scheduler lehenetsiaren pisuak edo edita ditzakezu soilik hemen .
Aipatzekoa da behin nodo batek ez zuela punturik jaso ImageLocalityPriority politikaren arabera erregistratu ahal izan genuela, nodo bati puntuak ematen dizkiola aplikazioa exekutatzeko beharrezkoa den irudia baldin badu. Hau da, aplikazioaren bertsio berri bat zabaldu zen unean, cron ataza bi nodotan exekutatzen zen, docker erregistrotik irudi berri bat deskargatuz haiei, eta horrela bi nodok azken puntuazio handiagoa jaso zuten hirugarrenarekin alderatuta. .
Goian idatzi dudan bezala, erregistroetan ez dugu ImageLocalityPriority politikaren ebaluazioari buruzko informaziorik ikusten, beraz, gure hipotesiak egiaztatzeko, aplikazioaren bertsio berriarekin irudia hirugarren nodora bota genuen, eta ondoren programazioak behar bezala funtzionatu zuen. . Hain zuzen ere, ImageLocalityPriority politikagatik oso gutxitan ikusi zen programazio arazoa; maizago beste zerbaitekin lotzen zen. Kube-scheduler lehenetsiaren lehentasunen zerrendako politika bakoitza guztiz arakatu ezin izan genuenez, pod scheduler politiken kudeaketa malgua behar genuen.
Arazoaren formulazioa
Arazoaren konponbidea ahalik eta zehatzena izatea nahi genuen, hau da, Kubernetes-en entitate nagusiak (hemen kube-scheduler lehenetsia esan nahi dugu) aldatu gabe geratu behar ziren. Ez genuen arazo bat toki batean konpondu eta beste batean sortu nahi. Horrela, arazoa konpontzeko bi aukera iritsi ginen, artikuluaren sarreran iragarri zirenak: programatzaile gehigarri bat sortzea edo zurea idaztea. Cron zereginak antolatzeko baldintza nagusia karga hiru nodoetan uniformeki banatzea da. Baldintza hau lehendik dauden kube-scheduler gidalerroek bete dezakete, beraz, gure arazoa konpontzeko ez du balio zure programatzailea idazteak.
Kube-scheduler gehigarri bat sortzeko eta zabaltzeko jarraibideak atalean deskribatzen dira . Hala ere, iruditu zitzaigun Inplementazioaren entitatea ez zela nahikoa kube-scheduler bezalako zerbitzu kritiko baten funtzionamenduan akatsen tolerantzia bermatzeko, beraz, kube-scheduler berri bat zabaltzea erabaki genuen Pod Estatiko gisa, zuzenean kontrolatuko zena. Kubelet-en eskutik. Horrela, honako baldintza hauek ditugu kube-scheduler berrirako:
- Zerbitzua Pod Estatiko gisa inplementatu behar da kluster nagusi guztietan
- Akatsen tolerantzia eman behar da kube-scheduler duen pod aktiboa erabilgarri ez badago
- Planifikatzean lehentasun nagusia nodoan dauden baliabideen kopurua izan behar da (LeastRequestedPriority)
Ezartzeko irtenbideak
Azpimarratzekoa da berehala Kubernetes v1.14.7-n egingo dugula lan guztiak, izan ere Hau da proiektuan erabili den bertsioa. Has gaitezen manifestu bat idazten gure kube-scheduler berrirako. Har dezagun manifestu lehenetsia (/etc/kubernetes/manifests/kube-scheduler.yaml) oinarri gisa eta eraman dezagun forma honetara:
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-configAldaketa nagusiei buruz laburki:
- Pod eta edukiontziaren izena kube-scheduler-cron bihurtu da
- Aukera definitu zen bezala 10151 eta 10159 ataken erabilera zehaztu zen
hostNetwork: trueeta ezin ditugu kube-scheduler lehenetsiaren ataka berdinak erabili (10251 eta 10259) - --config parametroa erabiliz, zerbitzua abiarazi behar den konfigurazio fitxategia zehaztu dugu
- Ostalaritik konfigurazio fitxategia (scheduler-custom.conf) eta programazio politika fitxategia (scheduler-custom-policy-config.json) muntatzea konfiguratuta.
Ez ahaztu gure kube-scheduler-ek lehenetsitakoaren antzeko eskubideak beharko dituela. Editatu bere cluster rola:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Orain hitz egin dezagun konfigurazio-fitxategian eta programazio-politika-fitxategian eduki behar denaz:
- Konfigurazio fitxategia (scheduler-custom.conf)
Kube-scheduler konfigurazio lehenetsia lortzeko, parametroa erabili behar duzu--write-config-to- . Sortutako konfigurazioa /etc/kubernetes/scheduler-custom.conf fitxategian jarriko dugu eta forma honetara murriztuko dugu:
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"Aldaketa nagusiei buruz laburki:
- SchedulerName gure kube-scheduler-cron zerbitzuaren izena ezarri dugu.
- Parametroan
lockObjectNamegure zerbitzuaren izena ere ezarri behar duzu eta parametroa dela ziurtatuleaderElectezarri true (nodo nagusi bat baduzu, false gisa ezar dezakezu). - Fitxategirako bidea zehaztu du parametroan programazio-politiken deskribapenarekin
algorithmSource.
Bigarren puntua gertutik aztertzea merezi du, non teklaren parametroak editatzen ditugun leaderElection. Akatsen tolerantzia bermatzeko, gaitu dugu (leaderElect) gure kube-scheduler-aren poden artean liderra (maisua) hautatzeko prozesua haientzako amaierako puntu bakarra erabiliz (resourceLock) kube-scheduler-cron izenekoa (lockObjectName) kube-system izenen espazioan (lockObjectNamespace). Kubernetes-ek osagai nagusien erabilgarritasun handia (kube-scheduler barne) nola bermatzen duen aurki daiteke .
- Programazio-gidalerroen fitxategia (scheduler-custom-policy-config.json)
Lehen idatzi dudan bezala, kube-scheduler lehenetsiak zein politika zehatzekin lan egiten duen jakin dezakegu bere kodea aztertuta. Hau da, ezin dugu kube-scheduler lehenetsitako programazio-politikak dituen fitxategirik lortu konfigurazio fitxategi baten moduan. Deskriba ditzagun /etc/kubernetes/scheduler-custom-policy-config.json fitxategian interesatzen zaizkigun antolamendu-politikak honela:
{
"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
}Horrela, kube-scheduler-ek lehenik eta behin pod bat programatu daitekeen nodoen zerrenda osatzen du GeneralPredicates politikaren arabera (PodFitsResources, PodFitsHostPorts, HostName eta MatchNodeSelector politiken multzoa barne). Eta, ondoren, nodo bakoitza lehentasunen arrayko politiken multzoaren arabera ebaluatzen da. Gure zereginaren baldintzak betetzeko, horrelako politika-multzo bat irtenbide egokiena litzatekeela uste genuen. Gogorarazten dizut bere deskribapen zehatzekin gidalerro multzo bat eskuragarri dagoela hemen . Zure zeregina betetzeko, erabilitako politika multzoa alda dezakezu eta haiei pisu egokiak esleitu.
Dei diezaiogun kapituluaren hasieran sortu dugun kube-scheduler berriaren manifestuari kube-scheduler-custom.yaml eta jar diezaiogun hurrengo /etc/kubernetes/manifests hiru nodo nagusietan. Dena behar bezala egiten bada, Kubelet-ek pod bat abiaraziko du nodo bakoitzean, eta gure kube-scheduler berriaren erregistroetan gure politika-fitxategia behar bezala aplikatu den informazioa ikusiko dugu:
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:{}]'Orain geratzen dena da gure CronJob-en zehaztapenetan adieraztea bere lekak antolatzeko eskaera guztiak gure kube-scheduler berriak prozesatu behar dituela:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...Ondorioa
Azken finean, kube-scheduler gehigarri bat lortu dugu, programazio-politika multzo berezi batekin, eta horren lana kubelet-ek zuzenean kontrolatzen du. Horrez gain, gure kube-scheduler-eko poden artean buruzagi berri baten hautaketa ezarri dugu, arrazoiren batengatik lider zaharra erabilgarri ez badago.
Ohiko aplikazioak eta zerbitzuak kube-scheduler lehenetsiaren bidez programatzen jarraitzen dute, eta cron zeregin guztiak berrira erabat transferitu dira. Cron atazek sortutako karga orain nodo guztietan uniformeki banatzen da. Kontuan izanda cron zeregin gehienak proiektuaren aplikazio nagusien nodo berdinetan exekutatzen direla, horrek nabarmen murriztu du lekak mugitzeko arriskua baliabide faltagatik. Kube-scheduler gehigarria sartu ondoren, jada ez ziren sortu cron zereginen programazio irregularreko arazoak.
Irakurri beste artikulu batzuk ere gure blogean:
Iturria: www.habr.com