Täiendava kube-scheduler'i loomine kohandatud planeerimisreeglitega

Kube-scheduler on Kubernetes'i hädavajalik komponent, mis vastutab pod'ide planeerimise eest sõlmedele vastavalt määratud poliitikatele. Tihti ei pea me Kubernetes'i klastrit kasutades mõtlema, milliste poliitikate alusel pod'e planeeritakse, kuna vaikimisi kube-scheduler'i poliitikakomplekt sobib enamikeks igapäevasteks ülesanneteks. Siiski on olukordi, kus on oluline täpselt juhtida pod'ide jaotamise protsessi, ning selle saavutamiseks on kaks teed:

1. Luua kube-scheduler kohandatud reeglite komplektiga
2. Kirjutada oma scheduler ja õpetada seda töötama API-serveri päringutega

Selles artiklis kirjeldan ma esimese punkti elluviimist, et lahendada ühtlaste pod'ide planeerimise probleem meie projektides.

Lühike sissejuhatus kube-scheduler'i tööle

Tuleb erilist tähelepanu pöörata sellele, et kube-scheduler ei vastuta pod'ide otsemise planeerimise eest — see vastutab ainult selle määramise eest, millisele nodile pod'i paigutada. Teisisõnu, kube-scheduler'i töö tulemuseks on nodi nimi, mille ta tagastab API-serverile planeerimise päringule ja sellega tema töö lõppeb.

Esmalt koostab kube-scheduler nodide nimekirja, kuhu pod võib olla planeeritud vastavalt predicate poliitikatele. Seejärel saab iga nod, mis on selles nimekirjas, teatud hulga punkte vastavalt prioriteet poliitikatele. Tulemusena valitakse nod, mis on kogunud maksimaalse arvu punkte. Kui on nod, mis on saanud sama maksimumpunktide arvu, valitakse juhuslik. Predicate (filtreerimise) ja prioriteetide (hindamise) poliitikate nimekirja ja kirjeldusega saab tutvuda dokumentatsioonis.

Probleemi kirjelduse tekst

Hoolimata Nixysis teenindatavatest erinevatest Kubernetes klastritest, olime podide planeerimise probleemiga esmakordselt silmitsi alles hiljuti, kui ühe meie projekti raames tekkis vajadus käivitada suur hulk perioodilisi ülesandeid (~100 CronJobi üksust). Probleemi võimalikult lihtsaks kirjeldamiseks toome näiteks ühe mikroteenuse, mille raames käivitub iga minuti tagant cron-ülesanne, mis tekitab CPU-le teatud koormuse. Cron-ülesande käitamiseks eraldati kolm täiesti identset sõlme (igal 24 vCPU-d).

Sellegipoolest ei saa täpselt öelda, kui kaua CronJobi täitmine kestab, kuna sisendandmete maht muutub pidevalt. Keskmiselt, normaalses kube-schedulear'i töö korral töötab igal sõlmel 3-4 ülesande eksemplari, mis tekitavad 20-30% koormust iga sõlme CPU-le:

Probleem seisneb selles, et mõnikord peatusid cron-tööde podid ühe kolmest noodist planeerimast. See tähendab, et mingil hetkel ei planeeritud ühtegi poodi ühele nodile, samas kui kahel teisel noodil töötas 6-8 ülesande koopia, tekitades umbes 40-60% koormust CPU-le:

Probleem kordus täiesti juhuslikult ja harva korreleerus uue koodi versiooni väljalaskmise hetkega.

Suurendades kube-scheduler’i logimist 10. tasemele (-v=10), hakkasime fikseerima, kui palju punkte iga node hindamisprotsessis kogub. Tavalise planeerimise töö ajal võis logides näha järgmisi andmeid:

resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: BalancedResourceAllocation, maht 23900 millicores 67167186944 mälu baiti, kogusumma taotlus 1387 millicores 4161694720 mälu baiti, skoor 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: BalancedResourceAllocation, maht 23900 millicores 67167186944 mälu baiti, kogusumma taotlus 1347 millicores 4444810240 mälu baiti, skoor 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: LeastResourceAllocation, maht 23900 millicores 67167186944 mälu baiti, kogusumma taotlus 1387 millicores 4161694720 mälu baiti, skoor 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: BalancedResourceAllocation, maht 23900 millicores 67167186944 mälu baiti, kogusumma taotlus 1687 millicores 4790840320 mälu baiti, skoor 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: LeastResourceAllocation, maht 23900 millicores 67167186944 mälu baiti, kogusumma taotlus 1347 millicores 4444810240 mälu baiti, skoor 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: LeastResourceAllocation, maht 23900 millicores 67167186944 mälu baiti, kogusumma taotlus 1687 millicores 4790840320 mälu baiti, skoor 9
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: NodeAffinityPriority, skoor: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: NodeAffinityPriority, skoor: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: NodeAffinityPriority, skoor: (0)                                                                                       
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node01: InterPodAffinityPriority, skoor: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: TaintTolerationPriority, skoor: (10)                                                                                   
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node02: InterPodAffinityPriority, skoor: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: TaintTolerationPriority, skoor: (10)                                                                                   
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node01: SelectorSpreadPriority, skoor: (10)                                                                                                        
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node03: InterPodAffinityPriority, skoor: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: TaintTolerationPriority, skoor: (10)                                                                                   
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node02: SelectorSpreadPriority, skoor: (10)                                                                                                        
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node03: SelectorSpreadPriority, skoor: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: SelectorSpreadPriority, skoor: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: SelectorSpreadPriority, skoor: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: SelectorSpreadPriority, skoor: (10)                                                                                    
generic_scheduler.go:781] Host Node01 -> skoor 100043                                                                                                                                                                        
generic_scheduler.go:781] Host Node02 -> skoor 100043                                                                                                                                                                        
generic_scheduler.go:781] Host Node03 -> skoor 100043

See, logidest saadud teabe põhjal saavutas iga nodi võrdselt palju lõpppunne ja planeerimise jaoks valiti juhuslik variant. Probleemse planeerimise hetkel nägid logid välja järgmiselt:

resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: Tasakaalustatud Ressursi Jagamine, maht 23900 millicore 67167186944 mälubaiti, kogu nõue 1587 millicore 4581125120 mälubaiti, skoor 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: Tasakaalustatud Ressursi Jagamine, maht 23900 millicore 67167186944 mälubaiti, kogu nõue 1087 millicore 3532549120 mälubaiti, skoor 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: Minimaalne Ressursi Jagamine, maht 23900 millicore 67167186944 mälubaiti, kogu nõue 1587 millicore 4581125120 mälubaiti, skoor 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: Tasakaalustatud Ressursi Jagamine, maht 23900 millicore 67167186944 mälubaiti, kogu nõue 987 millicore 3322833920 mälubaiti, skoor 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: Minimaalne Ressursi Jagamine, maht 23900 millicore 67167186944 mälubaiti, kogu nõue 987 millicore 3322833920 mälubaiti, skoor 9 
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: Minimaalne Ressursi Jagamine, maht 23900 millicore 67167186944 mälubaiti, kogu nõue 1087 millicore 3532549120 mälubaiti, skoor 9
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node03: InterPod Ühtsuse Prioriteet, skoor: (0)                                                                                                        
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node02: InterPod Ühtsuse Prioriteet, skoor: (0)                                                                                                        
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node01: InterPod Ühtsuse Prioriteet, skoor: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: TaintTolerationPrioriteet, skoor: (10)                                                                                   
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node03: Selektori Leviku Prioriteet, skoor: (10)                                                                                                        
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node02: Selektori Leviku Prioriteet, skoor: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: TaintTolerationPrioriteet, skoor: (10)                                                                                   
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node01: Selektori Leviku Prioriteet, skoor: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: Node Ühtsuse Prioriteet, skoor: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: Selektori Leviku Prioriteet, skoor: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: Selektori Leviku Prioriteet, skoor: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: TaintTolerationPrioriteet, skoor: (10)                                                                                   
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: Node Ühtsuse Prioriteet, skoor: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: Node Ühtsuse Prioriteet, skoor: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: Selektori Leviku Prioriteet, skoor: (10)                                                                                    
generic_scheduler.go:781] Host Node03 => skoor 100041                                                                                                                                                                        
generic_scheduler.go:781] Host Node02 => skoor 100041                                                                                                                                                                        
generic_scheduler.go:781] Host Node01 => skoor 100038

Millest tuleneb, et üks sõlmedest kogus vähem punkte kui teised ning seetõttu toimus planeerimine vaid kahe sõlme peal, mis kogusid maksimaalse skoori. Nii saime veenduda, et probleem on just podide planeerimises.

Järgmine lahenduse algoritm oli meie jaoks ilmne — analüüsida logisid, mõista, millise prioriteedi tõttu sõlm punkte ei kogunud ja vajadusel kohandada kuberneti kube-scheduler'i põhikeerukuse poliitikaid. Siiski seisisime silmitsi kahe olulise väljakutsega:

