🥇Xüsusi planlaşdırma qaydaları ilə əlavə kube-scheduler yaratmaq

Kube-scheduler Kubernetes-in ayrılmaz bir hissəsidir və podların spesifik siyasətlərə uyğun olaraq nodlara təyin edilməsindən məsuldur. Tez-tez Kubernetes klasteri işlədilərkən podların planlanmasının necə həyata keçirildiyi barədə düşünməyə ehtiyac yoxdur, çünki default kube-scheduler-in siyasətləri əksər gündəlik tapşırıqlar üçün uyğundur. Lakin, podların bölgüsü prosesini incə idarə etmək vacib olduğu hallar olur və bu məqsədlə iki yol var:

Xüsusi planlama qaydaları olan kube-scheduler yaratmaq
Öz scheduler-inizi yazmaq və onu API-server ilə işləməyə öyrətmək

Məqalə çərçivəsində birinci variantın tətbiqini, podların bərabər şəkildə planlanmaması problemini həll etmək üçün izah edəcəyəm.

Kube-scheduler-in iş prinsipi haqqında qısa giriş

Xüsusi qeyd etmək lazımdır ki, kube-scheduler podların birbaşa planlanmasından məsul deyil — yalnız podun yerləşdiriləcəyi nodu müəyyən edir. Başqa sözlə, kube-scheduler-in işinin nəticəsi, planlaşdırma sorğusuna API-serverə göndərdiyi nodun adıdır və bununla da onun işi bitir.

Əvvəlcə kube-scheduler, predikasiya siyasətlərinə uyğun olaraq podun planlana biləcəyi nodların siyahısını tərtib edir. Sonra, bu siyahıdan hər bir nod müəyyən bir sayda bal alır, prioritet siyasətlərinə uyğun olaraq. Nəticədə, ən çox bal toplayan nod seçilir. Əgər eyni maksimum balı toplayan nodlar varsa, təsadüfi seçilir. Predikasiya (filtrləmə) və prioritet (bal toplama) siyasətlərinin siyahısı və təsviri ilə tanış ola bilərsiniz. sənəd.

Problemin təsvirinə dair

Nixys-də bir çox müxtəlif Kubernetes klasterləri olsa da, podların planlaşdırılmasında problemi ilk dəfə yalnız yaxın vaxtlarda yaşadıq, bir layihəmizdə böyük sayda dövri vəzifələrin (təxminən 100 CronJob varlığı) yerinə yetirilməsini tələb edəndə. Problemin təsvirini daha da sadələşdirmək üçün, hər dəqiqə cron vəzifəsi işə salan bir mikroservisi götürək ki, bu da CPU üzərində müəyyən bir yük yaradır. Cron vəzifələrinin icrası üçün tamamilə eyni xüsusiyyətlərə malik üç nod ayrılıb (hər birində 24 vCPU).

Eyni zamanda, CronJob-un nə qədər vaxt aparacağını dəqiq söyləmək mümkün deyil, çünki daxil olan məlumatların həcmi daima dəyişir. Orta hesabla, kube-scheduler-in normal işlədiyi dövrdə, hər nodda 3-4 işin nüsxəsi işləyir ki, bu da hər nodun CPU-sində ~20-30% yük yaradır:

Problem buradadır ki, bəzən cron vəzifələrinin podları üç noddan birində planlaşdırılmağı dayandırırdı. Yəni, hansısa bir vaxtda bir nodda heç bir pod planlaşdırılmırdı, halbuki digər iki nodda 6-8 vəzifə işləyərək CPU-da təxminən 40-60% yük yaradırdı.

Problem tamamilə təsadüfi dövrlərlə təkrarlanırdı və nadir hallarda yeni kod versiyasının yayımlanması ilə əlaqələndirilirdi.

kube-scheduler’in loq səviyyəsini 10-a qaldırdıqdan sonra (-v=10) hər bir nodun qiymətləndirmə prosesi zamanı nə qədər xal topladığını qeyd etməyə başladıq. Planlaşdırma normal işlədiyi zaman loqlarda aşağıdakı məlumatı görə bilirdik:

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 100043

