ProHoster > Blogs > Administrācija > Papildu kube plānotāja izveide ar pielāgotu plānoŔanas noteikumu kopu

Papildu kube plānotāja izveide ar pielāgotu plānoŔanas noteikumu kopu

Papildu kube plānotāja izveide ar pielāgotu plānoŔanas noteikumu kopu

Kube plānotājs ir neatņemama Kubernetes sastāvdaļa, kas ir atbildÄ«gs par podziņu plānoÅ”anu mezglos saskaņā ar noteiktām politikām. Bieži vien Kubernetes klastera darbÄ«bas laikā mums nav jādomā par to, kuras politikas tiek izmantotas, lai ieplānotu podziņus, jo noklusējuma kube plānotāja politiku kopa ir piemērota lielākajai daļai ikdienas uzdevumu. Tomēr ir situācijas, kad mums ir svarÄ«gi precÄ«zi noregulēt pākstu pieŔķirÅ”anas procesu, un ir divi veidi, kā paveikt Å”o uzdevumu:

  1. Izveidojiet kube plānotāju ar pielāgotu noteikumu kopu
  2. Uzrakstiet savu plānotāju un iemāciet tam strādāt ar API servera pieprasījumiem

Å ajā rakstā es aprakstÄ«Å”u pirmā punkta ievieÅ”anu, lai atrisinātu kurtuvju nevienmērÄ«gas plānoÅ”anas problēmu vienā no mÅ«su projektiem.

ÄŖss ievads par to, kā darbojas kube plānotājs

ÄŖpaÅ”i vērts atzÄ«mēt faktu, ka kube-scheduler nav atbildÄ«gs par tieÅ”u podziņu plānoÅ”anu ā€” tas ir atbildÄ«gs tikai par mezgla noteikÅ”anu, uz kura novietot podziņu. Citiem vārdiem sakot, kube plānotāja darba rezultāts ir mezgla nosaukums, kuru tas atgriež API serverim, lai veiktu plānoÅ”anas pieprasÄ«jumu, un ar to arÄ« beidzas tā darbs.

Pirmkārt, kube plānotājs izveido to mezglu sarakstu, kuros var ieplānot podziņu saskaņā ar predikātu politikām. Tālāk katrs mezgls no Ŕī saraksta saņem noteiktu punktu skaitu saskaņā ar prioritāŔu politikām. Rezultātā tiek atlasÄ«ts mezgls ar maksimālo punktu skaitu. Ja ir mezgli, kuriem ir vienāds maksimālais punktu skaits, tiek atlasÄ«ts nejauÅ”s. Predikātu (filtrÄ“Å”anas) un prioritāŔu (vērtÄ“Å”anas) politiku sarakstu un aprakstu var atrast dokumentācija.

Problēmas ķermeņa apraksts

Neraugoties uz lielo skaitu dažādu Kubernetes klasteru, kas tiek uzturēts Nixys, mēs pirmo reizi saskārāmies ar plānoÅ”anas podu problēmu tikai nesen, kad vienam no mÅ«su projektiem bija nepiecieÅ”ams izpildÄ«t lielu skaitu periodisku uzdevumu (~100 CronJob entÄ«tiju). Lai pēc iespējas vienkārÅ”otu problēmas aprakstu, par piemēru ņemsim vienu mikropakalpojumu, kura ietvaros reizi minÅ«tē tiek palaists cron uzdevums, radot zināmu slodzi CPU. Lai izpildÄ«tu cron uzdevumu, tika pieŔķirti trÄ«s mezgli ar absolÅ«ti identiskiem raksturlielumiem (24 vCPU katrā).

Tajā paŔā laikā nav iespējams precÄ«zi pateikt, cik ilgi CronJob tiks izpildÄ«ts, jo ievades datu apjoms pastāvÄ«gi mainās. Vidēji normālas kube-plānotāja darbÄ«bas laikā katrs mezgls palaiž 3-4 darba gadÄ«jumus, kas rada ~20-30% no katra mezgla CPU slodzes:

Papildu kube plānotāja izveide ar pielāgotu plānoŔanas noteikumu kopu

Problēma pati par sevi ir tāda, ka dažkārt cron uzdevumu podi vairs netiek ieplānoti vienā no trim mezgliem. Tas nozīmē, ka kādā brīdī vienam no mezgliem nebija plānots neviens pods, savukārt pārējos divos mezglos darbojās 6-8 uzdevuma kopijas, radot ~40-60% no CPU slodzes:

Papildu kube plānotāja izveide ar pielāgotu plānoŔanas noteikumu kopu