1. Maksimaalsel logimise tasemel (10) kajastatakse punktide komplekti ainult teatud prioriteetide põhjal. Ülaltoodud logide lõigus võib märgata, et kõikide logides kajastatud prioriteetide puhul saavutavad nodid tavapärase ja probleemse planeerimise juures sama arvu punkte, kuid probleemse planeerimise korral on lõpptulemus erinev. Seega võib järeldada, et teatud prioriteetide puhul toimub punktide arvestamine „kaamera taguses”, ja meil puudub igasugune võimalus mõista, mille tõttu nodid punkte ei kogunud. Seda probleemi oleme kirjeldanud probleem Kubernetes'e Githubi hoidlas. Artikli kirjutamise hetkel oli arendajatelt saadud vastus, et logimise tugi lisatakse Kubernetes v1.15, 1.16 ja 1.17 uuendustes.
2. Ei ole lihtsat viisi mõista, millise konkreetse poliitikakomplektiga kube-scheduler praegu töötab. Jah, see loetelu on olemas, kuid selles ei ole teavet, millised konkreetsed kaalud on määratud igale prioriteedi poliitikale. Näha kaalusid või muuta vaikimisi kube-scheduler'i poliitikaid on võimalik ainult dokumentatsioonis see selles loetletud, kuid seal pole teavet, millised konkreetsed kaalud on määratud iga prioriteedi poliitika jaoks. Nähtavad kaalud või redigeerida vaikimisi kube-scheduler'i poliitikaid saab ainult allikates.

On tähelepanuväärne, et üks kord suutsime fikseerida, et sõlm (node) ei kogunud punkte ImageLocalityPriority poliitika järgi, mis annab sõlmele punkte, kui sellel on juba olemas vajalik pilt rakenduse käivitamiseks. See tähendab, et uue rakenduse versiooni väljalaske hetkel jõudis cron-ülesanne käivituda kahel sõlmel, laadides neile uue pildi docker registrist alla, ja seega said need kaks sõlme võrreldes kolmandaga suurema lõpppunktide arvu.

Nagu ma juba varem mainisin, ei näe me logides teavet ImageLocalityPriority poliitika hindamise kohta. Seetõttu, et lõplikult oma oletust kontrollida, tõmbasime uue rakenduse versiooni pildi kolmandale sõlmele, mille järel planeerimine hakkas korralikult tööle. Just ImageLocalityPriority poliitika tõttu esines planeerimise probleem piisavalt harva, enamasti oli see seotud millegagi muuga. Kuna me ei saanud täielikult iga poliitika prioriteetide loendis debaida (debug), tekkis vajadus paindliku podide planeerimise poliitikate haldamise järele.

Ülesande seadmine

Soovisime, et probleemide lahendamine oleks võimalikult sihipärane, st Kubernetes'i põhielemendid (siin mõeldakse vaikimisi kube-scheduler'it) peaksid jääma muutumatuks. Me ei soovinud probleemi lahendada ühes kohas ja teises kohas luua uut. Seetõttu jõudsime kahe probleemilahenduseni, mis olid artikli sissejuhatuses välja toodud — lisascheduler'i loomine või oma kirjutamine. Peamine nõue cron-tööde planeerimisele on koormuse ühtlane jaotamine kolme nodi vahel. Seda nõuet saab rahuldada olemasolevate kube-scheduler'i poliitikate abil, seega ei ole meie ülesande lahendamiseks mõtet kirjutada oma scheduling'i programmi.

Lisakube-scheduler'i loomise ja juurutamise juhised on kirjeldatud dokumentatsioonis. Siiski nägime, et juurutuse elemendid ei ole piisavad sellise kriitilise teenuse nagu kube-scheduler tööhäirekindluse tagamiseks, mistõttu otsustasime juurutada uue kube-scheduler'i Static Pod'ina, mida jälgib otse Kubelet. Seega tulid meil välja järgmised nõuded uuele kube-scheduler'ile:

1. Teenust tuleb juurutada Static Pod'ina kõigis kinnitusklastri mestreides.
2. Aktive pod'i puudumise korral tuleb tagada tõrgeteta töö.
3. Planeerimisel peaks peamiseks prioriteediks olema sõlme saadaval olevate ressursside hulk (LeastRequestedPriority).

Lahenduse rakendamine.

Oluline on märkida, et kõik tööd teeme Kubernetes v1.14.7 versioonis, kuna just seda versiooni kasutati projektis. Alustame oma uue kube-scheduler’i jaoks manifesti kirjutamist. Võtame aluseks vaikimisi manifesti (/etc/kubernetes/manifests/kube-scheduler.yaml) ja kohandame selle järgmisesse vormi:

tüüp: Pod
metaandmed:
  sildid:
    komponent: scheduleri
    tase: kontrolli-tasand
  nimi: kube-scheduler-cron
  nimetusruum: kube-system
