Kube-scheduler hêmanek yekbûyî ya Kubernetes e, ku berpirsiyar e ku li gorî polîtîkayên diyarkirî li seranserê nodan plansaz bike. Bi gelemperî, di dema xebitandina komek Kubernetes de, em ne hewce ne ku bifikirin ka kîjan polîtîka têne bikar anîn ji bo plansazkirina podan, ji ber ku komek polîtîkayên kube-serdema xwerû ji bo piraniya karên rojane maqûl e. Lêbelê, rewş hene ku ji bo me girîng e ku em pêvajoya dabeşkirina potan baş bi rêkûpêk bikin, û du rê hene ku meriv vî karî pêk bîne:
- Kube-scheduler bi komek rêzikên xwerû biafirînin
- Plansazkerê xwe binivîsin û wê fêr bikin ku bi daxwazên servera API-ê re bixebite
Di vê gotarê de, ez ê pêkanîna xala yekem ji bo çareserkirina pirsgirêka nexşeya nehevseng a odên li ser yek ji projeyên me diyar bikim.
Pêşgotinek kurt li ser ka kube-scheduler çawa dixebite
Hêjayî balkişandinê ye ku kube-scheduler ne berpirsiyar e rasterast plansazkirina pod-an - ew tenê berpirsiyar e ji bo destnîşankirina girêka ku li ser pêve tê danîn. Bi gotinek din, encama xebata kube-scheduler navê nodê ye, ku ew ji bo daxwaznameyek plansazkirinê vedigere servera API-ê, û li wir xebata wê bi dawî dibe.
Pêşîn, kube-scheduler navnîşek girêkan berhev dike ku li ser wan pod dikare li gorî polîtîkayên pêşdaraz were plansaz kirin. Dûv re, her girêk ji vê navnîşê li gorî polîtîkayên pêşengiyê hejmarek xalan distîne. Di encamê de, girêka herî zêde ya xalan tê hilbijartin. Ger girêk hebin ku xwediyê heman puana herî zêde ne, yek rasthatî tê hilbijartin. Navnîşek û danasîna polîtîkayên pêşdar (parzkirin) û pêşanî (pûlan) di nav de têne dîtin. .
Danasîna laşê pirsgirêkê
Tevî ku hejmareke mezin a komên Kubernetes ên cihêreng ên ku li Nixys têne parastin, em yekem car rastî pirsgirêka plansazkirina podan tenê vê dawiyê hatin, dema ku yek ji projeyên me hewce bû ku hejmareke mezin ji karên periyodîk bimeşîne (~ 100 hebûnên CronJob). Ji bo ku danasîna pirsgirêkê bi qasî ku gengaz hêsan bike, em ê wekî mînakek mîkroxizmetê bigirin, ku di hundurê wê de karek kronîk her deqeyekê carekê tê destpêkirin, û hin bargiraniyê li CPU-yê diafirîne. Ji bo meşandina peywira kronê, sê girêkên bi taybetmendiyên bêkêmasî yeksan hatin veqetandin (li ser her yekê 24 vCPU).
Di heman demê de, ne gengaz e ku meriv bi duristî bêje ka dê CronJob çiqas dem bigire ji bo darvekirinê, ji ber ku hêjmara daneyên têketinê bi domdarî diguhere. Bi navînî, di dema xebata normal a kube-scheduler de, her nod 3-4 nimûneyên kar dimeşîne, ku ~ 20-30% barkirina li ser CPU-ya her girêkê diafirîne:
Pirsgirêk bi xwe ev e ku carinan podên peywira cron li ser yek ji sê girêkan nayên plansaz kirin. Ango, di demekê de, ji bo yek ji girêkan yek podek nehat plansaz kirin, dema ku li ser du girêkên din 6-8 kopiyên peywirê dimeşiyan, ~ 40-60% ji barkirina CPU-yê diafirînin:
Pirsgirêk bi frekansa bêkêmasî ya bêkêmasî dubare bû û carinan bi dema ku guhertoyek nû ya kodê hatî derxistin re têkildar bû.
Bi zêdekirina asta têketinê ya kube-scheduler heya asta 10 (-v=10), me dest bi tomarkirina çend xalan kir ku her girêkek di pêvajoya nirxandinê de çend xal bi dest xistiye. Di dema xebata plansaziya normal de, agahdariya jêrîn dikare di qeydan de were dîtin:
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 100043Ewan. Li gorî agahiyên ku ji qeydan hatine girtin, her yek ji girêkan hejmareke wekhev xalên dawîn bi dest xistin û yek rasthatî ji bo plansaziyê hate hilbijartin. Di dema plansazkirina pirsgirêkê de, têketin bi vî rengî xuya bûn:
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 100038Ji vê yekê tê dîtin ku yek ji girêkan ji yên din kêmtir xalên dawîn stendiye, û ji ber vê yekê plansazkirin tenê ji bo du girêkên ku herî zêde puan girtine hate kirin. Ji ber vê yekê, em bê guman pê bawer bûn ku pirsgirêk bi rastî di plansazkirina potan de ye.
Algorîtmaya din a ji bo çareserkirina pirsgirêkê ji me re eşkere bû - têketin analîz bikin, fam bikin ku nodê bi kîjan pêşanî xalan dernexistiye û, ger hewce bike, polîtîkayên kube-serdema xwerû biguhezînin. Lêbelê, li vir em bi du zehmetiyên girîng re rû bi rû ne:
- Di asta herî zêde ya têketinê (10) de, xalên ku tenê ji bo hin pêşandan hatine bidestxistin têne xuyang kirin. Di beşa jorîn a têketinê de, hûn dikarin bibînin ku ji bo hemî pêşîniyên ku di qeydan de têne xuyang kirin, girêk di nexşeya normal û pirsgirêkê de heman hejmarê xalan digirin, lê encama dawîn di doza plansazkirina pirsgirêkê de cûda ye. Ji ber vê yekê, em dikarin encam bidin ku ji bo hin pêşanîn, tomarkirin "li pişt perdeyê" pêk tê, û me rêyek tune ku em fam bikin ka ji bo kîjan pêşanî xalê xalan negirtiye. Me di nav de ev pirsgirêk bi berfirehî diyar kir Depoya Kubernetes li ser Github. Di dema nivîsandinê de, bersivek ji pêşdebiran hate wergirtin ku dê piştgirîya têketinê di nûvekirinên Kubernetes v1.15,1.16, 1.17 û XNUMX de were zêdekirin.
- Rêyek hêsan tune ku meriv fêm bike ku kube-scheduler niha bi kîjan komek polîtîkayên taybetî re dixebite. Belê, di ev lîste tête navnîş kirin, lê ew agahdarî li ser kîjan giraniyên taybetî ji bo her yek ji polîtîkayên pêşîn têne destnîşan kirin tune. Hûn dikarin giranan bibînin an jî polîtîkayên kube-scheduler-a xwerû tenê tê de biguherînin .
Hêjayî gotinê ye ku carekê me karîbû tomar bike ku nodek li gorî polîtîkaya ImageLocalityPriority xalan wernegirtiye, ku xalek ji girêkekê re diyar dike ger wêneya wê ya ku ji bo xebitandina serîlêdanê jixwe hebe hebe. Ango, di dema ku guhertoyek nû ya serîlêdanê hate derxistin, peywira cron karî li ser du girêkan bixebite, wêneyek nû ji qeyda dokerê ji wan re dakêşe, û bi vî rengî du girêk li gorî ya sêyemîn puanek dawînek bilindtir wergirtin. .
Wekî ku min li jor nivîsî, di têketinan de em agahdariya li ser nirxandina polîtîkaya ImageLocalityPriority nabînin, ji ber vê yekê ji bo ku em texmîna xwe kontrol bikin, me wêneyê bi guhertoya nû ya serîlêdanê re davêje ser girêka sêyemîn, piştî ku plansazkirin rast xebitî. . Bi rastî ji ber polîtîkaya ImageLocalityPriority bû ku pirsgirêka plansazkirinê pir kêm kêm dihat dîtin; pir caran ew bi tiştek din re têkildar bû. Ji ber vê yekê ku me nikarîbû her yek ji polîtîkayên di navnîşa pêşîn a kube-bersazkera xwerû de bi tevahî debuke, hewcedariya me bi rêveberiya maqûl a polîtîkayên plansazkirina pod hebû.
Formulkirina pirsgirêkê
Me xwest ku çareseriya pirsgirêkê bi qasî ku gengaz be taybetî be, yanî divê saziyên sereke yên Kubernetes (li vir mebesta me ya kube-scheduler-ya xwerû) neguhezîne. Me nexwest pirsgirêkek li cihekî çareser bikin û li cihekî din çêbikin. Bi vî rengî, em gihîştin du vebijarkan ji bo çareserkirina pirsgirêkê, ku di danasîna gotarê de hatine ragihandin - çêkirina plansaziyek zêde an nivîsandina xweya xwe. Pêdiviya sereke ji bo plansazkirina peywirên kron ev e ku bar bi rengek wekhev li sê nokan belav bike. Ev hewcedarî dikare ji hêla polîtîkayên kube-plansazker ên heyî ve were têr kirin, ji ber vê yekê ji bo çareserkirina pirsgirêka me tu wateya nivîsandina nexşerêya xwe tune.
Talîmatên ji bo çêkirin û danasîna kube-rêveberek zêde di nav de têne diyar kirin . Lêbelê, ji me re xuya bû ku saziya Deployment têrê nake ku di xebata karûbarek weha krîtîk wekî kube-scheduler de tolerasyona xeletiyê misoger bike, ji ber vê yekê me biryar da ku kube-plansazek nû wekî Podek Statîk, ku dê rasterast were şopandin, bicîh bikin. ji hêla Kubelet ve. Ji ber vê yekê, me ji bo kube-scheduler-a nû hewcedariyên jêrîn hene:
- Pêdivî ye ku karûbar wekî Podek Statîk li ser hemî axayên komê were bicîh kirin
- Ger ku pod çalak a bi kube-scheduler tune be divê tolerasyona xeletiyê were peyda kirin
- Di dema plansaziyê de pêşîniya sereke divê hejmara çavkaniyên berdest ên li ser nodê be (LeastRequestedPriority)
Çareseriyên pêkanîna
Hêjayî gotinê ye ku di cih de em ê hemî xebata di Kubernetes v1.14.7 de pêk bînin, ji ber ku Ev guhertoya ku di projeyê de hat bikaranîn e. Werin em dest bi nivîsandina manîfestoyek ji bo kube-scheduler meya nû bikin. Ka em manîfestoya xwerû (/etc/kubernetes/manifests/kube-scheduler.yaml) ji xwe re bingeh bigirin û bînin forma jêrîn:
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-configBi kurtî li ser guhertinên sereke:
- Navê pod û konteynerê kir kube-scheduler-cron
- Bikaranîna portên 10151 û 10159 wekî vebijark hate destnîşan kirin
hostNetwork: trueû em nikarin heman portan wekî kube-scheduler-a xwerû bikar bînin (10251 û 10259) - Bi karanîna parametreya --config, me pela veavakirinê ya ku divê karûbar pê re were destpêkirin diyar kir
- Sazkirina pelê veavakirinê (scheduler-custom.conf) û pelê sîyaseta plansazkirinê (scheduler-custom-policy-config.json) ji mêvandarê vesaz kirin
Ji bîr nekin ku plansazkerê me yê kube dê hewceyê mafên mîna ya xwerû hebe. Rola wê ya komê biguherîne:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Naha em biaxivin ka çi divê di pelê mîhengê û pelê polîtîkaya plansazkirinê de hebe:
- Pelê veavakirinê (scheduler-custom.conf)
Ji bo bidestxistina veavakirina kube-scheduler ya xwerû, divê hûn pîvanê bikar bînin--write-config-toji . Em ê veavakirina encam di pelê /etc/kubernetes/scheduler-custom.conf de bi cîh bikin û wê bi forma jêrîn kêm bikin:
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"Bi kurtî li ser guhertinên sereke:
- Me schedulerName li ser navê karûbarê xweya kube-scheduler-cron destnîşan kir.
- Di parametreyê de
lockObjectNamehûn jî hewce ne ku navê karûbarê me destnîşan bikin û pê ewle bin ku parametreleaderElectrast were danîn (heke girêkek weya sereke hebe, hûn dikarin wê wekî xelet bicîh bikin). - Rêya pelê bi ravekirina polîtîkayên plansazkirinê di pîvanê de diyar kir
algorithmSource.
Hêja ye ku meriv ji nêz ve li xala duyemîn binêre, ku em li wir parametreyên ji bo mifteyê biguherînin leaderElection. Ji bo misogerkirina tolerasyona xeletiyê, me çalak kiriye (leaderElect(resourceLock) bi navê kube-scheduler-cron (lockObjectName) di qada navên pergala kube de (lockObjectNamespace). Çawa Kubernetes hebûna bilind a hêmanên sereke (tevî kube-scheduler) misoger dike, dikare di nav de were dîtin .
- Dosya polîtîkaya plansazkirinê (scheduler-custom-policy-config.json)
Wekî ku min berê nivîsî, em dikarin fêr bibin ka kîjan polîtîkayên taybetî yên kube-scheduler-a xwerû bi tenê bi analîzkirina koda xwe re dixebite. Ango, em nikarin pelek bi polîtîkayên plansazkirinê ji bo kube-scheduler-a xwerû bi heman awayê pelek vesazkirinê bi dest bixin. Ka em polîtîkayên plansazkirinê yên ku em pê re eleqedar dibin di pelê /etc/kubernetes/scheduler-custom-policy-config.json de wiha diyar bikin:
{
"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
}Bi vî rengî, kube-scheduler yekem navnîşek girêkan berhev dike ku podek li gorî polîtîkaya GeneralPredicates (ku komek polîtîkayên PodFitsResources, PodFitsHostPorts, HostName, û MatchNodeSelector dihewîne) ve tê plansaz kirin. Û dûv re her girêk li gorî rêzika polîtîkayên di rêza pêşîn de têne nirxandin. Ji bo ku şert û mercên erka xwe pêk bînin, me wisa nirxand ku polîtîkayeke bi vî rengî wê bibe çareseriya herî baş. Bihêle ku ez ji we re bi bîr bînim ku komek polîtîk bi raveyên wan ên berfireh tê de heye . Ji bo ku hûn peywira xwe bi cih bînin, hûn dikarin bi tenê komek polîtîkayên ku hatine bikar anîn biguhezînin û giraniyên guncan ji wan re destnîşan bikin.
Werin em ji manîfestoya kube-scheduler-a nû, ya ku me di destpêka beşê de çêkiriye, kube-scheduler-custom.yaml bi nav bikin û li ser sê girêkên masterê bixin nav riya jêrîn /etc/kubernetes/manifests. Ger her tişt rast were kirin, Kubelet dê li ser her girêkek podek bide destpêkirin, û di têketinên kube-scheduler-a meya nû de em ê agahdarî bibînin ku pelê polîtîkaya me bi serfirazî hate sepandin:
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:{}]'Naha ya ku dimîne ev e ku em di taybetmendiya CronJob-a me de destnîşan bikin ku hemî daxwazên ji bo plansazkirina podên wê divê ji hêla kube-scheduler-a meya nû ve bêne pêvajo kirin:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...encamê
Di dawiyê de, me kube-bernamegerek din a bi komek polîtîkayên nexşesaziyê yên yekta peyda kir, ku xebata ku rasterast ji hêla kubelet ve tê şopandin. Digel vê yekê, me hilbijartina serokek nû di navbera polên kube-bernameya xwe de saz kiriye heke serokê kevn ji ber hin sedeman nederbas bibe.
Serlêdan û karûbarên birêkûpêk bi navgîniya kube-scheduler-a xwerû ve têne plansaz kirin berdewam dikin, û hemî peywirên cron bi tevahî li ya nû hatine veguheztin. Barkirina ku ji hêla peywirên cron ve hatî afirandin naha li hemî girêkan bi rengek wekhev tê belav kirin. Bihesibînin ku piraniya peywirên kron li ser heman girêkan wekî serîlêdanên sereke yên projeyê têne darve kirin, vê yekê ji ber kêmbûna çavkaniyan xetera barkirina podan bi girîngî kêm kiriye. Piştî danasîna kube-bernameya pêvek, pirsgirêkên bi plansazkirina nehevseng a peywirên kronê nema derketin.
Her weha gotarên din ên li ser bloga me bixwînin:
Source: www.habr.com