Yəni, əldə olunan məlumatlara əsasən, hər bir nod bərabər sayda yekun xal topladı və təsadüfi seçimlə planlaşdırıldı. Problemli planlaşdırma anında loglar aşağıdakı kimi görünürdü:

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

Bu, nodlardan birinin digərindən daha az nəticə puanı topladığını göstərir, buna görə də planlaşdırma yalnız maksimum bal toplayan iki node ilə həyata keçirildi. Beləliklə, problemin pods planlaşdırılmasında olduğunu dəqiq müəyyən etdik.

Problemin həlli üçün növbəti algoritm bizə aydın oldu — logları təhlil etmək, hansı prioritetə görə nodun puan toplaya bilmədiyini başa düşmək və lazım gələrsə, default kube-scheduler siyasətlərini düzəltmək. Ancaq burada iki ciddi çətinliklə üzləşdik:

Maksimal loglama səviyyəsində (10) yalnız bəzi prioritetlərə görə puan dəsti əks olunur. Yuxarıda qeyd olunan log parçalarında göründüyü kimi, loglarda əks olunan bütün prioritetlərdə nodlar, normal və problemli planlaşdırmada eyni sayda puan toplayır, lakin problemli planlaşdırma halında son nəticə fərqlidir. Beləliklə, bəzi prioritetlərə görə puanların hesablanmasının 'kadr arxasında' baş verdiyini və hansı prioritetə görə nodun puan toplaya bilmədiyini başa düşmək imkanımızın olmadığını deyə bilərik. Bu problemi biz issue Kubernetes’in GitHub reposunda ətraflı izah etdik. Məlumat yazılarkən, inkişaf etdiricilərdən alınan cavab, loglama dəstəyinin Kubernetes v1.15, 1.16 və 1.17 yeniləmələrində əlavə ediləcəyi idi.
Kube-scheduler'in hansı konkret siyasətlərlə işlədiyini anlamaq üçün sadə bir yol yoxdur. Bəli, sənəd bu siyahıda qeyd olunub, amma burada cada prioritet siyasəti üçün hansı konkret çəkilərin təyin edildiyi barədə məlumat yoxdur. Default kube-scheduler’in siyasətlərini görmək və ya düzəltmək yalnız mənbələrdə mümkündür..

Qeyd etmək lazımdır ki, bir dəfə ImageLocalityPriority siyasətinə görə nodun puan toplaya bilmədiyini təsdiqləyə bildik. Bu siyasət, nodda tətbiqdən istifadə üçün lazım olan görüntü varsa, nodu puanlandırır. Yəni, yeni versionun tətbiq edilməsi zamanı cron-tapşırığı iki nodda başlamışdı, yeni görüntünü docker registry'dən yükləyirdi, beləliklə iki nod üçün son puan üçüncü noddan daha yüksək oldu.

Yuxarıda qeyd etdiyim kimi, loglarda ImageLocalityPriority siyasətinin qiymətləndirilməsi haqqında məlumat görmürük, buna görə də öz şübhəmi təsdiqləmək üçün üçüncü nodda yeni versiyanın görüntüsünü çəkdikdən sonra planlaşdırma düzgün işləməyə başladı. Məhz ImageLocalityPriority siyasətinə görə planlaşdırma problemi nisbətən nadir baş verdi, daha çox başqaları ilə əlaqəli oldu. Default kube-scheduler’in prioritet siyasətlərini tam şəkildə debaq etmək imkanımızın olmaması, podların planlaşdırma siyasətləri ilə çevik idarəetmə ehtiyacını ortaya çıxardı.

Məsələnin qoyulması

