Kube-Scheduler ass en integralen Bestanddeel vu Kubernetes, dee verantwortlech ass fir Pods iwwer Noden ze plangen am Aklang mat spezifizéierte Politiken. Dacks, wärend der Operatioun vun engem Kubernetes Cluster, musse mir net iwwerdenken wéi eng Politik benotzt gi fir Pods ze plangen, well d'Set vu Politiken vum Standard Kube-Scheduler fir déi meescht alldeeglech Aufgaben gëeegent ass. Wéi och ëmmer, et ginn Situatiounen wou et wichteg ass fir eis de Prozess vun der Verdeelung vun de Pods ze feinstemmen, an et ginn zwou Weeër fir dës Aufgab z'erreechen:
- Erstellt e Kube-Scheduler mat engem personaliséierte Set vu Regelen
- Schreift Ären eegene Scheduler a léiert et mat API Server Ufroen ze schaffen
An dësem Artikel wäert ech d'Ëmsetzung vun den éischte Punkt beschreiwen fir de Problem vun ongläiche Fuerplang vun hearths op ee vun eise Projeten ze léisen.
Eng kuerz Aféierung wéi Kube-Scheduler funktionnéiert
Et ass derwäert besonnesch d'Tatsaach ze notéieren datt de Kube-Scheduler net verantwortlech ass fir direkt Pods ze plangen - et ass nëmme verantwortlech fir den Node ze bestëmmen op deem de Pod plazéiert. An anere Wierder, d'Resultat vun der Aarbecht vum Kube-Scheduler ass den Numm vum Node, deen en op den API Server fir eng Fuerplangufro zréckkënnt, an dat ass wou seng Aarbecht ophält.
Als éischt kompiléiert kube-Scheduler eng Lëscht vun Noden op deenen de Pod ka geplangt ginn am Aklang mat de Prädikatpolitiken. Als nächst kritt all Node aus dëser Lëscht eng gewëssen Zuel vu Punkten am Aklang mat de Prioritéite Politiken. Als Resultat gëtt den Node mat der maximaler Unzuel u Punkte gewielt. Wann et Wirbelen déi de selwechte Maximum Score hunn, gëtt eng zoufälleg ausgewielt. Eng Lëscht an Beschreiwung vun de Prädikater (Filteren) a Prioritéite (Scoring) Politiken kënnen an .
Beschreiwung vum Problem Kierper
Trotz der grousser Zuel vu verschiddene Kubernetes Cluster, déi bei Nixys erhale ginn, hu mir fir d'éischt de Problem vun der Zäitplang vun Pods eréischt viru kuerzem begéint, wann ee vun eise Projeten eng grouss Zuel vu periodeschen Aufgaben brauch (~ 100 CronJob Entitéiten). Fir d'Beschreiwung vum Problem sou vill wéi méiglech ze vereinfachen, wäerte mir als Beispill ee Mikroservice huelen, an deem eng Cron Task eemol pro Minutt lancéiert gëtt, e bësse Laascht op der CPU erstellt. Fir d'Cron Aufgab auszeféieren, goufen dräi Wirbelen mat absolut identesche Charakteristiken zougewisen (24 vCPUs op all).
Zur selwechter Zäit ass et onméiglech mat Genauegkeet ze soen wéi laang de CronJob dauert fir auszeféieren, well de Volume vun den Inputdaten dauernd ännert. Am Duerchschnëtt, wärend der normaler Operatioun vum Kube-Scheduler, leeft all Node 3-4 Jobinstanzen, déi ~20-30% vun der Laascht op der CPU vun all Node erstellen:
De Problem selwer ass datt heiansdo Cron Task Pods opgehalen hunn op engem vun den dräi Wirbelen geplangt ze ginn. Dat ass, iergendwann an der Zäit, war keen eenzege Pod fir ee vun de Wirbelen geplangt, während op deenen aneren zwee Wirbelen 6-8 Exemplare vun der Aufgab lafen, déi ~40-60% vun der CPU-Laascht erstellen:
De Problem huet sech mat absolut zoufälleger Frequenz erëmfonnt an heiansdo korreléiert mam Moment wou eng nei Versioun vum Code ausgerullt gouf.
Duerch d'Erhéijung vum Kube-Scheduler Logniveau op Niveau 10 (-v = 10), hu mir ugefaang ze notéieren wéivill Punkten all Node wärend dem Evaluatiounsprozess gewonnen huet. Wärend der normaler Planungsoperatioun konnten déi folgend Informatioun an de Logbicher gesi ginn:
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 100043Déi. beurteelen duerch d'Informatioun, déi aus de Logbicher kritt gëtt, huet jidderee vun den Noden eng gläich Zuel vu Finale Punkten geschoss an eng zoufälleg fir d'Planung ausgewielt. Zu der Zäit vun der problematescher Planung hunn d'Logbicher esou ausgesinn:
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 100038Vun deem kann ee gesinn, datt ee vun de Wirbelen manner Finale Punkte wéi déi aner gemaach huet, an dofir Planung war nëmmen fir déi zwee Wirbelen duerchgefouert, datt de Maximum Score. Mir waren also definitiv iwwerzeegt, datt de Problem genee am Fuerplang vun de Pods läit.
De weideren Algorithmus fir de Problem ze léisen war eis offensichtlech - d'Logbicher analyséieren, verstoen mat wéi enger Prioritéit den Node keng Punkte krut an, wann néideg, d'Politik vum Standard Kube-Scheduler upassen. Wéi och ëmmer, hei si mir mat zwee bedeitende Schwieregkeeten konfrontéiert:
- Um maximale Loggingsniveau (10) reflektéiert Punkten, déi nëmme fir e puer Prioritéite gewonnen goufen. Am uewe genannten Auszuch vu Logbicher kënnt Dir gesinn datt fir all Prioritéite, déi an de Logbicher reflektéiert sinn, Noden déi selwecht Zuel vu Punkten am normalen a Problemplang maachen, awer d'Finale Resultat am Fall vun der Problemplanung ass anescht. Also kënne mir schléissen datt fir e puer Prioritéite Scoring "hannert de Kulissen" geschitt, a mir hu kee Wee fir ze verstoen fir wéi eng Prioritéit den Node keng Punkte krut. Mir beschriwwen dëse Problem am Detail an Kubernetes Repository op Github. Zu der Zäit vum Schreiwen gouf eng Äntwert vun den Entwéckler kritt datt d'Logbicherstëtzung an de Kubernetes v1.15,1.16, 1.17 an XNUMX Updates bäigefüügt ginn.
- Et gëtt keen einfache Wee fir ze verstoen mat wéi enge spezifesche Set vu Politiken de Kube-Scheduler am Moment schafft. Jo, an dëser Lëscht ass opgezielt, mee et enthält keng Informatiounen iwwert wat spezifesch Gewiichter op jiddereng vun den Prioritéit Politik zougewisen sinn. Dir kënnt d'Gewichte gesinn oder d'Politik vum Standard Kube-Scheduler änneren nëmmen an .
Et ass derwäert ze notéieren datt eemol mir konnten notéieren datt en Node keng Punkte kritt huet no der ImageLocalityPriority Politik, déi Punkten un en Node ausgezeechent wann et schonn dat Bild huet dat néideg ass fir d'Applikatioun ze lafen. Dat ass, an der Zäit wou eng nei Versioun vun der Applikatioun ausgerullt gouf, huet d'Cron Task et fäerdeg bruecht op zwee Wirbelen ze lafen, en neit Bild aus dem Docker Registry un hinnen erofzelueden, an domat kruten zwee Wirbelen e méi héije Schlussscore par rapport zum drëtten .
Wéi ech uewen geschriwwen hunn, gesi mir an de Logbicher keng Informatioun iwwer d'Evaluatioun vun der ImageLocalityPriority Politik, also fir eis Viraussetzung ze kontrolléieren, hu mir d'Bild mat der neier Versioun vun der Applikatioun op den drëtten Node gedumpt, duerno huet de Fuerplang richteg geschafft. . Et war genee wéinst der ImageLocalityPriority Politik datt de Fuerplangproblem zimlech seelen observéiert gouf; méi dacks war et mat soss eppes verbonnen. Wéinst der Tatsaach, datt mir all vun de Politiken an der Lëscht vun Prioritéite vun der Default Kube-Scheduler net voll debug konnten, hu mir e Besoin fir flexibel Gestioun vun Pod Scheduling Politiken.
Problemerklärung
Mir wollten d'Léisung vum Problem esou spezifesch wéi méiglech sinn, dat heescht, d'Haaptentitéite vu Kubernetes (hei menge mir de Standard Kube-Scheduler) sollten onverännert bleiwen. Mir wollten net e Problem op enger Plaz léisen an en op enger anerer Plaz kreéieren. Also hu mir zwou Méiglechkeeten fir de Problem ze léisen, déi an der Aféierung vum Artikel ugekënnegt goufen - en zousätzleche Scheduler erstellen oder Ären eegene schreiwen. D'Haaptfuerderung fir Cron Aufgaben ze plangen ass d'Laascht gläichméisseg iwwer dräi Wirbelen ze verdeelen. Dës Fuerderung kann duerch bestehend Kube-Scheduler Politiken zefridde ginn, also fir eise Problem ze léisen ass et kee Sënn Ären eegene Scheduler ze schreiwen.
Instruktioune fir en zousätzleche Kube-Scheduler ze kreéieren an z'installéieren ginn an . Wéi och ëmmer, et huet eis geschéngt datt d'Deployment Entity net genuch wier fir Feeler Toleranz an der Operatioun vun esou engem kriteschen Service wéi Kube-Scheduler ze garantéieren, sou datt mir decidéiert hunn en neie Kube-Scheduler als Static Pod z'installéieren, deen direkt iwwerwaacht gëtt vum Kubelet. Also hu mir déi folgend Ufuerderunge fir den neie Kube-Scheduler:
- De Service muss als Static Pod op all Cluster Master ofgesat ginn
- Feeler Toleranz muss zur Verfügung gestallt ginn am Fall wou den aktive Pod mat Kube-Scheduler net verfügbar ass
- D'Haaptprioritéit bei der Planung sollt d'Zuel vun de verfügbare Ressourcen um Node sinn (LeastRequestedPriority)
Léisung Ëmsetzung
Et ass derwäert direkt ze notéieren datt mir all Aarbecht am Kubernetes v1.14.7 ausféieren, well Dëst ass d'Versioun déi am Projet benotzt gouf. Loosst eis ufänken e Manifest fir eisen neie Kube-Scheduler ze schreiwen. Loosst eis de Standardmanifest (/etc/kubernetes/manifests/kube-scheduler.yaml) als Basis huelen an et op déi folgend Form bréngen:
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-configKuerz iwwer d'Haaptännerungen:
- Den Numm vum Pod an dem Container op kube-scheduler-cron geännert
- Spezifizéiert d'Benotzung vun Häfen 10151 an 10159 wéi d'Optioun definéiert gouf
hostNetwork: truea mir kënnen net déiselwecht Ports benotzen wéi de Standard Kube-Scheduler (10251 an 10259) - Mat dem --config Parameter hu mir d'Konfiguratiounsdatei spezifizéiert, mat där de Service soll gestart ginn
- Konfiguréiert Montéierung vun der Konfiguratiounsdatei (scheduler-custom.conf) a Scheduler-Politikdatei (scheduler-custom-policy-config.json) vum Host
Vergiesst net datt eise Kube-Scheduler Rechter ähnlech wéi de Standard brauch. Änneren seng Cluster Roll:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Loosst eis elo schwätzen iwwer wat an der Konfiguratiounsdatei an der Scheduling Politikdatei enthale soll sinn:
- Konfiguratiounsdatei (scheduler-custom.conf)
Fir d'Standard Kube-Scheduler Konfiguratioun ze kréien, musst Dir de Parameter benotzen--write-config-toaus . Mir setzen déi resultéierend Konfiguratioun an der Datei /etc/kubernetes/scheduler-custom.conf a reduzéieren se op déi folgend Form:
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"Kuerz iwwer d'Haaptännerungen:
- Mir setzen SchedulerName op den Numm vun eisem kube-scheduler-cron Service.
- Am Parameter
lockObjectNameDir musst och den Numm vun eisem Service setzen an sécherstellen datt de ParameterleaderElectop wouer gesat (wann Dir e Master Node hutt, kënnt Dir et op falsch setzen). - Spezifizéiert de Wee fir d'Datei mat enger Beschreiwung vun de Fuerplangpolitiken am Parameter
algorithmSource.
Et ass derwäert den zweete Punkt méi no ze kucken, wou mir d'Parameteren fir de Schlëssel änneren leaderElection. Fir Feeler Toleranz ze garantéieren, hu mir aktivéiert (leaderElect) de Prozess vun der Auswiel vun engem Leader (Meeschter) tëscht de Pods vun eisem Kube-Scheduler mat engem eenzegen Endpunkt fir si (resourceLock) genannt kube-scheduler-cron (lockObjectName) am Kube-System Nummraum (lockObjectNamespace). Wéi Kubernetes eng héich Disponibilitéit vun den Haaptkomponenten garantéiert (inklusive Kube-Scheduler) kann fonnt ginn .
- Politikdatei Zäitplang (scheduler-custom-policy-config.json)
Wéi ech virdru geschriwwen hunn, kënne mir erausfannen mat wéi enger spezifescher Politik de Standard Kube-Scheduler funktionnéiert nëmme andeems Dir säi Code analyséiert. Dat ass, mir kënnen net e Fichier mat Fuerplangpolitike fir de Standard Kube-Scheduler op déiselwecht Manéier wéi eng Konfiguratiounsdatei kréien. Loosst eis d'Fuerplangpolitik beschreiwen, déi mir an der /etc/kubernetes/scheduler-custom-policy-config.json Datei interesséiert wéi follegt:
{
"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
}Also, kube-scheduler kompiléiert als éischt eng Lëscht vun Noden, op deenen e Pod ka geplangt ginn no der GeneralPredicates Politik (déi eng Rei vu PodFitsResources, PodFitsHostPorts, HostName, a MatchNodeSelector Politiken enthält). An dann gëtt all Node am Aklang mat der Satz vu Politiken an der Prioritéitarray bewäert. Fir d'Konditioune vun eiser Aufgab ze erfëllen, hu mir geduecht datt esou eng Politik déi optimal Léisung wier. Loosst mech Iech drun erënneren datt eng Rei vu Politiken mat hiren detailléierte Beschreiwunge verfügbar sinn . Fir Är Aufgab z'erreechen, kënnt Dir einfach d'Set vun de benotzte Politik änneren an hinnen entspriechend Gewiichter zouginn.
Mir ruffen d'Manifest vum neie Kube-Scheduler, dee mir am Ufank vum Kapitel erstallt hunn, kube-scheduler-custom.yaml a placéiere se an de folgende Wee /etc/kubernetes/manifests op dräi Meeschternoden. Wann alles richteg gemaach gëtt, lancéiert de Kubelet e Pod op all Node, an an de Logbicher vun eisem neie Kube-Scheduler wäerte mir Informatioun gesinn datt eis Politikdatei erfollegräich applizéiert gouf:
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:{}]'Elo bleift just fir an der Spezifizéierung vun eisem CronJob unzeginn datt all Ufroe fir seng Pods ze plangen solle vun eisem neie Kube-Scheduler veraarbecht ginn:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...Konklusioun
Schlussendlech hu mir en zousätzleche Kube-Scheduler mat engem eenzegaartege Set vu Fuerplangpolitiken, d'Aarbecht vun deenen direkt vum Kubelet iwwerwaacht gëtt. Zousätzlech hu mir d'Wiel vun engem neie Leader tëscht de Pods vun eisem Kube-Scheduler opgestallt, am Fall wou den ale Leader aus irgendege Grënn net verfügbar ass.
Regelméisseg Uwendungen a Servicer ginn weider duerch de Standard Kube-Scheduler geplangt, an all Cron Aufgaben goufen komplett op déi nei transferéiert. D'Laascht erstallt duerch Cron Aufgaben ass elo gläichméisseg iwwer all Noden verdeelt. Bedenkt datt déi meescht Cron Aufgaben op déiselwecht Node wéi d'Haaptapplikatioune vum Projet ausgefouert ginn, huet dëst de Risiko wesentlech reduzéiert fir Pods ze bewegen wéinst Mangel u Ressourcen. No der Aféierung vun engem zousätzleche Kube-Scheduler sinn d'Problemer mat ongläiche Fuerplang vun Cron Aufgaben net méi entstanen.
Liest och aner Artikelen op eisem Blog:
Source: will.com