🥇 Ƙirƙirar ƙarin kube-scheduler tare da tsarin al'ada na ƙa'idodin tsarawa

Kube-scheduler wani muhimmin sashi ne na Kubernetes, wanda ke da alhakin tsara shirye-shiryen kwasfa a cikin nodes daidai da ƙayyadaddun manufofi. Sau da yawa, a lokacin aikin Kubernetes cluster, ba dole ba ne mu yi tunani game da waɗanne manufofi ake amfani da su don tsara kwasfan fayiloli, tun da saitin manufofin kube-scheduler tsoho ya dace da yawancin ayyukan yau da kullun. Koyaya, akwai yanayi idan yana da mahimmanci a gare mu mu daidaita tsarin rarraba kwas ɗin, kuma akwai hanyoyi guda biyu don cim ma wannan aikin:

Ƙirƙiri mai tsara tsarin kube tare da saitin ƙa'idodi na al'ada
Rubuta mai tsara jadawalin ku kuma koya masa yin aiki tare da buƙatun uwar garken API

A cikin wannan labarin, zan bayyana aiwatar da batu na farko don magance matsalar rashin daidaituwar tsarawa na murhu a ɗayan ayyukanmu.

Takaitaccen gabatarwa ga yadda kube-scheduler ke aiki

Yana da mahimmanci a lura da cewa kube-scheduler ba shi da alhakin tsara shirye-shiryen kwasfan fayiloli kai tsaye - yana da alhakin ƙayyade kumburin da za a sanya kwaf ɗin. A wasu kalmomi, sakamakon aikin kube-scheduler shine sunan kumburi, wanda yake komawa zuwa uwar garken API don buƙatun tsarawa, kuma a nan ne aikinsa ya ƙare.

Na farko, kube-scheduler ya tattara jerin nodes waɗanda za a iya tsara kwaf ɗin bisa ga manufofin tsinkaya. Na gaba, kowane kumburi daga wannan jeri yana karɓar takamaiman adadin maki daidai da manufofin fifiko. A sakamakon haka, an zaɓi kumburi tare da matsakaicin adadin maki. Idan akwai nodes waɗanda ke da matsakaicin maƙi ɗaya, ana zaɓin bazuwar. Za a iya samun jeri da bayanin ma'auni (tace) da manufofin fifiko (maki) a ciki takardun.

Bayanin jikin matsala

Duk da yawan nau'ikan gungu na Kubernetes daban-daban da ake kiyaye su a Nixys, mun fara cin karo da matsalar tsara kwasfan fayiloli kwanan nan, lokacin da ɗayan ayyukanmu ya buƙaci gudanar da ayyuka masu yawa na lokaci-lokaci (~ 100 CronJob ƙungiyoyi). Don sauƙaƙe bayanin matsalar kamar yadda zai yiwu, za mu ɗauki a matsayin misali ɗaya microservice, wanda aka ƙaddamar da aikin cron sau ɗaya a minti ɗaya, ƙirƙirar wasu kaya akan CPU. Don gudanar da aikin cron, nodes uku tare da cikakkun halaye iri ɗaya an ware su (24 vCPUs akan kowane).

A lokaci guda, ba zai yiwu a faɗi da daidaito tsawon lokacin da CronJob zai ɗauka don aiwatarwa ba, tunda ƙarar bayanan shigarwa koyaushe yana canzawa. A matsakaita, yayin aiki na yau da kullun na kube-scheduler, kowane kumburi yana gudanar da ayyukan ayyuka 3-4, waɗanda ke haifar da ~ 20-30% na kaya akan CPU na kowane kumburi:

Matsalar kanta ita ce, wani lokacin cron task pods sun daina tsarawa akan ɗaya daga cikin nodes uku. Wato, a wani lokaci a cikin lokaci, ba a shirya kwasfa ɗaya ba don ɗaya daga cikin nodes, yayin da a kan sauran nodes guda biyu 6-8 kofe na aikin suna gudana, suna ƙirƙirar ~ 40-60% na nauyin CPU:

Matsalar ta sake faruwa tare da mitar bazuwar kuma lokaci-lokaci tana da alaƙa da lokacin da aka fitar da sabon sigar lambar.

