Kube-график - бул Kubernetesтин ажырагыс компоненти, ал белгиленген саясаттарга ылайык түйүндөр боюнча подкасттарды пландаштырууга жооп берет. Көбүнчө, Kubernetes кластеринин иштеши учурунда, демейки кубе пландоочунун саясаттарынын жыйындысы күнүмдүк тапшырмалардын көбүнө ылайыктуу болгондуктан, подкасттарды пландаштыруу үчүн кайсы саясаттар колдонулары жөнүндө ойлонуунун кажети жок. Бирок, биз үчүн поддондорду бөлүштүрүү процессин тактоо маанилүү болгон жагдайлар бар жана бул тапшырманы аткаруунун эки жолу бар:
- Ыңгайлаштырылган эрежелер топтому менен кубе-график түзүңүз
- Өзүңүздүн пландаштыргычыңызды жазыңыз жана аны API сервер суроо-талабы менен иштөөгө үйрөтүңүз
Бул макалада, мен биздин долбоорлордун биринде очокторду бирдей эмес пландаштыруу маселесин чечүү үчүн биринчи пунктту ишке ашырууну сүрөттөп берем.
Кубе-график кантип иштээри жөнүндө кыскача маалымат
Өзгөчө белгилей кетүүчү нерсе, kube-график подкасттарды түздөн-түз пландаштыруу үчүн жооптуу эмес - ал поддонду жайгаштыра турган түйүндү аныктоо үчүн гана жооптуу. Башка сөз менен айтканда, kube-пландаштыруучунун ишинин натыйжасы түйүндүн аталышы болуп саналат, ал пландаштыруу өтүнүчү үчүн API серверине кайтып келет жана анын иши ушуну менен аяктайт.
Биринчиден, kube-шайлоочу придикаттар саясатына ылайык подкаст пландаштырылышы мүмкүн болгон түйүндөрдүн тизмесин түзөт. Андан кийин, бул тизмедеги ар бир түйүн приоритеттик саясатка ылайык белгилүү бир сандагы упайларды алат. Натыйжада, упайлардын максималдуу саны менен түйүн тандалат. Эгерде бирдей максималдуу баллга ээ түйүндөр бар болсо, кокусунан бири тандалат. Предикаттардын (фильтрлөө) жана приоритеттердин (баллдоо) саясаттарынын тизмеси жана сүрөттөлүшү төмөнкү жерден тапса болот. .
Проблемалык органдын сүрөттөлүшү
Nixys'те ар кандай Kubernetes кластерлеринин көптүгүнө карабастан, биз биринчи жолу подкасттарды пландаштыруу көйгөйүнө жакында эле туш болдук, анда биздин долбоорлордун бири көп сандагы мезгилдүү тапшырмаларды (~ 100 CronJob объектилери) аткарууну талап кылганда. Көйгөйдүн сүрөттөлүшүн мүмкүн болушунча жөнөкөйлөтүү үчүн, биз мисал катары бир микросервисти алабыз, анын ичинде cron тапшырмасы мүнөтүнө бир жолу ишке киргизилип, CPU бир аз жүктү жаратат. Cron тапшырмасын аткаруу үчүн, таптакыр окшош мүнөздөмөлөргө ээ үч түйүн бөлүнгөн (ар биринде 24 vCPU).
Ошол эле учурда, CronJob ишке ашырууга канча убакыт талап кылынарын так айтуу мүмкүн эмес, анткени киргизилген маалыматтардын көлөмү тынымсыз өзгөрүп турат. Орточо алганда, kube-графиктин нормалдуу иштеши учурунда, ар бир түйүн 3-4 жумуш инстанциясын иштетет, алар ар бир түйүндүн CPU-на жүктүн ~20-30% түзөт:
Көйгөйдүн өзү, кээде cron тапшырма подкчалары үч түйүндүн биринде пландаштырылбай калган. Башкача айтканда, кайсы бир убакта түйүндөрдүн бири үчүн бир да поддон пландаштырылган эмес, ал эми калган эки түйүндөрдө тапшырманын 6-8 көчүрмөсү иштеп, CPU жүгүнүн ~ 40-60% түздү:
Көйгөй такыр кокустук жыштык менен кайталанып, кээде коддун жаңы версиясы чыгарылган учурга байланыштуу болгон.
Кубе-график журналынын деңгээлин 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 жана XNUMX жаңыртууларына кошулат деген жооп алынды.
- Учурда kube-графиктердин кайсы конкреттүү топтому менен иштеп жатканын түшүнүүнүн оңой жолу жок. Ооба, в бул тизме тизмеленген, бирок ал ар бир приоритеттик саясатка кандай конкреттүү салмактар ыйгарылгандыгы жөнүндө маалыматты камтыбайт. Демейки кубе-графиктин салмагын көрө аласыз же саясаттарын өзгөртө аласыз .
Белгилей кетчү нерсе, бир жолу биз түйүн ImageLocalityPriority саясатына ылайык упайларды албаганын жазып алганбыз, ал тиркемени иштетүү үчүн керектүү сүрөтү бар түйүнгө упайларды берет. Башкача айтканда, тиркеменин жаңы версиясы чыгарылган учурда, cron тапшырмасы эки түйүндө иштөөгө жетишти, аларга докер реестринен жаңы сүрөттү жүктөп алып, эки түйүн үчүнчүгө салыштырмалуу жогорку жыйынтыкка ээ болду. .
Мен жогоруда жазгандай, журналдарда биз ImageLocalityPriority саясатын баалоо жөнүндө маалыматты көрбөйбүз, андыктан биздин божомолубузду текшерүү үчүн биз колдонмонун жаңы версиясы менен сүрөттү үчүнчү түйүнгө таштадык, андан кийин график туура иштеген. . Так ImageLocalityPriority саясатынан улам пландаштыруу маселеси өтө сейрек байкалган; көбүнчө ал башка нерсе менен байланышкан. Демейки кубе пландаштыргычтын артыкчылыктарынын тизмесиндеги саясаттардын ар бирин толук оңдой албагандыктан, биз подкасттарды пландаштыруу саясаттарын ийкемдүү башкарууга муктаж болдук.
Тапшырманын коюлушу
Биз маселенин чечилиши мүмкүн болушунча конкреттүү болушун кааладык, башкача айтканда, Kubernetesтин негизги объекттери (бул жерде биз демейки кубе-графикти айтып жатабыз) өзгөрүүсүз калышы керек. Биз бир жерде маселени чечип, башка жерде жараталы деген жокпуз. Ошентип, биз маселени чечүүнүн эки вариантына келдик, алар макаланын кириш сөзүндө айтылган - кошумча пландоочу түзүү же өзүңүздүн жазуу. Cron тапшырмаларын пландаштыруунун негизги талабы - жүктү үч түйүн боюнча бирдей бөлүштүрүү. Бул талапты кубе-графиктердин учурдагы саясаттары канааттандырышы мүмкүн, андыктан биздин көйгөйдү чечүү үчүн өзүңүздүн пландоочуңузду жазуудан эч кандай пайда жок.
Кошумча куб графигин түзүү жана жайылтуу боюнча нускамалар сүрөттөлгөн . Бирок, бизге Жайгаштыруу объекти кубе-график сыяктуу маанилүү кызматтын иштешинде каталарга чыдамдуулукту камсыз кылуу үчүн жетишсиз болуп көрүндү, ошондуктан биз жаңы кубе-графикти Static Pod катары жайгаштырууну чечтик, ал түздөн-түз көзөмөлдөнөт. Kubelet тарабынан. Ошентип, бизде жаңы кубе-график үчүн төмөнкү талаптар бар:
- Кызмат бардык кластер мастерлеринде Статикалык Pod катары жайгаштырылышы керек
- Kube-график менен жигердүү подряд жеткиликсиз болгон учурда катага чыдамдуулук камсыз кылынышы керек
- Пландоодо негизги приоритет түйүндөгү жеткиликтүү ресурстардын саны болушу керек (LeastRequestedPriority)
Ишке ашыруу чечимдери
Биз Kubernetes v1.14.7 бардык иштерди аткара турганыбызды дароо белгилей кетүү керек, анткени Бул долбоордо колдонулган версия. Жаңы кубе-график үчүн манифест жазуудан баштайлы. Келгиле, демейки манифестти (/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Негизги өзгөрүүлөр жөнүндө кыскача:
- Под жана контейнердин атын kube-scheduler-cron деп өзгөрттү
- Опция аныкталгандай 10151 жана 10159 портторун колдонуу көрсөтүлгөн
hostNetwork: trueжана биз демейки kube-график (10251 жана 10259) сыяктуу портторду колдоно албайбыз. - --config параметрин колдонуу менен биз кызматты баштоо керек болгон конфигурация файлын аныктадык
- Конфигурацияланган конфигурациялоо файлы (scheduler-custom.conf) жана пландаштыруу саясаты файлы (scheduler-custom-policy-config.json) хосттон
Биздин кубе пландоочубузга демейкиге окшош укуктар керек болорун унутпаңыз. Анын кластердик ролун түзөтүңүз:
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"Негизги өзгөрүүлөр жөнүндө кыскача:
- Биздин kube-график-cron кызматыбыздын атына schedulerName койдук.
- Параметрде
lockObjectNameСиз ошондой эле биздин кызматтын атын коюп, параметр бар экенине ынануу керекleaderElectчындыкка коюңуз (эгерде сизде бир башкы түйүн болсо, аны "false" деп коё аласыз). - Параметрде пландаштыруу саясаттарынын сүрөттөлүшү менен файлга жол көрсөтүлгөн
algorithmSource.
Биз ачкычтын параметрлерин түзөтө турган экинчи пунктту кылдаттык менен карап чыгуу керек leaderElection. Күнөөлөргө чыдамдуулукту камсыз кылуу үчүн, биз иштеттик (leaderElect) биздин кубе пландоочубуздун поддондорунун ортосунда лидерди (мастер) тандоо процесси, алар үчүн бир акыркы чекит аркылуу (resourceLock) kube-scheduler-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-шайлоочу адегенде 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-график аркылуу пландаштырыла берет жана бардык cron тапшырмалары толугу менен жаңысына өткөрүлүп берилди. Cron тапшырмалары менен түзүлгөн жүк эми бардык түйүндөр боюнча бирдей бөлүштүрүлөт. Крон тапшырмаларынын көбү долбоордун негизги тиркемелери менен бир эле түйүндөрдө аткарыларын эске алсак, бул ресурстардын жетишсиздигинен улам көчүрүү коркунучун бир кыйла азайтты. Кошумча кубе-график киргизгенден кийин, крон тапшырмаларын бир калыпта эмес пландаштыруу проблемалары мындан ары пайда болгон жок.
Биздин блогдогу башка макалаларды да окуңуз:
Source: www.habr.com