کیوب-شیډیولر د Kubernetes یوه لازمي برخه ده، کوم چې د مشخصو پالیسیو سره سم د نوډونو په اوږدو کې د پوډونو مهال ویش مسولیت لري. ډیری وختونه ، د کوبرنیټس کلسټر عملیاتو په جریان کې ، موږ اړتیا نلرو چې د پوډونو مهالویش لپاره کومې پالیسۍ کارول کیږي ، ځکه چې د ډیفالټ کیوب - مهالویش پالیسي د ډیری ورځني کارونو لپاره مناسبه ده. په هرصورت، داسې شرایط شتون لري کله چې دا زموږ لپاره مهم دي چې د پوډونو تخصیص کولو پروسه ښه تنظیم کړو، او د دې دندې سرته رسولو لپاره دوه لارې شتون لري:
- د دودیز مقرراتو سره د کیوب شیډولر جوړ کړئ
- خپل مهالویش ولیکئ او د API سرور غوښتنو سره کار کولو لپاره یې زده کړئ
په دې مقاله کې، زه به د لومړي ټکي پلي کول تشریح کړم چې زموږ په یوه پروژه کې د هارتونو د غیر مساوي مهال ویش ستونزه حل کړي.
د کیوب شیډولر څنګه کار کوي یو لنډ پیژندنه
دا په ځانګړي توګه د دې حقیقت په پام کې نیولو سره ارزښت لري چې کیوب شیډولر د پوډونو مستقیم مهالویش لپاره مسؤل ندي - دا یوازې د نوډ ټاکلو لپاره مسؤل دی چې په کوم کې پوډ ځای په ځای شي. په بل عبارت، د کیوب - مهالویش کار پایله د نوډ نوم دی، کوم چې دا د مهال ویش غوښتنې لپاره د API سرور ته راستنیږي، او دا هغه ځای دی چې کار یې پای ته رسیږي.
لومړی، کیوب-شیډولر د نوډونو لیست ترتیبوي چې په هغې کې پوډ د وړاندوینې پالیسیو سره سم ټاکل کیدی شي. بیا، د دې لیست څخه هر نوډ د لومړیتوبونو پالیسیو سره سم یو مشخص شمیر ټکي ترلاسه کوي. د پایلې په توګه، نوډ د ډیری پوائنټونو سره غوره شوی. که چیرې داسې نوډونه شتون ولري چې ورته اعظمي نمرې ولري ، یو تصادفي غوره شوی. د وړاندوینې (فلټر کولو) او لومړیتوبونو (سکور کولو) پالیسیو لیست او توضیحات په کې موندل کیدی شي .
د بدن د ستونزې تشریح
سره له دې چې په Nixys کې د لوی شمیر مختلف Kubernetes کلسترونو ساتل کیږي، موږ لومړی په دې وروستیو کې د پوډونو د مهالویش کولو ستونزې سره مخ شو، کله چې زموږ یوه پروژه د ډیری وختي کارونو (~ 100 CronJob ادارې) پرمخ وړلو ته اړتیا درلوده. د امکان تر حده د ستونزې تشریح ساده کولو لپاره ، موږ به د مثال په توګه یو مایکرو سرویس واخلو ، په کوم کې چې د کرون دنده په دقیقه کې یو ځل پیل کیږي ، په CPU کې یو څه بار رامینځته کوي. د کرون دندې د چلولو لپاره، درې نوډونه چې په بشپړ ډول ورته ځانګړتیاوو سره تخصیص شوي وو (په هر یو کې 24 vCPUs).
په ورته وخت کې، دا ناشونې ده چې په دقت سره ووایو چې کرون جاب به څومره وخت ونیسي چې پلي شي، ځکه چې د ان پټ ډیټا حجم په دوامداره توګه بدلیږي. په اوسط ډول، د کیوب شیډولر د نورمال عملیاتو په جریان کې، هر نوډ د 3-4 دندې مثالونه پرمخ وړي، کوم چې د هر نوډ CPU باندې ~ 20-30٪ بار جوړوي:
ستونزه پخپله دا ده چې ځینې وختونه د کرون ټاسک پوډونه له دریو نوډونو څخه په یوه کې مهالویش ودرول. دا، په ځینو وختونو کې، د یو نوډونو لپاره یو پوډ پلان شوی نه و، پداسې حال کې چې په نورو دوو نوډونو کې د دندې 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له کوم څخه دا لیدل کیدی شي چې یو نوډ د نورو په پرتله لږ وروستي ټکي ترلاسه کړي، او له همدې امله پالن جوړونه یوازې د دوو نوډونو لپاره ترسره شوي چې اعظمي نمرې یې ترلاسه کړې. په دې توګه، موږ په یقیني توګه ډاډه یو چې ستونزه د پوډونو په مهالویش کې دقیقه ده.
د ستونزې د حل لپاره نور الګوریتم موږ ته څرګند و - لاګونه تحلیل کړئ ، پوه شئ چې نوډ په کوم لومړیتوب کې پوائنټونه ندي ترلاسه کړي او که اړتیا وي ، د ډیفالټ کیوب - مهالویش پالیسي تنظیم کړئ. په هرصورت، دلته موږ د دوو مهمو ستونزو سره مخ یو:
- د ننوتلو په اعظمي کچه (10) کې، یوازې د ځینو لومړیتوبونو لپاره ترلاسه شوي ټکي منعکس کیږي. د لوګو په پورتنۍ اقتباس کې، تاسو لیدلی شئ چې د ټولو لومړیتوبونو لپاره چې په لاګونو کې منعکس شوي، نوډونه په نورمال او د ستونزو مهالویش کې د ورته شمیر پوائنټونو نمرې ورکوي، مګر د ستونزې پالن کولو په صورت کې وروستۍ پایله توپیر لري. په دې توګه، موږ کولی شو دې پایلې ته ورسیږو چې د ځینو لومړیتوبونو لپاره، نمرې "د پردې شاته" واقع کیږي، او موږ د دې پوهیدو لپاره هیڅ لاره نلرو چې د کوم لومړیتوب لپاره نوډ پوائنټونه نه دي ترلاسه کړي. موږ دا ستونزه په تفصیل سره بیان کړه په ګیتوب کې د کوبرنیټس ذخیره. د لیکلو په وخت کې، د پراختیا کونکو څخه ځواب ترلاسه شو چې د ننوتلو ملاتړ به د Kubernetes v1.15,1.16، 1.17 او XNUMX تازه معلوماتو کې اضافه شي.
- د دې پوهیدلو لپاره کومه اسانه لار نشته چې د کوم ځانګړي پالیسي سیټ کیوب - شیډولر اوس مهال ورسره کار کوي. هو، په دا لیست لیست شوی، مګر دا پدې اړه معلومات نلري چې د لومړیتوبونو هرې پالیسۍ ته کوم ځانګړي وزنونه ټاکل شوي. تاسو کولی شئ وزن وګورئ یا یوازې د ډیفالټ کیوب - مهالویش پالیسي ایډیټ کړئ .
دا د یادونې وړ ده چې یوځل موږ وکولی شو ثبت کړو چې یو نوډ د ImageLocalityPriority پالیسي سره سم پوائنټونه ندي ترلاسه کړي، کوم چې نوډ ته اشاره کوي که چیرې دا دمخه د غوښتنلیک چلولو لپاره اړین عکس ولري. دا ، په هغه وخت کې چې د غوښتنلیک نوې نسخه راپورته شوه ، د کرون دنده په دوه نوډونو کې پرمخ وړل کېده ، دوی ته د ډاکر راجسټری څخه نوی عکس ډاونلوډ کول ، او پدې توګه دوه نوډونو د دریم په پرتله لوړه وروستۍ نمرې ترلاسه کړې. .
لکه څنګه چې ما پورته لیکلي، په لاګونو کې موږ د ImageLocalityPriority پالیسي ارزونې په اړه معلومات نه ګورو، نو د دې لپاره چې زموږ انګیرنه وګورئ، موږ عکس د غوښتنلیک نوې نسخه په دریم نوډ کې ډوب کړ، وروسته له دې چې مهال ویش په سمه توګه کار کاوه. . دا دقیقا د ImageLocalityPriority پالیسي له امله وه چې د مهالویش ستونزه په ندرت سره لیدل شوې؛ ډیری وختونه دا د بل څه سره تړاو لري. د دې حقیقت له امله چې موږ نشو کولی د ډیفالټ کیوب - شیډولر لومړیتوبونو لیست کې هره پالیسي په بشپړ ډول ډیبګ کړو ، موږ د پوډ مهالویش پالیسي انعطاف وړ مدیریت ته اړتیا درلوده.
د ستونزې تشکیل
موږ غوښتل چې د ستونزې حل د امکان تر حده مشخص وي، دا دی، د Kubernetes اصلي بنسټونه (دلته موږ د ډیفالټ کیوب - مهالویش معنی لرو) باید بدله پاتې وي. موږ نه غوښتل چې ستونزه په یو ځای کې حل کړو او په بل ځای کې یې رامنځته کړو. په دې توګه، موږ د ستونزې حل کولو لپاره دوه اختیارونو ته ورسیدو، کوم چې د مقالې په سریزه کې اعلان شوي - یو اضافي مهالویش جوړ کړئ یا خپل ځان ولیکئ. د کرون دندو د مهالویش لپاره اصلي اړتیا په دریو نوډونو کې په مساوي ډول توزیع کول دي. دا اړتیا د موجوده کیوب - مهالویش پالیسي لخوا پوره کیدی شي ، نو زموږ د ستونزې حل کولو لپاره ستاسو د خپل مهالویش لیکلو هیڅ معنی نلري.
د اضافي کیوب شیډولر رامینځته کولو او ځای په ځای کولو لارښوونې په کې تشریح شوي . په هرصورت، موږ ته داسې بریښي چې د ځای پرځای کولو اداره کافي نه وه چې د کیوب - شیډولر په څیر د داسې مهم خدمت په عملیاتو کې د خطا زغم ډاډمن کړي ، نو موږ پریکړه وکړه چې یو نوی کیوب شیډولر د سټیټیک پوډ په توګه ځای په ځای کړو ، کوم چې به مستقیم نظارت کیږي. د کوبیلیټ لخوا. په دې توګه، موږ د نوي کیوب-شیډولر لپاره لاندې اړتیاوې لرو:
- خدمت باید په ټولو کلستر ماسټرانو کې د جامد پوډ په توګه ځای په ځای شي
- د غلطۍ زغم باید چمتو شي که چیرې فعال پوډ د کیوب شیډولر سره شتون ونلري
- اصلي لومړیتوب کله چې پلان کول باید په نوډ کې د موجودو سرچینو شمیر وي (لږترلږه غوښتنه شوي لومړیتوب)
د تطبیق حل لارې
دا سمدلاسه د یادولو وړ ده چې موږ به ټول کارونه په 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او موږ نشو کولی د ډیفالټ کیوب شیډولر (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)
د ډیفالټ کیوب - مهالویش ترتیب ترلاسه کولو لپاره ، تاسو باید پیرامیټر وکاروئ--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"په لنډه توګه د اصلي بدلونونو په اړه:
- موږ د شیډولر نوم زموږ د کیوب-شیډولر-کرون خدمت نوم ته ټاکلی.
- په پیرامیټر کې
lockObjectNameتاسو اړتیا لرئ زموږ د خدمت نوم هم تنظیم کړئ او ډاډ ترلاسه کړئ چې پیرامیټرleaderElectریښتیا ته وټاکئ (که تاسو یو ماسټر نوډ ولرئ، تاسو کولی شئ دا غلط ته وټاکئ). - په پیرامیټر کې د مهالویش پالیسي توضیحاتو سره فایل ته لاره مشخصه کړه
algorithmSource.
دا د دوهم ټکي ته نږدې لید لید ارزښت لري ، چیرې چې موږ د کیلي لپاره پیرامیټونه ترمیم کوو leaderElection. د خطا زغم ډاډمن کولو لپاره، موږ فعال کړی دی (leaderElect) زموږ د کیوب - مهالویش کونکي پوډونو ترمینځ د مشر (ماسټر) غوره کولو پروسه د دوی لپاره د یو واحد پای ټکی په کارولو سره (resourceLock) نومول شوی kube-scheduler-cron (lockObjectNameد کیوب سیسټم نوم ځای کې (lockObjectNamespace). څنګه Kubernetes د اصلي برخو لوړ شتون یقیني کوي (د کیوب - مهالویش په شمول) موندل کیدی شي .
- د مهالویش پالیسي فایل (scheduler-custom-policy-config.json)
لکه څنګه چې ما مخکې لیکلي، موږ کولی شو معلومه کړو چې کوم ځانګړي پالیسۍ د ډیفالټ کیوب - مهالویش سره کار کوي یوازې د دې کوډ تحلیل کولو سره. دا دی، موږ نشو کولی د ډیفالټ کیوب - مهالویش لپاره د مهالویش پالیسیو سره فایل ترلاسه کړو په ورته ډول د ترتیب کولو فایل په څیر. راځئ چې د مهالویش پالیسي تشریح کړو چې موږ یې په لاندې ډول /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
}په دې توګه، کیوب-شیډولر لومړی د نوډونو لیست تالیف کوي چیرې چې پوډ د عمومي پریډیکټ پالیسۍ سره سم ټاکل کیدی شي (پدې کې د PodFitsResources، PodFitsHostPorts، HostName، او MatchNodeSelector پالیسیو سیټ شامل دي). او بیا هر نوډ د لومړیتوبونو په صف کې د پالیسیو د ترتیب سره سم ارزول کیږي. زموږ د دندې د شرایطو پوره کولو لپاره، موږ فکر کاوه چې دا ډول پالیسۍ به غوره حل وي. اجازه راکړئ تاسو ته یادونه وکړم چې د دوی د تفصيلي توضیحاتو سره د پالیسیو یوه مجموعه شتون لري . د خپلې دندې د سرته رسولو لپاره، تاسو کولی شئ په ساده ډول د کارول شویو پالیسیو سیټ بدل کړئ او دوی ته مناسب وزنونه وټاکئ.
راځئ چې د نوي کیوب-شیډولر مینی فیسټ ته زنګ ووهو، کوم چې موږ د څپرکي په پیل کې جوړ کړی، kube-scheduler-custom.yaml او په لاندې لار کې یې ځای په ځای کړئ /etc/kubernetes/manifests په دریو ماسټر نوډونو کې. که هرڅه په سمه توګه ترسره شوي وي، کوبیلټ به په هر نوډ کې یو پوډ پیل کړي، او زموږ د نوي کیوب-شیډولر په لاګونو کې به موږ هغه معلومات وګورو چې زموږ د پالیسۍ فایل په بریالیتوب سره پلي شوی و:
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:{}]'اوس ټول هغه څه چې پاتې دي هغه زموږ د کرون جاب په ځانګړتیا کې په ګوته کول دي چې د دې پوډونو مهالویش کولو ټولې غوښتنې باید زموږ د نوي کیوب - مهالویش کونکي لخوا پروسس شي:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...پایلې
په نهایت کې ، موږ د مهالویش کولو پالیسیو ځانګړي سیټ سره یو اضافي کیوب شیډولر ترلاسه کړ ، چې کار یې مستقیم د کیوبیل لخوا څارل کیږي. سربیره پردې ، موږ د خپل کیوب - مهالویش کونکي پوډونو ترمینځ د نوي مشر ټاکنه تنظیم کړې که چیرې پخوانی مشر د کوم دلیل لپاره شتون ونلري.
منظم غوښتنلیکونه او خدمات د ډیفالټ کیوب - مهالویش له لارې مهالویش ته دوام ورکوي ، او د کرون ټولې دندې په بشپړ ډول نوي ته لیږدول شوي. د کرون دندو لخوا رامینځته شوی بار اوس په ټولو نوډونو کې په مساوي ډول توزیع شوی. د دې په پام کې نیولو سره چې د کرون ډیری دندې د پروژې اصلي غوښتنلیکونو په څیر په ورته نوډونو کې اجرا کیږي، دې د سرچینو نشتوالي له امله د پوډونو حرکت کولو خطر د پام وړ کم کړی. د اضافي کیوب - مهالویش معرفي کولو وروسته ، د کرون دندو غیر مساوي مهالویش سره ستونزې نور نه راپورته کیږي.
زموږ په بلاګ کې نورې مقالې هم ولولئ:
سرچینه: www.habr.com