Ta hanyar haɓaka matakin kube-scheduler zuwa mataki na 10 (-v=10), mun fara rikodin maki nawa ne kowane kumburi ya samu yayin aikin tantancewa. A lokacin aiki na yau da kullun, ana iya ganin bayanai masu zuwa a cikin rajistan ayyukan:

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

Wadancan. yin la'akari da bayanan da aka samu daga rajistan ayyukan, kowane ɗayan nodes ya sami daidaitattun adadin maki na ƙarshe kuma an zaɓi bazuwar don tsarawa. A lokacin tsara matsala, rajistan ayyukan sun kasance kamar haka:

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

Daga abin da za a iya gani cewa daya daga cikin nodes ya sami ƙarancin maki na ƙarshe fiye da sauran, don haka an gudanar da shirin kawai don nodes biyu waɗanda suka sami matsakaicin maki. Don haka, ba shakka mun tabbata cewa matsalar ta ta'allaka ne a cikin tsara tsarin kwasfa.

Ƙarin algorithm don magance matsalar ya bayyana a gare mu - bincika rajistan ayyukan, fahimtar menene fifikon kumburin bai sami maki ba kuma, idan ya cancanta, daidaita manufofin kube-scheduler tsoho. Koyaya, a nan muna fuskantar matsaloli guda biyu masu mahimmanci:

A matsakaicin matakin shiga (10), maki da aka samu don wasu abubuwan fifiko kawai ana nunawa. A cikin abin da ke sama na rajistan ayyukan, zaku iya ganin cewa ga duk manyan abubuwan da aka nuna a cikin rajistan ayyukan, nodes suna ƙididdige adadin maki iri ɗaya a cikin tsarin al'ada da tsara matsala, amma sakamakon ƙarshe a cikin yanayin tsara matsala ya bambanta. Don haka, zamu iya yanke shawarar cewa ga wasu abubuwan da suka fi dacewa, maki yana faruwa "a bayan al'amuran", kuma ba mu da wata hanyar da za mu fahimci wane fifikon kumburin bai sami maki ba. Mun bayyana wannan matsala daki-daki batun Ma'ajiyar Kubernetes akan Github. A lokacin rubutawa, an karɓi amsa daga masu haɓakawa cewa za a ƙara tallafin shiga a cikin sabuntawar Kubernetes v1.15,1.16, 1.17 da XNUMX.
Babu wata hanya mai sauƙi don fahimtar wane takamaiman tsarin manufofin kube-scheduler ke aiki da su a halin yanzu. iya, in takardun An jera wannan jeri, amma ba ya ƙunshi bayanai game da takamaiman ma'aunin nauyi da aka sanya wa kowane manufofin fifiko. Kuna iya ganin ma'auni ko shirya manufofin tsohowar kube-scheduler kawai a ciki kafofin.

Yana da kyau a lura cewa da zarar mun sami damar yin rikodin cewa kumburi bai sami maki bisa ga manufar ImageLocaityPriority ba, wanda ke ba da lambar yabo zuwa kumburi idan ya riga ya sami hoton da ya dace don gudanar da aikace-aikacen. Wato, a lokacin da aka fitar da sabon sigar aikace-aikacen, aikin cron ya gudanar da aiki akan nodes biyu, yana zazzage musu sabon hoto daga wurin rajistar docker, don haka nodes biyu sun sami maki na ƙarshe mafi girma dangane da na uku. .

Kamar yadda na rubuta a sama, a cikin rajistan ayyukan ba mu ga bayanai game da kimantawa na ImageLocalityPriority manufofin, don haka don bincika tunaninmu, mun zubar da hoton tare da sabon sigar aikace-aikacen a kan kulli na uku, bayan haka tsarin aiki yayi aiki daidai. . Daidai saboda manufar ImageLocaityPriority ne aka lura da matsalar tsarawa da wuya; sau da yawa ana danganta shi da wani abu dabam. Saboda gaskiyar cewa ba za mu iya cika cikar gyara kowane manufofin da ke cikin jerin abubuwan da suka fi dacewa na tsoho-kube-scheduler ba, muna da buƙatar sassauƙan sarrafa tsare-tsaren tsare-tsare.

Tsara matsalar