Problēma atkārtojās absolÅ«ti nejauÅ”i un dažkārt korelēja ar brÄ«di, kad tika izlaista jauna koda versija.

Palielinot kube plānotāja reÄ£istrÄ“Å”anas lÄ«meni lÄ«dz 10. lÄ«menim (-v=10), mēs sākām reÄ£istrēt, cik punktu katrs mezgls ieguvis novērtÄ“Å”anas procesā. Parastās plānoÅ”anas darbÄ«bas laikā žurnālos var redzēt Ŕādu informāciju:

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

Tie. spriežot pēc žurnālos iegÅ«tās informācijas, katrs no mezgliem ieguva vienādu gala punktu skaitu un plānoÅ”anai tika izvēlēts nejauÅ”s. Problēmas plānoÅ”anas laikā žurnāli izskatÄ«jās Ŕādi:

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

No tā var redzēt, ka viens no mezgliem ieguva mazāk gala punktu nekā citi, un tāpēc plānoÅ”ana tika veikta tikai diviem mezgliem, kas ieguva maksimālo punktu skaitu. Tādējādi mēs noteikti bijām pārliecināti, ka problēma ir tieÅ”i pākstu plānoÅ”anā.

Tālākais problēmas risināŔanas algoritms mums bija acÄ«mredzams - analizējiet žurnālus, saprotiet, ar kādu prioritāti mezgls nesaņēma punktus, un, ja nepiecieÅ”ams, pielāgojiet noklusējuma kube plānotāja politikas. Tomēr Å”eit mēs saskaramies ar divām bÅ«tiskām grÅ«tÄ«bām:

  1. Maksimālajā mežizstrādes lÄ«menÄ« (10) tiek atspoguļoti punkti, kas iegÅ«ti tikai par dažām prioritātēm. IepriekÅ” minētajā žurnālu izvilkumā var redzēt, ka visām prioritātēm, kas atspoguļotas žurnālos, mezgli iegÅ«st vienādu punktu skaitu parastajā un problēmu plānoÅ”anā, taču gala rezultāts problēmu plānoÅ”anas gadÄ«jumā ir atŔķirÄ«gs. Tādējādi varam secināt, ka par dažām prioritātēm punktu skaitÄ«Å”ana notiek ā€œaizkulisēsā€, un mums nav iespējas saprast, par kuru prioritāti mezgls nesaņēma punktus. Mēs detalizēti aprakstÄ«jām Å”o problēmu izdot Kubernetes repozitorijs vietnē Github. RakstÄ«Å”anas laikā tika saņemta atbilde no izstrādātājiem, ka Kubernetes v1.15,1.16, 1.17 un XNUMX atjauninājumos tiks pievienots reÄ£istrÄ“Å”anas atbalsts.
  2. Nav vienkārÅ”s veids, kā saprast, ar kuru konkrētu politiku kopu kube plānotājs paÅ”laik strādā. Jā, iekŔā dokumentācija Å”is saraksts ir norādÄ«ts, taču tajā nav informācijas par to, kādi konkrēti svari ir pieŔķirti katrai prioritāŔu politikai. Varat skatÄ«t noklusējuma kube plānotāja svarus vai rediģēt politikas tikai Å”eit pirmkodi.

Ir vērts atzÄ«mēt, ka reiz mēs varējām reÄ£istrēt, ka mezgls nesaņēma punktus saskaņā ar ImageLocalityPriority politiku, kas pieŔķir punktus mezglam, ja tam jau ir lietojumprogrammas palaiÅ”anai nepiecieÅ”amais attēls. Tas nozÄ«mē, ka brÄ«dÄ«, kad tika izlaista jauna lietojumprogrammas versija, cron uzdevumam izdevās darboties divos mezglos, lejupielādējot tajos jaunu attēlu no docker reÄ£istra, un tādējādi divi mezgli saņēma augstāku gala rezultātu salÄ«dzinājumā ar treÅ”o. .

Kā jau rakstÄ«ju iepriekÅ”, žurnālos mēs neredzam informāciju par ImageLocalityPriority politikas novērtējumu, tāpēc, lai pārbaudÄ«tu savu pieņēmumu, mēs izmetām attēlu ar jauno lietojumprogrammas versiju treÅ”ajā mezglā, pēc kura plānoÅ”ana darbojās pareizi. . TieÅ”i ImageLocalityPriority politikas dēļ plānoÅ”anas problēma tika novērota diezgan reti, biežāk tā bija saistÄ«ta ar kaut ko citu. Tā kā mēs nevarējām pilnÄ«bā atkļūdot katru no noklusējuma kube plānotāja prioritāŔu sarakstā esoÅ”ajām politikām, mums bija nepiecieÅ”ama elastÄ«ga pod plānoÅ”anas politiku pārvaldÄ«ba.