Biz problemi mümkün qədər dəqiq bir şəkildə həll etmək istəyirdik, yəni Kubernetes-in əsas varlıqları (burada defolt kube-scheduler nəzərdə tutulur) dəyişməz qalmalıdır. Bir yerdə problemi həll edib, digər yerdə yaratmaq istəyirdik. Beləliklə, biz məqalənin girişində dilə gətirilən iki variantın həllinə gəldik - əlavə bir scheduler yaratmaq və ya öz schedulerimizi yazmaq. Cron tapşırıqlarının planlaşdırılması üçün əsas tələblər yüklərin üç nod arasında bərabər bölünməsidir. Bu tələbi artıq var olan kube-scheduler siyasətləri ilə yerinə yetirmək olar, buna görə bizim işimiz üçün öz scheduler yaratmağın mənası yoxdur.

Əlavə kube-scheduler yaratma və Deployment təlimatı aşağıdakılarda təsvir edilmişdir sənəd. Lakin bizə elə gəldi ki, Deployment varlıqları kube-scheduler kimi kritik bir xidmətin işləməsini təmin etmək üçün yetərli deyil, buna görə müstəqil bir kube-scheduler-i Static Pod olaraq işə salmağı qərara aldıq, bununla Kubelet birbaşa nəzarət edəcək. Beləliklə, yeni kube-scheduler üçün aşağıdakı tələblərimiz yaranır:

Xidmət klasterin bütün qovşaq ustalarında Static Pod kimi yerləşdirilməlidir
Aktiv kube-scheduler pod-u əlçatan olmadıqda, əlillik təmin edilməlidir
Planlaşdırmada əsas prioritet sərf olunan resursların sayı olmalıdır (LeastRequestedPriority)

Həllin reallığı

İlk növbədə qeyd etmək lazımdır ki, bütün işlərimizi Kubernetes v1.14.7-də aparacağıq, çünki məhz bu versiya layihədə istifadə olunub. Yeni kube-scheduler üçün manifest yazmaqla başlayırıq. Defolt manifesti (/etc/kubernetes/manifests/kube-scheduler.yaml) əsas götürərək onu aşağıdakı formada təqdim edirik:

növ: Pod
metadata:
  etiketlər:
    komponent: scheduler
    səviyyə: idarəetmə-mərkəzi
  ad: kube-scheduler-cron
  namespace: kube-system
spec:
      konteynerlər:
      - əmrlər:
        - /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
        şəkil: gcr.io/google-containers/kube-scheduler:v1.14.7
        imagePullPolicy: IfNotPresent
        canlılıqProbe:
          uğursuzluqSınır: 8
          httpGet:
            ev: 127.0.0.1
            yol: /healthz
            port: 10151
            sxem: HTTP
          ilkinGecikməSaniyələri: 15
          vaxtAşımıSaniyələri: 15
        ad: kube-scheduler-cron-konteyner
        resurslar:
          tələblər:
            cpu: '0.1'
        həcimMontajları:
        - montajYeri: /etc/kubernetes/scheduler.conf
          ad: kube-config
          yalnızOxuma: true
        - montajYeri: /etc/localtime
          ad: localtime
          yalnızOxuma: true
        - montajYeri: /etc/kubernetes/scheduler-custom.conf
          ad: scheduler-config
          yalnızOxuma: true
        - montajYeri: /etc/kubernetes/scheduler-custom-policy-config.json
          ad: policy-config
          yalnızOxuma: true
      hostNetwork: true
      öncəlikSinifi: system-cluster-critical
      həcimlər:
      - hostPath:
          yol: /etc/kubernetes/scheduler.conf
          növ: FileOrCreate
        ad: kube-config
      - hostPath:
          yol: /etc/localtime
        ad: localtime
      - hostPath:
          yol: /etc/kubernetes/scheduler-custom.conf
          növ: FileOrCreate
        ad: scheduler-config
      - hostPath:
          yol: /etc/kubernetes/scheduler-custom-policy-config.json
          növ: FileOrCreate
        ad: policy-config

Əsas dəyişikliklər haqqında qısa məlumat:

Pod və konteynerin adını kube-scheduler-cron olaraq dəyişdirdik
10251 və 10259 standart kube-scheduler ilə eyni portlardan istifadə edə bilmədiyimiz üçün 10151 və 10159 portlarını istifadə etməyimizi göstərdik hostNetwork: true və biz eyni portlardan istifadə edə bilmirik
Xidmətin başladılacağı konfiqurasiya faylını −config parametri ilə göstərdik
Konfiqurasiya faylını (scheduler-custom.conf) və planlaşdırma siyasəti faylını (scheduler-custom-policy-config.json) hostdan montaj etdik

Unutmayaq ki, kube-scheduler’imizə standart kube-scheduler ilə eyni icazələr lazım olacaq. Klaster rolunu redaktə edirik:

kubectl edit clusterrole system:kube-scheduler

...
   mənbəAdlar:
    - kube-scheduler
    - kube-scheduler-cron
...

İndi konfiqurasiya faylında və planlaşdırma siyasətləri faylında nələrin olmalı olduğunu müzakirə edək:

Konfiqurasiya faylı (scheduler-custom.conf)
Standart kube-scheduler konfiqurasiyasını əldə etmək üçün parametrdən istifadə etməliyik --write-config-to biz sənəd. Alınan konfiqurasiyanı /etc/kubernetes/scheduler-custom.conf faylında yerləşdirəcəyik və aşağıdakı şəkildə düzləşdirəcəyik:

apiVersion: kubescheduler.config.k8s.io/v1alpha1
növ: 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:
   siyasət:
     fayl:
       yol: "/etc/kubernetes/scheduler-custom-policy-config.json"

Əsas dəyişikliklər haqqında qısa məlumat:

schedulerName parametrində xidmətimizin adını kube-scheduler-cron olaraq təyin etdik.
Parametrdə lockObjectName həmçinin, xidmətimizin adını müəyyən etmək və leaderElect parametrinin true dəyərinə təyin olunduğuna əmin olmaq lazımdır (əgər sizdə yalnız bir master node varsa, false dəyərinə təyin edə bilərsiniz).
Planlaşdırma siyasətləri haqqında fayl yolunu algorithmSource.

parametrində göstərmək lazımdır. İkinci bəndə daha detallı şəkildə dayanmağı doğru sayırıq, burada leaderElectionüçün parametrləri redaktə edirik. Dayanıqlığı təmin etmək üçün biz aktiv etdik (leaderElect) podlarımız arasında lider (master) seçmək prosesini onların unikal endpoint-dən istifadə etməklə (resourceLock) kube-scheduler-cron adlanan (lockObjectName) kube-system ad məkanında (lockObjectNamespace). Kubernetes-də əsas komponentlərin (məsələn, kube-scheduler) yüksək əlçatanlığını necə təmin etdiyimiz barədə məlumat əldə etmək olar makalede.

Planlaşdırma siyasətləri faylı (scheduler-custom-policy-config.json)
Daha əvvəl qeyd etdiyim kimi — defolt kube-scheduler-ın hansı konkret siyasətlərlə işlədiyini yalnız onun kodunu analiz etməklə öyrənə bilərik. Yəni, defolt kube-scheduler üçün planlaşdırma siyasətləri faylını konfiqurasiya faylı ilə analoji olaraq əldə edə bilmirik. İstədiyimiz planlaşdırma siyasətlərini /etc/kubernetes/scheduler-custom-policy-config.json faylında aşağıdakı kimi təsvir edəcəyik:

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

Bu şəkildə, kube-scheduler əvvəlcə GeneralPredicates siyasətinə uyğun olaraq nəql edilə bilən nodların siyahısını yaradır (bu, PodFitsResources, PodFitsHostPorts, HostName və MatchNodeSelector siyasətləri də daxil olmaqla bir sıra siyasətləri əhatə edir). Sonra isə priority-lar massivindəki siyasətlərdən istifadə edərək hər bir nodun qiymətləndirilməsi həyata keçirilir. Bizim tapşırığımız üçün belə bir siyasət dəstinin optimal həll olduğunu düşündük. Yadımdadır, siyasətlərin dəstinin və onların detallı təsvirinin olduğu sənəd. Öz tapşırığınızı yerinə yetirmək üçün siz sadəcə istifadə olunan siyasət dəstini dəyişə və onlara müvafiq çəkilər təyin edə bilərsiniz.

Yeni kube-scheduler manifestini, əvvəlki fəsildə yaratdığımız, kube-scheduler-custom.yaml adlandıracağıq və onu /etc/kubernetes/manifests yolu ilə üç master node-da yerləşdirəcəyik. Hər şey düzgün yerinə yetirildikdə, hər nodda Kubelet pod-u başladacaq, və yeni kube-scheduler-ımızın loqlarıda siyasətlərimizin uğurla tətbiq olunduğuna dair məlumatları görəcəyik:

Konfiqurasiyadan cədvəlləşdirici yaratmaq: {{ } [{GeneralPredicates } ] [{ServiceSpreadingPriority 1 } {EqualPriority 1 } {LeastRequestedPriority 1 } {NodePreferAvoidPodsPriority 10000 } {NodeAffinityPriority 1 } ] [] 10 false}
Predikatı qeyd edirik: GeneralPredicates
GeneralPredicates tipli predikat artıq qeydə alınmışdır, təkrar istifadə olunur.
Prioriteti qeyd edirik: ServiceSpreadingPriority
ServiceSpreadingPriority tipli prioritet artıq qeydə alınmışdır, təkrar istifadə olunur.
Prioriteti qeyd edirik: EqualPriority
EqualPriority tipli prioritet artıq qeydə alınmışdır, təkrar istifadə olunur.
Prioriteti qeyd edirik: LeastRequestedPriority
LeastRequestedPriority tipli prioritet artıq qeydə alınmışdır, təkrar istifadə olunur.
Prioriteti qeyd edirik: NodePreferAvoidPodsPriority
NodePreferAvoidPodsPriority tipli prioritet artıq qeydə alınmışdır, təkrar istifadə olunur.
Prioriteti qeyd edirik: NodeAffinityPriority
NodeAffinityPriority tipli prioritet artıq qeydə alınmışdır, təkrar istifadə olunur.
'fit' predikatları 'map[GeneralPredicates:{}]' və prioritet funksiyaları 'map[EqualPriority:{} LeastRequestedPriority:{} NodeAffinityPriority:{} NodePreferAvoidPodsPriority:{} ServiceSpreadingPriority:{}]' olan cədvəlləşdirici yaradırıq.

İndi yalnız CronJob'ımızın spesifikasiyasında, pod'larının planlaşdırılması üçün bütün sorğuların yeni kube-scheduler'ımız tərəfindən işlənməli olduğunu qeyd etmək qalır:

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

Nəticə

Nəticədə, idarə olunan kubelet tərəfindən izləniləcək unikal planlaşdırma siyasətləri olan əlavə bir kube-scheduler əldə etdik. Bundan əlavə, köhnə liderin hər hansı bir səbəbdən əlçatmaz olması halında kube-scheduler'ımızın pod'ları arasında yeni lider seçimini uyğunlaşdırdıq.

Adi tətbiqlər və xidmətlər hələ də standart kube-scheduler vasitəsilə planlaşdırılır, lakin bütün cron vəzifələri tamamilə yeni sistemə köçürülmüşdür. İndi cron vəzifələrinin yaratdığı yük bütün nodelar arasında bərabər şəkildə paylanır. Əsas proqramların çalışdığı nodelarla eynik aktedici yerlərdə cron vəzifələrinin fəaliyyəti, resurs çatışmazlığından dolayı pod'lardan köçmə riskini əhəmiyyətli dərəcədə azaltmağa imkan verdi. Əlavə kube-scheduler'ımızı tətbiq etdikdən sonra, cron vəzifələrinin qeyri-bərabər planlaşdırılması ilə bağlı problemlər artıq yaşanmadı.