spetsifikatsioon:
      konteinerid:
      - käsk:
        - /usr/local/bin/kube-scheduler
        - --aadress=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
        pilt: gcr.io/google-containers/kube-scheduler:v1.14.7
        pilditõmbepoliitika: IfNotPresent
        elusuurimis:
          ebaõnnestumise künnis: 8
          httpGet:
            host: 127.0.0.1
            tee: /healthz
            port: 10151
            skeem: HTTP
          algne viivitus sekundites: 15
          viivituse sekundid: 15
        nimi: kube-scheduler-cron-container
        ressursid:
          nõudmised:
            cpu: '0.1'
        mahuMäed:
        - mountPath: /etc/kubernetes/scheduler.conf
          nimi: kube-config
          ainultLugemiseks: true
        - mountPath: /etc/localtime
          nimi: localtime
          ainultLugemiseks: true
        - mountPath: /etc/kubernetes/scheduler-custom.conf
          nimi: scheduler-config
          ainultLugemiseks: true
        - mountPath: /etc/kubernetes/scheduler-custom-policy-config.json
          nimi: policy-config
          ainultLugemiseks: true
      hostNetwork: true
      prioriteediKlassiNimi: system-cluster-critical
      mahud:
      - hostPath:
          tee: /etc/kubernetes/scheduler.conf
          tüüp: FileOrCreate
        nimi: kube-config
      - hostPath:
          tee: /etc/localtime
        nimi: localtime
      - hostPath:
          tee: /etc/kubernetes/scheduler-custom.conf
          tüüp: FileOrCreate
        nimi: scheduler-config
      - hostPath:
          tee: /etc/kubernetes/scheduler-custom-policy-config.json
          tüüp: FileOrCreate
        nimi: policy-config

Lühidalt peamistest muudatustest:

1. Muudeti podi ja konteineri nimi kube-scheduler-croniks
2. Määrati portide 10151 ja 10159 kasutamine, kuna on määratud valik hostNetwork: true ja me ei saa kasutada samu porte nagu vaikimisi kube-scheduler (10251 ja 10259)
3. Parameetriga —config määrasime teenuse käivitamiseks vajaliku konfiguratsioonifaili
4. Seadsime konfiguratsioonifaili (scheduler-custom.conf) ja planeerimispoliitikate faili (scheduler-custom-policy-config.json) monteerimise hostilt

Ärme unusta, et meie kube-scheduler vajab õigusi, mis on sarnased vaikimisi õigustega. Redigeerime selle klastrirulli:

kubectl edit clusterrole system:kube-scheduler

...
   resourceNames:
    - kube-scheduler
    - kube-scheduler-cron
...

Nüüd räägime siitä, mis peab sisalduma konfiguratsioonifailis ja planeerimispoliitikate failis:

• Konfiguratsioonifail (scheduler-custom.conf)
  Vaikimisi kube-scheduler'i konfiguratsiooni saamiseks tuleb kasutada parameetrit --write-config-to kohast dokumentatsioonis. Saadud konfiguratsiooni paigutame faili /etc/kubernetes/scheduler-custom.conf ja kujundame selle järgmise välimusega:

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"

Lühidalt peamistest muudatustest:

1. Asetasime schedulerName'i väärtuseks meie teenuse nime kube-scheduler-cron.
2. Mõttes lockObjectName peame samuti määrama meie teenuse nime ja veenduma, et parameeter leaderElect on seatud väärtusele true (kui sul on üks master-node, võib väärtuseks seada false).
3. Määrasime teed planeerimispoliitikate kirjelduse faili parameetris algorithmSource.

Tasub natuke põhjalikumalt peatuda teisel punktis, kus redigeerime valiku võtme parameetreid leaderElection. Et tagada rikekindlus, aktiveerisime (leaderElect) juhi (masteri) valimise protsessi meie kube-scheduler'i podide vahel, kasutades neile ühte lõpp-punkti (resourceLock) nimega kube-scheduler-cron (lockObjectName) nimel kube-system (lockObjectNamespace). Kuidas Kubernetes tagab põhikomponentide (sealhulgas kube-scheduler) kõrge kAvailability kohta saab lugeda artiklis.

• Plaani fail (scheduler-custom-policy-config.json)
  Kuidas ma juba varem ütlesin — teada, milliste konkreetsete poliitikatega töötab vaikimisi kube-scheduler, saame ainult seda analüüsides tema koodi. See tähendab, et me ei saa faili vaikesed kube-scheduler'i planeerimise poliitikatega sarnasele konfiguratsioonifailile. Kirjeldame huvipoliitikaid planeerimise failis /etc/kubernetes/scheduler-custom-policy-config.json järgmiselt:

{
  "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
}

Seega koostab kube-scheduler esmalt list sõlmedest, kuhu saab vastavalt GeneralPredicates poliitikale (mis sisaldab setti poliitikaid PodFitsResources, PodFitsHostPorts, HostName ja MatchNodeSelector) määrata pod. Järgmisena hinnatakse igat sõlme vastavalt prioriteetide massiivi poliitikate kogumile. Meie ülesande tingimuste täitmiseks arvasime, et selline poliitikate kogum oleks optimaalne lahendus. Meenutame, et poliitikate kogum koos detailsete kirjeldustega on saadaval dokumentatsioonis. Oma ülesande täitmiseks võite lihtsalt muuta kasutatavaid poliitikaid ja määrata neile vastavad kaalud.

Uue kube-scheduler'i manifest, mille me lõ chapteri alguses lõime, nimetame kube-scheduler-custom.yaml-iks ja asetame järgmisele teele /etc/kubernetes/manifests kolme meistri sõlme peale. Kui kõik on õigesti tehtud, käivitab Kubelet igas sõlmes pod'i ning meie uue kube-scheduler'i logides näeme teavet selle kohta, et meie poliitikate fail rakendus edukalt:

Kavandaja loomine konfiguratsioonist: {{ } [{GeneralPredicates }][{ServiceSpreadingPriority 1 } {EqualPriority 1 } {LeastRequestedPriority 1 } {NodePreferAvoidPodsPriority 10000 } {NodeAffinityPriority 1 }][] 10 vale}
Registreerimine ennustust: GeneralPredicates
Ennustustüüp GeneralPredicates on juba registreeritud, taaskasutamine.
Registreerimine prioriteet: ServiceSpreadingPriority
Prioriteeditüüp ServiceSpreadingPriority on juba registreeritud, taaskasutamine.
Registreerimine prioriteet: EqualPriority
Prioriteeditüüp EqualPriority on juba registreeritud, taaskasutamine.
Registreerimine prioriteet: LeastRequestedPriority
Prioriteeditüüp LeastRequestedPriority on juba registreeritud, taaskasutamine.
Registreerimine prioriteet: NodePreferAvoidPodsPriority
Prioriteeditüüp NodePreferAvoidPodsPriority on juba registreeritud, taaskasutamine.
Registreerimine prioriteet: NodeAffinityPriority
Prioriteeditüüp NodeAffinityPriority on juba registreeritud, taaskasutamine.
Kavandaja loomine sobivusennustustega 'map[GeneralPredicates:{}]' ja prioriteedifunktsioonidega 'map[EqualPriority:{} LeastRequestedPriority:{} NodeAffinityPriority:{} NodePreferAvoidPodsPriority:{} ServiceSpreadingPriority:{}]'

Nüüd on jäänud ainult näidata meie CronJob'i spekis, et kõik taotlused selle pod'ide ajastamiseks peaks töötlema meie uus kube-scheduler:

...
 jobTemplate:
    spec:
      template:
        spec:
          schedulerName: kube-scheduler-cron
...

Kokkuvõte

Lõpuks saime täiendava kube-scheduler'i, millel on ainulaadne planeerimisreeglite kogum, mida jälgib otse kubelet. Lisaks seadistasime uue liidri valimise meie kube-scheduler'i podide vahel, juhul kui vana liider mingitel põhjustel ei ole saadaval.

Tavalised rakendused ja teenused jätkavad planeerimist vaikimisi kube-scheduler'i kaudu, samas kui kõik cron-ülesanded on täielikult üle viidud uuele. Cron-ülesannete tekitatud koormus jaotatakse nüüd ühtlaselt kõigi node'ide vahel. Arvestades, et enamik cron-ülesandeid täidetakse samadel node'idel, kus asuvad ka projekti põhiraamatud, on see aidanud oluliselt vähendada podide kolimise riski ressursside puuduse tõttu. Pärast täiendava kube-scheduler'i rakendamist enam cron-ülesannete ebaühtlasest planeerimisest probleeme ei tekkinud.

Vaata ka teisi artikleid meie blogis:

• Liikluskorraldus Kubernetes'i klastris Calico'ga
• Calicoga võrgu poliitikate rakendamise variantide mõistmine.
• Kui Linuxi conntrack ei ole enam teie sõber
• 4 näidet iota-loenditest
• Kubernetes klastrite uuendamine ilma seisakuta
• Nulla aega jaandmine ning andmebaasid
• Kubernetes: miks on süsteemi ressursihalduse seadistamine nii oluline?

Allikas: habr.com