Muna son warware matsalar ta zama takamaiman gwargwadon yiwuwar, wato, manyan abubuwan Kubernetes (a nan muna nufin mai tsara kube-scheduler) yakamata ya kasance ba canzawa. Ba mu so mu magance matsala a wuri ɗaya mu ƙirƙira ta a wani wuri. Don haka, mun zo ga zaɓuɓɓuka biyu don magance matsalar, waɗanda aka sanar a gabatarwar labarin - ƙirƙirar ƙarin mai tsarawa ko rubuta naku. Babban abin da ake buƙata don tsara ayyukan cron shine rarraba kaya a ko'ina cikin nodes uku. Ana iya biyan wannan buƙatu ta hanyar manufofin kube-scheduler na yanzu, don haka don magance matsalarmu babu ma'ana a rubuta naku jadawalin.

Umarnin don ƙirƙira da Aiwatar da ƙarin mai tsara kube-scheduler an bayyana su a ciki takardun. Duk da haka, ya zama kamar a gare mu cewa ƙungiyar ƙaddamarwa ba ta isa ba don tabbatar da rashin haƙuri a cikin aikin irin wannan muhimmin sabis kamar kube-scheduler, don haka mun yanke shawarar tura sabon kube-scheduler a matsayin Static Pod, wanda za a sa ido kai tsaye. da Kubelet. Don haka, muna da buƙatu masu zuwa don sabon kube-scheduler:

Dole ne a tura sabis ɗin azaman Static Pod akan duk mashawartan tari
Dole ne a ba da haƙurin kuskure idan ba a samu fasfo mai aiki tare da kube-scheduler ba
Babban fifiko lokacin tsarawa yakamata ya zama adadin albarkatun da ake samu akan kumburin (LeastRequestedPriority)

Aiwatar Magani

Ya kamata a lura nan da nan cewa za mu gudanar da duk ayyukan a Kubernetes v1.14.7, saboda Wannan shi ne sigar da aka yi amfani da ita a cikin aikin. Bari mu fara da rubuta takarda don sabon kube-scheduler. Bari mu ɗauki bayanan da aka saba (/etc/kubernetes/manifests/kube-scheduler.yaml) a matsayin tushe kuma mu kawo shi zuwa ga tsari mai zuwa:

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

A taƙaice game da manyan canje-canje:

Canza sunan kwafsa da kwantena zuwa kube-scheduler-cron
Ƙayyadaddun amfani da tashoshin jiragen ruwa 10151 da 10159 kamar yadda aka ayyana zaɓi hostNetwork: true kuma ba za mu iya amfani da tashar jiragen ruwa iri ɗaya kamar kube-scheduler tsoho (10251 da 10259)
Yin amfani da ma'aunin --config, mun ƙayyadadden fayil ɗin sanyi wanda yakamata a fara sabis ɗin da shi
Haɓakawa na fayil ɗin daidaitawa (scheduler-custom.conf) da fayil ɗin tsari (scheduler-custom-policy-config.json) daga mai watsa shiri

Kar a manta cewa kube-scheduler namu zai buƙaci haƙƙoƙin kama da wanda aka saba. Shirya rawar tari:

kubectl edit clusterrole system:kube-scheduler

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

Yanzu bari muyi magana game da abin da ya kamata a ƙunshe a cikin fayil ɗin daidaitawa da fayil ɗin tsarin tsarawa:

Fayil ɗin daidaitawa (scheduler-custom.conf)
Don samun tsayayyen tsarin kube-scheduler, dole ne ku yi amfani da siga --write-config-to daga takardun. Za mu sanya saitin da aka samu a cikin fayil /etc/kubernetes/scheduler-custom.conf kuma mu rage shi zuwa tsari mai zuwa:

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"

A taƙaice game da manyan canje-canje:

Mun saita suna mai tsarawa zuwa sunan sabis ɗin kube-scheduler-cron ɗin mu.
A cikin siga lockObjectName kuna buƙatar saita sunan sabis ɗin mu kuma tabbatar da cewa siga leaderElect saita zuwa gaskiya (idan kuna da kumburin master guda ɗaya, zaku iya saita shi zuwa ƙarya).
Ƙayyadaddun hanyar zuwa fayil ɗin tare da bayanin tsare-tsaren tsarawa a cikin siga algorithmSource.