Problēmas paziņojums

Mēs vēlējāmies, lai problēmas risinājums bÅ«tu pēc iespējas specifiskāks, tas ir, galvenajām Kubernetes entÄ«tijām (Å”eit mēs domājam noklusējuma kube plānotāju) vajadzētu palikt nemainÄ«gām. Mēs negribējām atrisināt problēmu vienā vietā un radÄ«t to citā. Tādējādi mēs nonācām pie diviem problēmas risināŔanas variantiem, par kuriem tika ziņots raksta ievadā - izveidojot papildu plānotāju vai rakstot savu. Galvenā prasÄ«ba cron uzdevumu plānoÅ”anai ir vienmērÄ«gi sadalÄ«t slodzi pa trim mezgliem. Å o prasÄ«bu var izpildÄ«t, izmantojot esoŔās kube plānotāja politikas, tāpēc, lai atrisinātu mÅ«su problēmu, nav jēgas rakstÄ«t savu plānotāju.

NorādÄ«jumi papildu kube plānotāja izveidei un izvietoÅ”anai ir aprakstÄ«ti dokumentācija. Tomēr mums Ŕķita, ka ar izvietoÅ”anas entÄ«tiju nepietiek, lai nodroÅ”inātu kļūdu toleranci tik svarÄ«ga pakalpojuma kā kube plānotājs darbÄ«bā, tāpēc mēs nolēmām izvietot jaunu kube plānotāju kā Static Pod, kas tiktu tieÅ”i uzraudzÄ«ts. autors Kubelets. Tādējādi jaunajam kube plānotājam ir Ŕādas prasÄ«bas:

  1. Pakalpojums ir jāizvieto kā Static Pod visos klasteru galvenajos projektos
  2. Kļūdu tolerance ir jānodroŔina gadījumā, ja aktīvais pods ar kube plānotāju nav pieejams
  3. PlānoŔanas galvenajai prioritātei jābūt mezglā pieejamo resursu skaitam (LeastRequestedPriority)

Risinājuma ievieŔana

Uzreiz ir vērts atzÄ«mēt, ka mēs veiksim visus darbus Kubernetes v1.14.7, jo Å Ä« ir versija, kas tika izmantota projektā. Sāksim ar manifesta rakstÄ«Å”anu mÅ«su jaunajam kube plānotājam. Ņemsim par pamatu noklusējuma manifestu (/etc/kubernetes/manifests/kube-scheduler.yaml) un izveidosim to Ŕādā formā:

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-config

ÄŖsumā par galvenajām izmaiņām:

  1. Apd un konteinera nosaukums ir mainīts uz kube-scheduler-cron
  2. Kā opcija tika definēta, tika norādÄ«ts portu 10151 un 10159 izmantoÅ”ana hostNetwork: true un mēs nevaram izmantot tos paÅ”us portus kā noklusējuma kube plānotājs (10251 un 10259)
  3. Izmantojot parametru --config, mēs norādījām konfigurācijas failu, ar kuru jāsāk pakalpojums
  4. Konfigurēta konfigurācijas faila (scheduler-custom.conf) un plānoÅ”anas politikas faila (scheduler-custom-policy-config.json) uzstādÄ«Å”ana no resursdatora

Neaizmirstiet, ka mÅ«su kube plānotājam bÅ«s nepiecieÅ”amas tiesÄ«bas, kas ir lÄ«dzÄ«gas noklusējuma tiesÄ«bām. Rediģēt tā klastera lomu:

kubectl edit clusterrole system:kube-scheduler

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

Tagad parunāsim par to, kas jāiekļauj konfigurācijas failā un plānoŔanas politikas failā:

  • Konfigurācijas fails (scheduler-custom.conf)
    Lai iegÅ«tu noklusējuma kube plānotāja konfigurāciju, ir jāizmanto parametrs --write-config-to no dokumentācija. IegÅ«to konfigurāciju ievietosim failā /etc/kubernetes/scheduler-custom.conf un reducēsim lÄ«dz Ŕādai formai:

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"

ÄŖsumā par galvenajām izmaiņām:

  1. Mēs iestatījām plānotāja nosaukumu kā pakalpojuma kube-scheduler-cron nosaukumu.
  2. Parametrā lockObjectName jums arī jāiestata mūsu pakalpojuma nosaukums un jāpārliecinās, ka parametrs leaderElect iestatīt uz patiesu (ja jums ir viens galvenais mezgls, varat iestatīt to uz false).
  3. Parametrā ir norādīts ceļŔ uz failu ar plānoŔanas politiku aprakstu algorithmSource.

