Tha Kube-scheduler na phàirt riatanach de Kubernetes, air a bheil uallach airson pods a chlàradh thairis air nodan a rèir poileasaidhean sònraichte. Gu tric, nuair a bhios buidheann Kubernetes ag obair, chan fheum sinn smaoineachadh air dè na poileasaidhean a thathas a’ cleachdadh airson pods a chlàradh, leis gu bheil an seata de phoileasaidhean den chlàr-ciùb àbhaisteach freagarrach airson a’ mhòr-chuid de ghnìomhan làitheil. Ach, tha suidheachaidhean ann nuair a tha e cudromach dhuinn mion-sgrùdadh a dhèanamh air a’ phròiseas airson pods a riarachadh, agus tha dà dhòigh air an obair seo a choileanadh:
- Cruthaich clàr-ciùb le seata àbhaisteach de riaghailtean
- Sgrìobh do chlàr-ama fhèin agus ionnsaich e gus obrachadh le iarrtasan frithealaiche API
San artaigil seo, bheir mi cunntas air buileachadh a ’chiad phuing gus fuasgladh fhaighinn air an duilgheadas a thaobh clàradh neo-chòmhnard teintean air aon de na pròiseactan againn.
Ro-ràdh goirid air mar a tha kube-scheduler ag obair
Is fhiach a bhith mothachail gu sònraichte nach eil cube-scheduler an urra ri bhith a 'clàradh pods gu dìreach - chan eil e an urra ach a bhith a' dearbhadh an nòta air an cuir thu am pod. Ann am faclan eile, is e toradh obair kube-scheduler ainm an nód, a thilleas e chun t-seirbheisiche API airson iarrtas clàraidh, agus sin far a bheil an obair aige a’ tighinn gu crìch.
An toiseach, bidh kube-scheduler a’ cur ri chèile liosta de nodan air am faodar am pod a chlàradh a rèir nam poileasaidhean ro-innse. An ath rud, gheibh gach nód bhon liosta seo àireamh sònraichte de phuingean a rèir nam poileasaidhean prìomhachais. Mar thoradh air an sin, tha an nód leis an àireamh as motha de phuingean air a thaghadh. Ma tha nodan ann aig a bheil an aon sgòr as àirde, thèid fear air thuaiream a thaghadh. Gheibhear liosta agus tuairisgeul de na poileasaidhean ro-innse (sìoladh) agus prìomhachasan (sgòradh). .
Tuairisgeul air buidheann trioblaid
A dh’ aindeoin an àireamh mhòr de chruinneachaidhean eadar-dhealaichte de Kubernetes a thathas a’ cumail aig Nixys, cha do choinnich sinn an-toiseach ri duilgheadas a bhith a’ clàradh pods o chionn ghoirid, nuair a dh’ fheumadh aon de na pròiseactan againn àireamh mhòr de ghnìomhan bho àm gu àm a ruith (~ 100 buidhnean CronJob). Gus an tuairisgeul air an duilgheadas a dhèanamh nas sìmplidhe cho mòr ‘s as urrainn, bheir sinn mar eisimpleir aon microservice, anns am bi gnìomh cron air a chuir air bhog uair sa mhionaid, a’ cruthachadh beagan luchd air an CPU. Gus an obair cron a ruith, chaidh trì nodan le feartan gu tur co-ionann a riarachadh (24 vCPU air gach fear).
Aig an aon àm, tha e do-dhèanta a ràdh le cinnt dè cho fada ‘s a bheir an CronJob a chuir gu bàs, leis gu bheil meud an dàta cuir a-steach an-còmhnaidh ag atharrachadh. Gu cuibheasach, rè obrachadh àbhaisteach clàr-ciùb, bidh gach nód a’ ruith suidheachaidhean obrach 3-4, a chruthaicheas ~ 20-30% den luchd air CPU gach nód:
Is e an duilgheadas fhèin uaireannan nach sguir pods gnìomh cron a bhith clàraichte air aon de na trì nodan. Is e sin, aig àm air choreigin, cha deach aon pod a dhealbhadh airson aon de na nodan, agus air an dà nod eile bha 6-8 leth-bhreac den obair a’ ruith, a’ cruthachadh ~ 40-60% den luchd CPU:
Thachair an duilgheadas a-rithist le tricead gu tur air thuaiream agus uaireannan bha e co-cheangailte ris an àm a chaidh dreach ùr den chòd a sgaoileadh.
Le bhith ag àrdachadh ìre logaidh kube-clàraiche gu ìre 10 (-v = 10), thòisich sinn a’ clàradh cia mheud puing a fhuair gach nód tron phròiseas measaidh. Rè obair dealbhaidh àbhaisteach, bha am fiosrachadh a leanas ri fhaicinn anns na logaichean:
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 100043An fheadhainn sin. a’ breithneachadh leis an fhiosrachadh a fhuaireadh bho na logaichean, fhuair gach aon de na nodan an aon àireamh de phuingean deireannach agus chaidh fear air thuaiream a thaghadh airson dealbhadh. Aig àm planadh duilich, bha na logaichean a 'coimhead mar seo:
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 100038Às an sin chìthear gun d’ fhuair aon de na nodan nas lugha de phuingean deireannach na an fheadhainn eile, agus mar sin cha deach dealbhadh a dhèanamh ach airson an dà nod a fhuair an sgòr as àirde. Mar sin, bha sinn gu cinnteach cinnteach gu bheil an duilgheadas dìreach ann an clàradh nam pods.
Bha an algairim a bharrachd airson fuasgladh fhaighinn air an duilgheadas follaiseach dhuinn - dèan sgrùdadh air na logaichean, tuig leis a’ phrìomhachas nach d’ fhuair an nód sgòr de phuingean agus, ma tha sin riatanach, atharraich poileasaidhean an clàr-ciùb bunaiteach. Ach, an seo tha dà dhuilgheadas mòr romhainn:
- Aig an ìre clàraidh as àirde (10), chithear puingean a fhuaireadh a-mhàin airson cuid de phrìomhachasan. Anns an earrann gu h-àrd de logaichean, chì thu, airson a h-uile prìomhachas a tha air a nochdadh anns na logaichean, gu bheil nodan a’ faighinn an aon àireamh de phuingean ann an clàradh àbhaisteach agus duilgheadas, ach tha an toradh deireannach ann an cùis dealbhadh duilgheadas eadar-dhealaichte. Mar sin, faodaidh sinn a cho-dhùnadh, airson cuid de phrìomhachasan, gu bheil sgòradh a’ tachairt “air cùl ghnothaichean”, agus chan eil dòigh againn air tuigsinn dè am prìomhachas nach d’ fhuair an nód puingean. Thug sinn cunntas mionaideach air an duilgheadas seo ann an Stòr Kubernetes air Github. Aig àm sgrìobhaidh, chaidh freagairt fhaighinn bhon luchd-leasachaidh gun tèid taic logaidh a chuir ris anns na h-ùrachaidhean Kubernetes v1.15,1.16, 1.17 agus XNUMX.
- Chan eil dòigh fhurasta ann a bhith a’ tuigsinn dè an seata sònraichte de phoileasaidhean leis a bheil kube-scheduler ag obair an-dràsta. Seadh, ann an tha an liosta seo air a liostadh, ach chan eil fiosrachadh ann mu na cuideaman sònraichte a tha air an sònrachadh do gach aon de na poileasaidhean prìomhachais. Chì thu na cuideaman no deasaich thu poileasaidhean a’ chlàr-clàir bunaiteach a-mhàin ann an .
Is fhiach a thoirt fa-near, aon uair ‘s gun robh e comasach dhuinn a chlàradh nach d’ fhuair nód puingean a rèir a ’phoileasaidh ImageLocalityPriority, a bhios a’ toirt seachad puingean gu nód ma tha an ìomhaigh aige mu thràth a tha riatanach airson an tagradh a ruith. Is e sin, aig an àm a chaidh dreach ùr den tagradh a chuir a-steach, chaidh aig a’ ghnìomh cron air ruith air dà nod, a’ luchdachadh sìos ìomhaigh ùr bhon chlàr docker thuca, agus mar sin fhuair dà nodan sgòr deireannach nas àirde an coimeas ris an treas fear. .
Mar a sgrìobh mi gu h-àrd, anns na logaichean chan eil sinn a’ faicinn fiosrachadh mu mheasadh a’ phoileasaidh ImageLocalityPriority, agus mar sin gus ar beachd a dhearbhadh, dhump sinn an ìomhaigh leis an dreach ùr den tagradh air an treas nód, agus às deidh sin dh’ obraich an clàradh gu ceart. . B’ ann dìreach air sgàth poileasaidh ImageLocalityPriority a chaidh an duilgheadas clàraidh a choimhead gu math ainneamh; nas trice bha e co-cheangailte ri rudeigin eile. Leis nach b’ urrainn dhuinn gach aon de na poileasaidhean anns an liosta phrìomhachasan den chlàr-ciùb bunaiteach a dheasbad gu h-iomlan, bha feum againn air riaghladh sùbailte air poileasaidhean clàraidh pod.
Aithris dhuilgheadas
Bha sinn airson gum biodh am fuasgladh don duilgheadas cho sònraichte ‘s a ghabhas, is e sin, bu chòir na prìomh bhuidhnean de Kubernetes (an seo tha sinn a’ ciallachadh an clàr-ciùb bunaiteach) fuireach gun atharrachadh. Cha robh sinn airson fuasgladh fhaighinn air duilgheadas ann an aon àite agus a chruthachadh ann an àite eile. Mar sin, thàinig sinn gu dà roghainn airson fuasgladh fhaighinn air an duilgheadas, a chaidh ainmeachadh anns an ro-ràdh don artaigil - a 'cruthachadh clàr-ama a bharrachd no a' sgrìobhadh do chuid fhèin. Is e am prìomh riatanas airson gnìomhan cron a chlàradh an luchd a sgaoileadh gu cothromach thairis air trì nodan. Faodaidh an riatanas seo a bhith air a shàsachadh leis na poileasaidhean clàr-ciùb a th’ ann mar-thà, agus mar sin gus an duilgheadas againn fhuasgladh chan eil feum air do chlàr-ama fhèin a sgrìobhadh.
Tha stiùireadh airson cruthachadh agus cleachdadh clàr-ciùb a bharrachd air a mhìneachadh ann an . Ach, bha e coltach dhuinn nach robh an eintiteas Cleachdadh gu leòr gus dèanamh cinnteach à fulangas sgàinidhean ann an obrachadh seirbheis cho deatamach ri kube-scheduler, agus mar sin chuir sinn romhainn clàr-ciùb ùr a chleachdadh mar Static Pod, a bhiodh air a sgrùdadh gu dìreach. le Kubelet. Mar sin, tha na riatanasan a leanas againn airson an clàr-ciùb ùr:
- Feumaidh an t-seirbheis a bhith air a cleachdadh mar Pod Statach air a h-uile maighstir brabhsair
- Feumar fulangas sgàinidh a thoirt seachad air eagal ‘s nach eil am pod gnìomhach le kube-scheduler ri fhaighinn
- Bu chòir gur e am prìomh phrìomhachas nuair a thathar a’ dealbhadh an àireamh de ghoireasan a tha rim faighinn air an nód (Priority RequestedPriority)
Fuasglaidhean buileachaidh
Is fhiach a bhith mothachail sa bhad gun dèan sinn a h-uile obair ann an Kubernetes v1.14.7, oir Seo an dreach a chaidh a chleachdadh sa phròiseact. Nach tòisich sinn le bhith a’ sgrìobhadh manifesto airson ar clàr-ciùb ùr. Gabhamaid am manifesto bunaiteach (/etc/kubernetes/manifests/kube-scheduler.yaml) mar bhunait agus bheir sinn chun fhoirm a leanas e:
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-configBeagan mu na prìomh atharrachaidhean:
- Dh’ atharraich sinn ainm a’ phoit agus a’ ghobhar gu kube-scheduler-cron
- Sònraich cleachdadh puirt 10151 agus 10159 mar a chaidh an roghainn a mhìneachadh
hostNetwork: trueagus chan urrainn dhuinn na h-aon phuirt a chleachdadh ris a’ chlàr-chlàr bunaiteach kube (10251 agus 10259) - A’ cleachdadh am paramadair --config, shònraich sinn am faidhle rèiteachaidh leis am bu chòir an t-seirbheis a thòiseachadh
- Cur suas air a rèiteachadh den fhaidhle rèiteachaidh (scheduler-custom.conf) agus faidhle poileasaidh clàraidh (scheduler-custom-policy-config.json) bhon òstair
Na dì-chuimhnich gum feum an clàr-ciùb againn còraichean coltach ris an fhear àbhaisteach. Deasaich a dhreuchd brabhsair:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...A-nis bruidhnidh sinn mu na bu chòir a bhith anns an fhaidhle rèiteachaidh agus am faidhle poileasaidh clàraidh:
- Faidhle rèiteachaidh (scheduler-custom.conf)
Gus an rèiteachadh bunaiteach kube-scheduler fhaighinn, feumaidh tu am paramadair a chleachdadh--write-config-tobho . Cuiridh sinn an rèiteachadh a thig às anns an fhaidhle /etc/kubernetes/scheduler-custom.conf agus lughdaichidh sinn e chun fhoirm a leanas:
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"Beagan mu na prìomh atharrachaidhean:
- Shuidhich sinn ainm clàr-ama gu ainm ar seirbheis kube-scheduler-cron.
- Ann am paramadair
lockObjectNamefeumaidh tu cuideachd ainm ar seirbheis a shuidheachadh agus dèanamh cinnteach gu bheil am paramadairleaderElectsuidhichte gu fìor (ma tha aon phrìomh nód agad, faodaidh tu a chuir gu meallta). - Shònraich an t-slighe chun an fhaidhle le tuairisgeul air na poileasaidhean clàraidh anns a’ pharamadair
algorithmSource.
Is fhiach sùil nas mionaidiche a thoirt air an dàrna puing, far am bi sinn a’ deasachadh nam paramadairean airson an iuchair leaderElection. Gus dèanamh cinnteach à fulangas lochdan, tha sinn air comas a thoirt do (leaderElect) am pròiseas airson stiùiriche (maighstir) a thaghadh eadar pods ar clàr-ciùba a’ cleachdadh aon phuing crìochnachaidh dhaibh (resourceLock) ainmichte kube-scheduler-cron (lockObjectName) ann an ionad-ainm siostam kube (lockObjectNamespace). Gheibhear mar a bhios Kubernetes a’ dèanamh cinnteach gu bheil cothrom àrd air na prìomh phàirtean (a’ gabhail a-steach kube-scheduler). .
- Faidhle poileasaidh clàraidh (scheduler-custom-policy-config.json)
Mar a sgrìobh mi na bu thràithe, is urrainn dhuinn faighinn a-mach dè na poileasaidhean sònraichte a bhios an clàr-clàir bunaiteach ag obair leis a-mhàin le bhith a’ dèanamh anailis air a’ chòd aige. Is e sin, chan urrainn dhuinn faidhle fhaighinn le poileasaidhean clàraidh airson a’ chlàr-chlàr bunaiteach kube san aon dòigh ri faidhle rèiteachaidh. Bheir sinn cunntas air na poileasaidhean clàraidh anns a bheil ùidh againn anns an fhaidhle /etc/kubernetes/scheduler-custom-policy-config.json mar a leanas:
{
"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
}Mar sin, bidh kube-scheduler an-toiseach a’ cur ri chèile liosta de nodan far am faodar pod a chlàradh a rèir poileasaidh GeneralPredicates (a tha a’ toirt a-steach seata de PodFitsResources, PodFitsHostPorts, HostName, agus poileasaidhean MatchNodeSelector). Agus an uairsin thèid gach nód a mheasadh a rèir an t-seata de phoileasaidhean anns an raon phrìomhachasan. Gus cumhachan na h-obrach againn a choileanadh, bha sinn den bheachd gur e seata de phoileasaidhean mar sin am fuasgladh a b’ fheàrr. Leig leam do chuimhneachadh gu bheil seata de phoileasaidhean leis na tuairisgeulan mionaideach aca rim faighinn ann an . Gus do ghnìomh a choileanadh, faodaidh tu dìreach an seata de phoileasaidhean a thathar a’ cleachdadh atharrachadh agus cuideaman iomchaidh a shònrachadh dhaibh.
Canaidh sinn follaiseachd an clàr-ciùb ùr, a chruthaich sinn aig toiseach na caibideil, kube-scheduler-custom.yaml agus cuir e san t-slighe a leanas /etc/kubernetes/manifests air trì prìomh nodan. Ma thèid a h-uile càil a dhèanamh ceart, cuiridh Kubelet pod air bhog air gach nód, agus ann an logaichean an clàr-ciùb ùr againn chì sinn fiosrachadh gun deach ar faidhle poileasaidh a chuir an sàs gu soirbheachail:
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:{}]'A-nis chan eil air fhàgail ach a bhith a’ nochdadh ann an sònrachadh ar CronJob gum bu chòir a h-uile iarrtas airson na pods aige a chlàradh a bhith air a phròiseasadh leis a’ chlàr-ciùb ùr againn:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...co-dhùnadh
Aig a 'cheann thall, fhuair sinn clàr-ciùb a bharrachd le seata sònraichte de phoileasaidhean clàraidh, agus tha an obair air a sgrùdadh gu dìreach leis an kubelet. A bharrachd air an sin, tha sinn air taghadh stiùiriche ùr a chuir air dòigh eadar pods ar clàr-ciùba gun fhios nach bi an seann stiùiriche ri fhaighinn airson adhbhar air choireigin.
Tha tagraidhean agus seirbheisean cunbhalach fhathast gan clàradh tron chlàr-chlàr bunaiteach kube, agus chaidh a h-uile gnìomh cron a ghluasad gu tur chun fhear ùr. Tha an luchd a chruthaich gnìomhan cron a-nis air a chuairteachadh gu cothromach thar gach nod. Leis gu bheil a’ mhòr-chuid de na gnìomhan cron air an coileanadh air na h-aon nodan ri prìomh thagraidhean a’ phròiseict, tha seo air lùghdachadh mòr a thoirt air a’ chunnart gun tèid pods a ghluasad air sgàth dìth ghoireasan. Às deidh an clàr-ciùb a bharrachd a thoirt a-steach, cha do dh’ èirich duilgheadasan le clàradh neo-chòmhnard de ghnìomhan cron tuilleadh.
Leugh cuideachd artaigilean eile air ar blog:
Source: www.habr.com