Yana da kyau a yi la'akari da hankali ga batu na biyu, inda muke gyara ma'auni don maɓalli leaderElection. Don tabbatar da haƙurin kuskure, mun kunna (leaderElect) tsarin zabar shugaba (maigida) tsakanin kwas ɗin kube-scheduler ta hanyar amfani da maƙasudi guda ɗaya gare su (resourceLock) mai suna kube-scheduler-cron (lockObjectName) a cikin kube-system namespace (lockObjectNamespace). Yadda Kubernetes ke tabbatar da wadatar manyan abubuwan haɗin gwiwa (ciki har da kube-scheduler) ana iya samun su a ciki labarin.

Fayilolin tsarin tsarawa (scheduler-custom-policy-config.json)
Kamar yadda na rubuta a baya, za mu iya gano waɗanne takamaiman manufofin tsohowar kube-scheduler ke aiki da su kawai ta hanyar nazarin lambar sa. Wato, ba za mu iya samun fayil tare da tsare-tsaren tsarawa don tsohowar kube-scheduler ba kamar yadda fayil ɗin sanyi yake. Bari mu bayyana manufofin tsarawa da muke sha'awar a cikin /etc/kubernetes/scheduler-custom-policy-config.json fayil kamar haka:

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

Don haka, kube-scheduler ya fara tattara jerin nodes waɗanda za a iya tsara kwafsa bisa ga manufofin GeneralPredicates (wanda ya haɗa da saitin PodFitsResources, PodFitsHostPorts, HostName, da MatchNodeSelector manufofin). Sannan ana kimanta kowane kumburi daidai da tsarin manufofin da ke cikin jerin abubuwan da suka fi fifiko. Don cika sharuddan aikinmu, mun yi la'akari da cewa irin wannan tsarin manufofin zai zama mafi kyawun mafita. Bari in tunatar da ku cewa akwai tsarin tsare-tsare tare da cikakkun bayanansu a ciki takardun. Don cim ma aikin ku, zaku iya kawai canza tsarin manufofin da aka yi amfani da su kuma ku sanya ma'aunin nauyi masu dacewa.

Bari mu kira bayyanar sabon kube-scheduler, wanda muka ƙirƙira a farkon babin, kube-scheduler-custom.yaml kuma mu sanya shi a cikin hanyar da ke gaba /etc/kubernetes/bayyana kan manyan nodes guda uku. Idan an yi komai daidai, Kubelet zai ƙaddamar da kwasfa akan kowane kumburi, kuma a cikin rajistan ayyukan sabon kube-scheduler za mu ga bayanin cewa an yi nasarar amfani da fayil ɗin manufofin mu:

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

Yanzu abin da ya rage shi ne a nuna a cikin ƙayyadaddun na CronJob cewa duk buƙatun tsara shirye-shiryen sa ya kamata a sarrafa shi ta sabon mai tsara kube-scheduler:

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

ƙarshe

A ƙarshe, mun sami ƙarin kube-scheduler tare da tsari na musamman na tsare-tsaren tsare-tsare, wanda kubelet ke kula da aikin kai tsaye. Bugu da kari, mun kafa zaben sabon shugaba a tsakanin kube-kube-scheduler namu idan tsohon shugaban ya kasa samuwa saboda wasu dalilai.

Ana ci gaba da tsara aikace-aikace da ayyuka na yau da kullun ta hanyar tsohowar kube-scheduler, kuma duk ayyukan cron an canza su gaba ɗaya zuwa sabon. Load ɗin da ayyukan cron ya ƙirƙira yanzu ana rarraba su daidai a duk nodes. Idan akai la'akari da cewa yawancin ayyukan cron suna aiwatar da su a kan nodes guda ɗaya kamar manyan aikace-aikacen aikin, wannan ya rage yawan haɗarin motsin kwasfa saboda rashin wadata. Bayan gabatar da ƙarin kube-scheduler, matsaloli tare da tsararru marar daidaituwa na ayyukan cron sun daina tashi.

Hakanan karanta wasu labarai akan shafinmu:

source: www.habr.com

Ƙirƙirar ƙarin kube-scheduler tare da tsarin al'ada na ƙa'idodin tsarawa