Ir vērts tuvāk apskatÄ«t otro punktu, kurā mēs rediģējam atslēgas parametrus leaderElection. Lai nodroÅ”inātu kļūdu toleranci, esam iespējojuÅ”i (leaderElect) lÄ«dera (galvenā) atlases process starp mÅ«su kube plānotāja podiem, izmantojot tiem vienu galapunktu (resourceLock) ar nosaukumu kube-scheduler-cron (lockObjectName) kube sistēmas nosaukumvietā (lockObjectNamespace). Kā Kubernetes nodroÅ”ina galveno komponentu (ieskaitot kube plānotāju) augstu pieejamÄ«bu, var uzzināt raksts.

  • PlānoÅ”anas politikas fails (scheduler-custom-policy-config.json)
    Kā jau rakstÄ«ju iepriekÅ”, mēs varam uzzināt, ar kurām konkrētām politikām darbojas noklusējuma kube plānotājs, tikai analizējot tā kodu. Tas nozÄ«mē, ka mēs nevaram iegÅ«t failu ar plānoÅ”anas politikām noklusējuma kube plānotājam tāpat kā konfigurācijas failu. AprakstÄ«sim mÅ«s interesējoŔās plānoÅ”anas politikas failā /etc/kubernetes/scheduler-custom-policy-config.json Ŕādi:

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

Tādējādi kube plānotājs vispirms sastāda to mezglu sarakstu, kuriem var ieplānot podziņu saskaņā ar GeneralPredicates politiku (kas ietver politiku PodFitsResources, PodFitsHostPorts, HostName un MatchNodeSelector politiku kopu). Un tad katrs mezgls tiek novērtēts saskaņā ar politiku kopu prioritāŔu masÄ«vā. Lai izpildÄ«tu mÅ«su uzdevuma nosacÄ«jumus, uzskatÄ«jām, ka Ŕāds politiku kopums bÅ«tu optimālais risinājums. AtgādināŔu, ka politiku kopa ar to detalizētiem aprakstiem ir pieejama dokumentācija. Lai veiktu savu uzdevumu, varat vienkārÅ”i mainÄ«t izmantoto politiku kopu un pieŔķirt tām atbilstoÅ”us svarus.

Mēs nosauksim jaunā kube-plānotāja manifestu, kuru izveidojām nodaļas sākumā, kube-scheduler-custom.yaml un ievietosim to Ŕādā ceļā /etc/kubernetes/manifests trÄ«s galvenajos mezglos. Ja viss ir izdarÄ«ts pareizi, Kubelet katrā mezglā palaidÄ«s podziņu, un mÅ«su jaunā kube plānotāja žurnālos mēs redzēsim informāciju, ka mÅ«su politikas fails ir veiksmÄ«gi piemērots:

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:{}]'

Tagad atliek tikai norādīt mūsu CronJob specifikācijā, ka mūsu jaunajam kube plānotājam ir jāapstrādā visi pieprasījumi par tā aplikumu plānoŔanu:

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

Secinājums

Galu galā mēs ieguvām papildu kube plānotāju ar unikālu plānoÅ”anas politiku komplektu, kura darbu tieÅ”i uzrauga kubelets. Turklāt starp mÅ«su kube plānotāja podiem esam uzstādÄ«juÅ”i jauna vadÄ«tāja vēlÄ“Å”anas gadÄ«jumam, ja vecais vadÄ«tājs kādu iemeslu dēļ kļūst nepieejams.

Regulāras lietojumprogrammas un pakalpojumi joprojām tiek ieplānoti, izmantojot noklusējuma kube plānotāju, un visi cron uzdevumi ir pilnÄ«bā pārsÅ«tÄ«ti uz jauno. Cron uzdevumu radÄ«tā slodze tagad ir vienmērÄ«gi sadalÄ«ta visos mezglos. Ņemot vērā, ka lielākā daļa cron uzdevumu tiek izpildÄ«ti tajos paÅ”os mezglos, kur galvenās projekta lietojumprogrammas, tas ir ievērojami samazinājis risku, ka podi tiks pārvietoti resursu trÅ«kuma dēļ. Pēc papildu kube plānotāja ievieÅ”anas problēmas ar cron uzdevumu nevienmērÄ«gu plānoÅ”anu vairs neradās.

Lasiet arī citus rakstus mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru