Kube-жоспарлағышы Kubernetes бағдарламасының ажырамас құрамдас бөлігі болып табылады, ол көрсетілген саясаттарға сәйкес түйіндер бойынша түйіндерді жоспарлауға жауап береді. Көбінесе, Kubernetes кластерінің жұмысы кезінде подкасттарды жоспарлау үшін нақты қандай саясаттар қолданылатыны туралы ойлаудың қажеті жоқ, өйткені әдепкі kube-жоспарлағыштың саясаттар жинағы күнделікті тапсырмалардың көпшілігі үшін қолайлы. Дегенмен, біз үшін бөтелкелердің таралуын дәл баптау маңызды болатын жағдайлар бар және бұл тапсырманы орындаудың екі жолы бар:
- Теңшелетін ережелер жинағы бар kube жоспарлаушысын жасаңыз
- Өзіңіздің жоспарлаушыңызды жазыңыз және оны API сервер сұрауларымен жұмыс істеуге үйретіңіз
Бұл мақалада мен біздің жобаларымыздың бірінде бұршақтарды біркелкі жоспарлау мәселесін шешу үшін дәл бірінші тармақтың орындалуын сипаттаймын.
kube-scheduler'a жұмысы туралы қысқаша кіріспе
Айта кету керек, kube-жоспарлаушы подкасттарды тікелей жоспарлауға жауап бермейді - ол тек подкаст орналастыруға болатын түйінді анықтауға жауапты. Басқаша айтқанда, kube-жоспарлаушы жұмысының нәтижесі жоспарлау сұрауы үшін API серверіне қайтаратын түйіннің атауы болып табылады және оның жұмысы осы жерде аяқталады.
Біріншіден, kube-жоспарлаушы Pod предикаттар саясаттарына сәйкес жоспарлауға болатын түйіндерді тізімдейді. Әрі қарай, осы тізімдегі әрбір түйін басымдықтар саясатына сәйкес белгілі бір ұпай санын алады. Нәтижесінде ең жоғары ұпай жинаған түйін таңдалады. Ең жоғары ұпайы бірдей түйіндер болса, кездейсоқ біреуі таңдалады. Предикаттар (сүзу) және басымдықтар (баллдау) саясаттарының тізімі мен сипаттамасын мына жерден табуға болады. .
Проблемалық дененің сипаттамасы
Nixys-те әртүрлі Kubernetes кластерлерінің көптігіне қарамастан, біз бірінші рет подкасттарды жоспарлау мәселесіне жақында ғана тап болдық, бұл кезде жобаларымыздың бірі үшін көптеген мерзімді тапсырмаларды орындау қажет болды (~ 100 CronJob нысаны). Мәселенің сипаттамасын мүмкіндігінше жеңілдету үшін мысал ретінде бір микросервисті алайық, оның ішінде cron тапсырмасы минутына бір рет іске қосылып, процессорға біршама жүктеме жасайды. Cron тапсырмасының жұмысы үшін үш мүлдем бірдей түйін (әрқайсысында 24 vCPU) бөлінді.
Бұл ретте CronJob қанша уақыт жұмыс істейтінін нақты айту мүмкін емес, өйткені кіріс деректерінің көлемі үнемі өзгеріп отырады. Орташа алғанда, қалыпты kube-жоспарлағыш жұмысы кезінде әрбір түйін әрбір түйіннің орталық процессорындағы жүктеменің ~ 3-4% құрайтын 20-30 тапсырма данасын іске қосады:
Мәселе мынада, кейде cron тапсырмаларының түйіндері үш түйіннің біріне жоспарлануды тоқтатады. Яғни, белгілі бір уақытта түйіндердің біреуі үшін бірде-бір блок жоспарланбаған, ал қалған екі түйінде 6-8 тапсырма данасы жұмыс істеп, CPU жүктемесінің ~ 40-60% құрайды:
Мәселе мүлдем кездейсоқ жиілікпен қайталанды және кейде кодтың жаңа нұсқасын шығару сәтімен байланысты болды.
Kube-жоспарлаушының тіркеу деңгейін 10-деңгейге (-v=10) көтеру арқылы біз бағалау процесінде әрбір түйін қанша ұпай жинайтынын жаза бастадық. Қалыпты жоспарлау кезінде журналдарда келесі ақпаратты көруге болады:
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Анау. журналдардан алынған ақпарат бойынша түйіндердің әрқайсысы бірдей қорытынды ұпай жинады және жоспарлау үшін кездейсоқ біреуі таңдалды. Мәселені жоспарлау кезінде журналдар келесідей болды:
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Бұдан түйіндердің біреуі басқаларына қарағанда жалпы ұпайларды аз жинағанын көруге болады, сондықтан жоспарлау максималды ұпай жинаған екі түйін үшін ғана орындалды. Осылайша, біз мәселенің дәл бүршіктерді жоспарлауда жатқанына сенімді болдық.
Мәселені шешудің одан әрі алгоритмі бізге түсінікті болды - журналдарды талдау, түйіннің қай басымдылық бойынша ұпай алмағанын түсіну және қажет болған жағдайда әдепкі kube-жоспарлағышының саясатын реттеу. Дегенмен, бұл жерде біз екі маңызды қиындыққа тап боламыз:
- Ең жоғары тіркеу деңгейі (10) тек кейбір басымдықтар үшін нүктелер жинағын көрсетеді. Жоғарыдағы журнал үзіндісінде журналдарда көрсетілген барлық басымдықтар үшін түйіндер қалыпты және проблемалық жоспарлауда бірдей ұпай санын жинайтынын көре аласыз, бірақ мәселені жоспарлау жағдайында соңғы нәтиже әртүрлі болады. Осылайша, кейбір басымдықтар үшін балл қою «сахна артында» орын алады деп қорытынды жасауға болады және бізде түйіннің қай басымдылық үшін ұпай алмағанын түсінуге мүмкіндік жоқ. Біз бұл мәселені егжей-тегжейлі сипаттадық Github жүйесіндегі Kubernetes репозиторийі. Жазу кезінде әзірлеушілерден Kubernetes v1.15,1.16 және 1.17 жаңартуларында журналды тіркеу қолдауы қосылатыны туралы жауап алынды.
- Қазіргі уақытта kube-жоспарлағыштың қандай саясаттар жиынтығымен жұмыс істеп жатқанын түсінудің оңай жолы жоқ. Иә, в бұл тізім тізімделген, бірақ ол басымдық саясаттарының әрқайсысы үшін қандай нақты салмақтар орнатылғаны туралы ақпаратты қамтымайды. Сіз тек салмақтарды көре аласыз немесе әдепкі kube жоспарлаушының саясаттарын өңдей аласыз .
Айта кету керек, бір рет біз түйіннің ImageLocalityPriority саясатына сәйкес ұпай жинамағанын түзете алдық, ол қолданбаны іске қосу үшін қажетті кескінге ие болса, түйінге ұпай береді. Яғни, қосымшаның жаңа нұсқасын шығару кезінде cron тапсырмасы екі түйінде жұмыс істеп, оларға докер тізілімінен жаңа кескінді жүктеп алуға үлгерді, осылайша екі түйінге қатысты жоғары қорытынды балл алды. үшінші.
Жоғарыда жазғанымдай, журналдарда біз ImageLocalityPriority саясатын бағалау туралы ақпаратты көрмейміз, сондықтан біздің болжамымызды тексеру үшін қолданбаның жаңа нұсқасымен суретті үшінші түйінге орналастырдық, содан кейін жоспарлау. дұрыс жұмыс істеді. Дәл ImageLocalityPriority саясатының арқасында жоспарлау мәселесі өте сирек байқалды, көбінесе ол басқа нәрсемен байланысты болды. Әдепкі kube-жоспарлаушысының басымдықтар тізіміндегі саясаттардың әрқайсысын толық күйіне келтіре алмағандықтан, бізге подкастты жоспарлау саясаттарын икемді басқару қажеттілігі туындады.
Мәселенің тұжырымы
Біз мәселені шешу мүмкіндігінше мақсатты болғанын қаладық, яғни Kubernetes-тің негізгі нысандары (бұл жерде біз әдепкі kube-жоспарлағышты айтамыз) өзгеріссіз қалуы керек. Біз бір жерде мәселені шешіп, оны басқа жерде жасағымыз келмеді. Осылайша, біз мақаланың кіріспесінде жарияланған мәселені шешудің екі нұсқасына келдік - қосымша жоспарлаушыны жасау немесе өз бетінше жазу. Cron тапсырмаларын жоспарлаудың негізгі талабы үш түйін бойынша жүктемені біркелкі бөлу болып табылады. Бұл талапты бар kube-жоспарлаушы саясаттары қанағаттандыруы мүмкін, сондықтан тапсырмамыз үшін өз жоспарлаушымызды жазудың мағынасы жоқ.
Қосымша kube-жоспарлағышты жасау және орналастыру нұсқаулары мына бөлімде сипатталған . Дегенмен, бізге «Орналастыру» нысаны kube-жоспарлаушы сияқты маңызды қызметтің жұмысында ақауларға төзімділікті қамтамасыз ету үшін жеткіліксіз болып көрінді, сондықтан біз Kubelet тікелей бақылайтын жаңа kube-жоспарлағышты Static Pod ретінде орналастыруды шештік. . Осылайша, бізде жаңа kube жоспарлаушыға келесі талаптар қойылады:
- Қызмет барлық кластер шеберлерінде Статикалық Pod ретінде орналастырылуы керек
- Kube-жоспарлағышы бар белсенді қосқыш қолжетімсіз болған жағдайда, істен шығу қамтамасыз етілуі керек
- Жоспарлау кезінде негізгі басымдық түйіндегі қолжетімді ресурстардың көлемі болуы керек (LeastRequestedPriority)
Іске асыру шешімдері
Бірден айта кету керек, біз Kubernetes v1.14.7 нұсқасындағы барлық жұмыстарды орындаймыз, өйткені бұл нұсқа жобада қолданылды. Жаңа kube-жоспарлағышымыз үшін манифест жазудан бастайық. Әдепкі манифестті (/etc/kubernetes/manifests/kube-scheduler.yaml) негізге алып, оны келесі пішінге келтірейік:
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Негізгі өзгерістер туралы қысқаша:
- Pod және контейнер атауы kube-scheduler-cron болып өзгертілді
- Опция анықталғандықтан 10151 және 10159 порттарын пайдалану үшін көрсетілген
hostNetwork: trueжәне біз әдепкі kube жоспарлаушысы сияқты порттарды пайдалана алмаймыз (10251 және 10259) - --config параметрін пайдаланып, қызмет басталатын конфигурация файлын көрсетіңіз
- Конфигурация файлын (scheduler-custom.conf) және жоспарлау саясаты файлын (scheduler-custom-policy-config.json) хосттан орнату үшін конфигурацияланған
Біздің kube-жоспарлағышымызға әдепкіге ұқсас құқықтар қажет болатынын ұмытпаңыз. Оның кластер рөлін өңдеңіз:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Енді конфигурация файлында және жоспарлау саясаты файлында не болуы керектігі туралы сөйлесейік:
- Конфигурация файлы (scheduler-custom.conf)
Әдепкі kube жоспарлаушысының конфигурациясын алу үшін параметрді пайдалану керек--write-config-to-дан . Алынған конфигурацияны /etc/kubernetes/scheduler-custom.conf файлына орналастырып, келесі пішінге келтіреміз:
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"Негізгі өзгерістер туралы қысқаша:
- PlanerName параметрін kube-scheduler-cron қызметіміздің атауына орнатыңыз.
- Параметрде
lockObjectNameбіз сондай-ақ қызметіміздің атын орнатуымыз керек және параметрдің екеніне көз жеткізуіміз керекleaderElectшын мәніне орнатыңыз (егер сізде бір негізгі түйін болса, мәнді жалған етіп орнатуға болады). - Параметрде жоспарлау саясаттарының сипаттамасы бар файлға жол көрсетілген
algorithmSource.
Екінші абзацқа толығырақ тоқталған жөн, онда біз кілттің параметрлерін өңдейміз. leaderElection. Ақауларға төзімділік үшін біз (leaderElect) біздің kube-жоспарлағыштың қосқыштары арасында олар үшін бір соңғы нүктені пайдалану арқылы көшбасшыны (шеберді) таңдау процесі (resourceLock) kube-жоспарлаушы-cron (lockObjectName) kube жүйесінің аттар кеңістігінде (lockObjectNamespace). Kubernetes негізгі компоненттердің (соның ішінде kube-жоспарлағыштың) жоғары қолжетімділігін қалай қамтамасыз ететінін мына жерден табуға болады .
- Жоспарлау саясаты файлы (scheduler-custom-policy-config.json)
Бұрын жазғанымдай, біз тек оның кодын талдау арқылы әдепкі kube жоспарлаушысы қандай нақты саясаттармен жұмыс істейтінін біле аламыз. Яғни, конфигурация файлына ұқсастық бойынша әдепкі kube-жоспарлаушының жоспарлау саясаты бар файлды ала алмаймыз. /etc/kubernetes/scheduler-custom-policy-config.json файлында бізді қызықтыратын жоспарлау саясаттарын төмендегідей сипаттап көрейік:
{
"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
}Сондықтан kube-жоспарлаушы алдымен Pod GeneralPredicates саясатына (PodFitsResources, PodFitsHostPorts, HostName және MatchNodeSelector саясат жиынын қамтиды) сәйкес жоспарлауға болатын түйіндерді тізімдейді. Содан кейін әрбір түйін басымдықтар массивіндегі саясаттар жинағына сәйкес бағаланады. Міндетіміздің шарттарын орындау үшін біз мұндай саясат кешенін ең жақсы шешім деп санадық. Егжей-тегжейлі сипаттамасы бар саясаттар жиынтығы бар екенін еске саламын . Тапсырмаңызды орындау үшін сіз жай ғана пайдаланылған саясаттар жинағын өзгерте аласыз және оларға сәйкес салмақтарды тағайындай аласыз.
Біз тараудың басында жасаған жаңа kube-жоспарлаушы манифест kube-scheduler-custom.yaml деп аталады және үш негізгі түйінде /etc/kubernetes/manifests ішіне орналастырылады. Егер бәрі дұрыс орындалса, Kubelet әрбір түйінде қосқышты іске қосады және жаңа kube-жоспарлағышымыздың журналдарында саясат файлымыз сәтті қолданылғаны туралы ақпаратты көреміз:
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:{}]'Енді біздің CronJob спецификациясында оның подкасттарын жоспарлауға арналған барлық сұрауларды біздің жаңа kube-жоспарлағышымыз өңдеуі керек екенін көрсету ғана қалды:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...қорытынды
Соңында біз кубелет арқылы тікелей бақыланатын жоспарлау саясаттарының бірегей жиынтығы бар қосымша kube-жоспарлағыш алдық. Бұған қоса, ескі жетекші қандай да бір себептермен қолжетімсіз болып қалса, кубе-жоспарлағыштың қосқыштары арасында жаңа көшбасшыны сайлауды орнаттық.
Қалыпты қолданбалар мен қызметтер әдепкі kube-жоспарлағыш арқылы жоспарлануда және барлық cron тапсырмалары толығымен жаңасына ауыстырылды. Cron тапсырмаларымен жасалған жүктеме енді барлық түйіндерге біркелкі бөлінеді. Cron тапсырмаларының көпшілігі жобаның негізгі қолданбалары сияқты бір түйіндерде орындалатынын ескере отырып, бұл ресурстардың жетіспеушілігіне байланысты бөтелкелердің қозғалу қаупін айтарлықтай төмендетті. Қосымша kube-жоспарлағышты енгізгеннен кейін, cron тапсырмаларын біркелкі емес жоспарлауда қиындықтар болмады.
Сондай-ақ біздің блогтағы басқа мақалаларды оқыңыз:
Ақпарат көзі: www.habr.com