Kube-షెడ్యూలర్ అనేది Kubernetes యొక్క అంతర్భాగం, ఇది పేర్కొన్న విధానాలకు అనుగుణంగా నోడ్‌లలో పాడ్‌లను షెడ్యూల్ చేయడానికి బాధ్యత వహిస్తుంది. తరచుగా, Kubernetes క్లస్టర్ యొక్క ఆపరేషన్ సమయంలో, పాడ్‌లను షెడ్యూల్ చేయడానికి ఏ విధానాలను ఉపయోగించాలో మనం ఆలోచించాల్సిన అవసరం లేదు, ఎందుకంటే డిఫాల్ట్ kube-షెడ్యూలర్ యొక్క విధానాల సెట్ చాలా రోజువారీ పనులకు అనుకూలంగా ఉంటుంది. అయినప్పటికీ, పాడ్‌లను కేటాయించే ప్రక్రియను చక్కగా ట్యూన్ చేయడం మాకు ముఖ్యమైన సందర్భాలు ఉన్నాయి మరియు ఈ పనిని సాధించడానికి రెండు మార్గాలు ఉన్నాయి:
- అనుకూల నియమాల సెట్‌తో kube-షెడ్యూలర్‌ను సృష్టించండి
- మీ స్వంత షెడ్యూలర్‌ని వ్రాయండి మరియు API సర్వర్ అభ్యర్థనలతో పని చేయడానికి నేర్పండి
ఈ వ్యాసంలో, మా ప్రాజెక్ట్‌లలో ఒకదానిపై పొయ్యిల అసమాన షెడ్యూల్ యొక్క సమస్యను పరిష్కరించడానికి మొదటి పాయింట్ యొక్క అమలును నేను వివరిస్తాను.
kube-షెడ్యూలర్ ఎలా పని చేస్తుందో సంక్షిప్త పరిచయం
పాడ్‌లను నేరుగా షెడ్యూల్ చేయడానికి kube-షెడ్యూలర్ బాధ్యత వహించదు - ఇది పాడ్‌ను ఉంచే నోడ్‌ను నిర్ణయించడానికి మాత్రమే బాధ్యత వహిస్తుంది. మరో మాటలో చెప్పాలంటే, kube-షెడ్యూలర్ యొక్క పని ఫలితం నోడ్ పేరు, ఇది షెడ్యూలింగ్ అభ్యర్థన కోసం API సర్వర్‌కు తిరిగి వస్తుంది మరియు దాని పని అక్కడ ముగుస్తుంది.
ముందుగా, kube-షెడ్యూలర్ ముందస్తు విధానాలకు అనుగుణంగా పాడ్‌ను షెడ్యూల్ చేయగల నోడ్‌ల జాబితాను కంపైల్ చేస్తుంది. తర్వాత, ఈ జాబితా నుండి ప్రతి నోడ్ ప్రాధాన్యతల విధానాలకు అనుగుణంగా నిర్దిష్ట సంఖ్యలో పాయింట్లను పొందుతుంది. ఫలితంగా, గరిష్ట సంఖ్యలో పాయింట్లతో నోడ్ ఎంపిక చేయబడింది. అదే గరిష్ట స్కోర్‌ను కలిగి ఉన్న నోడ్‌లు ఉంటే, యాదృచ్ఛికంగా ఒకటి ఎంపిక చేయబడుతుంది. ప్రిడికేట్స్ (ఫిల్టరింగ్) మరియు ప్రాధాన్యాల (స్కోరింగ్) విధానాల జాబితా మరియు వివరణను ఇందులో చూడవచ్చు .
సమస్య శరీరం యొక్క వివరణ
Nixys వద్ద పెద్ద సంఖ్యలో వివిధ Kubernetes క్లస్టర్‌లు నిర్వహించబడుతున్నప్పటికీ, మా ప్రాజెక్ట్‌లలో ఒకదానికి పెద్ద సంఖ్యలో ఆవర్తన పనులను (~100 CronJob ఎంటిటీలు) అమలు చేయాల్సిన అవసరం వచ్చినప్పుడు, మేము ఇటీవల పాడ్‌లను షెడ్యూల్ చేయడంలో సమస్యను ఎదుర్కొన్నాము. సమస్య యొక్క వివరణను సాధ్యమైనంతవరకు సరళీకృతం చేయడానికి, మేము ఒక మైక్రోసర్వీస్‌ని ఉదాహరణగా తీసుకుంటాము, దానిలో ఒక నిమిషానికి ఒకసారి క్రాన్ టాస్క్ ప్రారంభించబడుతుంది, ఇది CPUపై కొంత లోడ్‌ను సృష్టిస్తుంది. క్రాన్ టాస్క్‌ను అమలు చేయడానికి, పూర్తిగా ఒకే విధమైన లక్షణాలతో మూడు నోడ్‌లు కేటాయించబడ్డాయి (ఒక్కొక్కటిపై 24 vCPUలు).
అదే సమయంలో, ఇన్‌పుట్ డేటా వాల్యూమ్ నిరంతరం మారుతూ ఉంటుంది కాబట్టి, CronJob అమలు చేయడానికి ఎంత సమయం పడుతుందో ఖచ్చితంగా చెప్పడం అసాధ్యం. సగటున, kube-షెడ్యూలర్ యొక్క సాధారణ ఆపరేషన్ సమయంలో, ప్రతి నోడ్ 3-4 ఉద్యోగ సందర్భాలను అమలు చేస్తుంది, ఇది ప్రతి నోడ్ యొక్క CPUపై ~20-30% లోడ్‌ను సృష్టిస్తుంది:
సమస్య ఏమిటంటే, కొన్నిసార్లు క్రాన్ టాస్క్ పాడ్‌లు మూడు నోడ్‌లలో ఒకదానిలో షెడ్యూల్ చేయబడటం ఆగిపోయింది. అంటే, ఏదో ఒక సమయంలో, నోడ్‌లలో ఒకదానికి ఒక్క పాడ్ కూడా ప్లాన్ చేయబడలేదు, మిగిలిన రెండు నోడ్‌లలో టాస్క్ యొక్క 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దీని నుండి నోడ్‌లలో ఒకటి ఇతర వాటి కంటే తక్కువ తుది పాయింట్లను స్కోర్ చేసినట్లు చూడవచ్చు మరియు అందువల్ల గరిష్ట స్కోర్‌ను సాధించిన రెండు నోడ్‌ల కోసం మాత్రమే ప్రణాళిక రూపొందించబడింది. అందువల్ల, పాడ్‌ల షెడ్యూల్‌లో సమస్య ఖచ్చితంగా ఉందని మేము ఖచ్చితంగా ఒప్పించాము.
సమస్యను పరిష్కరించడానికి తదుపరి అల్గోరిథం మాకు స్పష్టంగా ఉంది - లాగ్‌లను విశ్లేషించండి, నోడ్ ఏ ప్రాధాన్యతతో పాయింట్లను స్కోర్ చేయలేదని అర్థం చేసుకోండి మరియు అవసరమైతే, డిఫాల్ట్ క్యూబ్-షెడ్యూలర్ యొక్క విధానాలను సర్దుబాటు చేయండి. అయితే, ఇక్కడ మేము రెండు ముఖ్యమైన సమస్యలను ఎదుర్కొంటున్నాము:
- గరిష్ట లాగింగ్ స్థాయి (10) వద్ద, కొన్ని ప్రాధాన్యతల కోసం మాత్రమే పొందిన పాయింట్లు ప్రతిబింబిస్తాయి. పైన పేర్కొన్న లాగ్‌ల సారాంశంలో, లాగ్‌లలో ప్రతిబింబించే అన్ని ప్రాధాన్యతలకు, నోడ్‌లు సాధారణ మరియు సమస్య షెడ్యూలింగ్‌లో ఒకే సంఖ్యలో పాయింట్లను స్కోర్ చేస్తాయని మీరు చూడవచ్చు, అయితే సమస్య ప్రణాళిక విషయంలో తుది ఫలితం భిన్నంగా ఉంటుంది. అందువల్ల, కొన్ని ప్రాధాన్యతల కోసం, స్కోరింగ్ "తెర వెనుక" జరుగుతుందని మేము నిర్ధారించగలము మరియు నోడ్ ఏ ప్రాధాన్యత కోసం పాయింట్లను పొందలేదో అర్థం చేసుకోవడానికి మాకు మార్గం లేదు. మేము ఈ సమస్యను వివరంగా వివరించాము గితుబ్‌లో కుబెర్నెటెస్ రిపోజిటరీ. వ్రాసే సమయంలో, కుబెర్నెట్స్ v1.15,1.16, 1.17 మరియు XNUMX అప్‌డేట్‌లలో లాగింగ్ సపోర్ట్ జోడించబడుతుందని డెవలపర్‌ల నుండి ప్రతిస్పందన వచ్చింది.
- kube-షెడ్యూలర్ ప్రస్తుతం ఏ నిర్దిష్ట విధానాలతో పని చేస్తుందో అర్థం చేసుకోవడానికి సులభమైన మార్గం లేదు. అవును, లో ఈ జాబితా జాబితా చేయబడింది, కానీ ప్రతి ప్రాధాన్యతా విధానాలకు ఏ నిర్దిష్ట బరువులు కేటాయించబడ్డాయనే దాని గురించిన సమాచారం ఇందులో లేదు. మీరు డిఫాల్ట్ kube-షెడ్యూలర్‌లో మాత్రమే బరువులను చూడగలరు లేదా పాలసీలను సవరించగలరు .
ఇమేజ్‌లోకాలిటీ ప్రయారిటీ విధానం ప్రకారం నోడ్‌కు పాయింట్లు అందలేదని మేము ఒకసారి రికార్డ్ చేయగలిగాము, ఇది అప్లికేషన్‌ను అమలు చేయడానికి అవసరమైన ఇమేజ్‌ని కలిగి ఉన్నట్లయితే నోడ్‌కు అవార్డును ఇస్తుంది. అంటే, అప్లికేషన్ యొక్క కొత్త వెర్షన్‌ను రూపొందించిన సమయంలో, క్రాన్ టాస్క్ రెండు నోడ్‌లలో అమలు చేయగలిగింది, డాకర్ రిజిస్ట్రీ నుండి వాటికి కొత్త చిత్రాన్ని డౌన్‌లోడ్ చేస్తుంది మరియు తద్వారా రెండు నోడ్‌లు మూడవ దానికి సంబంధించి ఎక్కువ తుది స్కోర్‌ను పొందాయి. .
నేను పైన వ్రాసినట్లుగా, లాగ్‌లలో ImageLocalityPriority విధానం యొక్క మూల్యాంకనం గురించిన సమాచారం మనకు కనిపించదు, కాబట్టి మా ఊహను తనిఖీ చేయడానికి, మేము అప్లికేషన్ యొక్క కొత్త వెర్షన్‌తో చిత్రాన్ని మూడవ నోడ్‌లో ఉంచాము, ఆ తర్వాత షెడ్యూలింగ్ సరిగ్గా పనిచేసింది . ImageLocalityPriority విధానం కారణంగా షెడ్యూలింగ్ సమస్య చాలా అరుదుగా గమనించబడింది; చాలా తరచుగా ఇది వేరొకదానితో అనుబంధించబడుతుంది. మేము డిఫాల్ట్ kube-షెడ్యూలర్ యొక్క ప్రాధాన్యతల జాబితాలోని ప్రతి పాలసీని పూర్తిగా డీబగ్ చేయలేనందున, మాకు పాడ్ షెడ్యూలింగ్ విధానాల యొక్క సౌకర్యవంతమైన నిర్వహణ అవసరం.
సమస్య యొక్క ప్రకటన
సమస్యకు పరిష్కారం సాధ్యమైనంత నిర్దిష్టంగా ఉండాలని మేము కోరుకున్నాము, అంటే, కుబెర్నెట్స్ యొక్క ప్రధాన అంశాలు (ఇక్కడ డిఫాల్ట్ kube-షెడ్యూలర్ అని అర్థం) మారకుండా ఉండాలి. మేము సమస్యను ఒక చోట పరిష్కరించి, మరొక చోట సృష్టించాలని అనుకోలేదు. అందువల్ల, సమస్యను పరిష్కరించడానికి మేము రెండు ఎంపికలకు వచ్చాము, ఇవి కథనానికి పరిచయంలో ప్రకటించబడ్డాయి - అదనపు షెడ్యూలర్‌ను సృష్టించడం లేదా మీ స్వంతంగా రాయడం. క్రాన్ టాస్క్‌లను షెడ్యూల్ చేయడానికి ప్రధాన అవసరం ఏమిటంటే, లోడ్‌ను మూడు నోడ్‌లలో సమానంగా పంపిణీ చేయడం. ఈ ఆవశ్యకతను ఇప్పటికే ఉన్న kube-షెడ్యూలర్ విధానాల ద్వారా సంతృప్తిపరచవచ్చు, కాబట్టి మా సమస్యను పరిష్కరించడానికి మీ స్వంత షెడ్యూలర్‌ను వ్రాయడంలో అర్థం లేదు.
అదనపు క్యూబ్-షెడ్యూలర్‌ను సృష్టించడం మరియు అమలు చేయడం కోసం సూచనలు వివరించబడ్డాయి . అయినప్పటికీ, kube-షెడ్యూలర్ వంటి క్లిష్టమైన సేవ యొక్క ఆపరేషన్‌లో తప్పును సహించడాన్ని నిర్ధారించడానికి డిప్లాయ్‌మెంట్ ఎంటిటీ సరిపోదని మాకు అనిపించింది, కాబట్టి మేము కొత్త kube-షెడ్యూలర్‌ను స్టాటిక్ పాడ్‌గా అమలు చేయాలని నిర్ణయించుకున్నాము, అది నేరుగా పర్యవేక్షించబడుతుంది కుబెలెట్ ద్వారా. కాబట్టి, మేము కొత్త kube-షెడ్యూలర్ కోసం క్రింది అవసరాలను కలిగి ఉన్నాము:
- అన్ని క్లస్టర్ మాస్టర్‌లలో సేవ తప్పనిసరిగా స్టాటిక్ పాడ్‌గా అమలు చేయబడాలి
- kube-షెడ్యూలర్‌తో యాక్టివ్ పాడ్ అందుబాటులో లేనప్పుడు తప్పక ఫాల్ట్ టాలరెన్స్ అందించాలి
- ప్లాన్ చేసేటప్పుడు ప్రధాన ప్రాధాన్యత నోడ్‌లో అందుబాటులో ఉన్న వనరుల సంఖ్య (తక్కువ అభ్యర్థన ప్రాధాన్యత)
పరిష్కారం అమలు
మేము 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ప్రధాన మార్పుల గురించి క్లుప్తంగా:
- పాడ్ మరియు కంటైనర్ పేరు kube-scheduler-cronగా మార్చబడింది
- ఎంపిక నిర్వచించబడినట్లుగా 10151 మరియు 10159 పోర్ట్‌ల వినియోగాన్ని పేర్కొనబడింది
hostNetwork: trueమరియు మేము డిఫాల్ట్ kube-షెడ్యూలర్ (10251 మరియు 10259) వలె అదే పోర్ట్‌లను ఉపయోగించలేము. - --config పరామితిని ఉపయోగించి, సేవను ప్రారంభించాల్సిన కాన్ఫిగరేషన్ ఫైల్‌ను మేము పేర్కొన్నాము
- హోస్ట్ నుండి కాన్ఫిగరేషన్ ఫైల్ (షెడ్యూలర్-కస్టమ్.conf) మరియు షెడ్యూలింగ్ పాలసీ ఫైల్ (షెడ్యూలర్-కస్టమ్-పాలసీ-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"ప్రధాన మార్పుల గురించి క్లుప్తంగా:
- మేము మా kube-scheduler-cron సేవ పేరుకు షెడ్యూలర్ పేరును సెట్ చేసాము.
- పరామితిలో
lockObjectNameమీరు మా సేవ పేరును కూడా సెట్ చేయాలి మరియు పరామితిని నిర్ధారించుకోవాలిleaderElectఒప్పుకు సెట్ చేయండి (మీకు ఒక మాస్టర్ నోడ్ ఉంటే, మీరు దాన్ని తప్పుగా సెట్ చేయవచ్చు). - పరామితిలో షెడ్యూలింగ్ విధానాల వివరణతో ఫైల్‌కి పాత్‌ను పేర్కొనబడింది
algorithmSource.
ఇది రెండవ పాయింట్ వద్ద నిశితంగా పరిశీలించడం విలువైనది, ఇక్కడ మేము కీ కోసం పారామితులను సవరించాము leaderElection. తప్పు సహనాన్ని నిర్ధారించడానికి, మేము ప్రారంభించాము (leaderElect) మా kube-షెడ్యూలర్ యొక్క పాడ్‌ల మధ్య ఒక నాయకుడిని (మాస్టర్) ఎంపిక చేసే ప్రక్రియ, వాటి కోసం ఒకే ముగింపు బిందువును ఉపయోగిస్తుంది (resourceLock) కుబే-షెడ్యూలర్-క్రాన్ (lockObjectName) కుబే-సిస్టమ్ నేమ్‌స్పేస్‌లో (lockObjectNamespace) ప్రధాన భాగాల (కుబే-షెడ్యూలర్‌తో సహా) అధిక లభ్యతను కుబెర్నెటెస్ ఎలా నిర్ధారిస్తుంది .
- షెడ్యూలింగ్ పాలసీ ఫైల్ (షెడ్యూలర్-కస్టమ్-పాలసీ-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-scheduler ముందుగా 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-షెడ్యూలర్‌ని పొందాము, దీని పనిని నేరుగా kubelet పర్యవేక్షిస్తుంది. అదనంగా, కొన్ని కారణాల వల్ల పాత నాయకుడు అందుబాటులో లేని పక్షంలో మా కుబే-షెడ్యూలర్‌ల మధ్య కొత్త నాయకుడి ఎన్నికను ఏర్పాటు చేసాము.
సాధారణ అప్లికేషన్లు మరియు సేవలు డిఫాల్ట్ kube-షెడ్యూలర్ ద్వారా షెడ్యూల్ చేయబడటం కొనసాగుతుంది మరియు అన్ని క్రాన్ టాస్క్‌లు పూర్తిగా కొత్తదానికి బదిలీ చేయబడ్డాయి. క్రాన్ టాస్క్‌ల ద్వారా సృష్టించబడిన లోడ్ ఇప్పుడు అన్ని నోడ్‌లలో సమానంగా పంపిణీ చేయబడింది. ప్రాజెక్ట్ యొక్క ప్రధాన అప్లికేషన్‌ల వలె చాలా క్రాన్ టాస్క్‌లు అదే నోడ్‌లలో అమలు చేయబడతాయని పరిగణనలోకి తీసుకుంటే, ఇది వనరుల కొరత కారణంగా పాడ్‌లను తరలించే ప్రమాదాన్ని గణనీయంగా తగ్గించింది. అదనపు kube-షెడ్యూలర్‌ను పరిచయం చేసిన తర్వాత, క్రాన్ టాస్క్‌ల అసమాన షెడ్యూల్‌తో సమస్యలు తలెత్తలేదు.
మా బ్లాగ్‌లోని ఇతర కథనాలను కూడా చదవండి:
మూలం: www.habr.com