🥇დამატებითი კუბე-დისპეჩერის შექმნა დაგეგმვის წესების მორგებული ნაკრებით

Kube-scheduler არის Kubernetes-ის განუყოფელი კომპონენტი, რომელიც პასუხისმგებელია კვანძების კვანძების დაგეგმვაზე მითითებული პოლიტიკის შესაბამისად. ხშირად, Kubernetes კლასტერის ფუნქციონირების დროს, ჩვენ არ გვიწევს ფიქრი იმაზე, თუ რომელი პოლიტიკის გამოყენება ხდება pod-ების დასაგეგმად, რადგან ნაგულისხმევი kube-scheduler-ის პოლიტიკის ნაკრები შესაფერისია ყოველდღიური ამოცანების უმეტესობისთვის. თუმცა, არის სიტუაციები, როდესაც ჩვენთვის მნიშვნელოვანია წიაღისეულის გამოყოფის პროცესის დახვეწა და ამ ამოცანის შესრულების ორი გზა არსებობს:

შექმენით კუბე-დისპეჩერი წესების მორგებული ნაკრებით
დაწერეთ თქვენი საკუთარი გრაფიკი და ასწავლეთ მას მუშაობა API სერვერის მოთხოვნებთან

ამ სტატიაში მე აღვწერ პირველი პუნქტის განხორციელებას ჩვენს ერთ-ერთ პროექტზე კერების არათანაბარი დაგეგმვის პრობლემის გადასაჭრელად.

მოკლე შესავალი, თუ როგორ მუშაობს kube-scheduler

განსაკუთრებით უნდა აღინიშნოს ის ფაქტი, რომ kube-scheduler არ არის პასუხისმგებელი პოდების პირდაპირ დაგეგმვაზე - ის მხოლოდ პასუხისმგებელია იმ კვანძის განსაზღვრაზე, რომელზედაც განთავსდება პოდი. სხვა სიტყვებით რომ ვთქვათ, kube-scheduler-ის მუშაობის შედეგი არის კვანძის სახელი, რომელსაც იგი უბრუნებს API სერვერს დაგეგმვის მოთხოვნით და აქ მთავრდება მისი მუშაობა.

პირველ რიგში, kube-scheduler ადგენს კვანძების ჩამონათვალს, რომლებზეც pod შეიძლება დაიგეგმოს პრედიკატების პოლიტიკის შესაბამისად. შემდეგი, ამ სიიდან თითოეული კვანძი იღებს ქულების გარკვეულ რაოდენობას პრიორიტეტების პოლიტიკის შესაბამისად. შედეგად, არჩეულია კვანძი, რომელსაც აქვს ქულების მაქსიმალური რაოდენობა. თუ არის კვანძები, რომლებსაც აქვთ იგივე მაქსიმალური ქულა, არჩეულია შემთხვევითი. პრედიკატების (ფილტრაციის) და პრიორიტეტების (ქულების) პოლიტიკის ჩამონათვალი და აღწერა შეგიძლიათ იხილოთ დოკუმენტაცია.

პრობლემური სხეულის აღწერა

მიუხედავად იმისა, რომ კუბერნეტის კლასტერების დიდი რაოდენობა შენარჩუნებულია Nixys-ში, ჩვენ პირველად შეგვხვდა პოდების დაგეგმვის პრობლემა მხოლოდ ახლახან, როდესაც ჩვენს ერთ-ერთ პროექტს სჭირდებოდა პერიოდული ამოცანების დიდი რაოდენობის შესრულება (~ 100 CronJob ერთეული). პრობლემის აღწერის მაქსიმალურად გასამარტივებლად, ჩვენ ავიღოთ მაგალითად ერთი მიკროსერვისი, რომლის ფარგლებშიც წუთში ერთხელ იწყება cron ამოცანა, რაც ქმნის გარკვეულ დატვირთვას CPU-ზე. cron ამოცანის გასაშვებად გამოიყო სამი კვანძი აბსოლუტურად იდენტური მახასიათებლებით (თითოეულზე 24 vCPU).

ამავდროულად, შეუძლებელია იმის თქმა, თუ რამდენი დრო დასჭირდება CronJob-ს შესრულებას, რადგან შეყვანის მონაცემების მოცულობა მუდმივად იცვლება. საშუალოდ, kube-scheduler-ის ნორმალური მუშაობის დროს, თითოეული კვანძი აწარმოებს 3-4 სამუშაო ინსტანციას, რაც ქმნის დატვირთვის ~20-30% თითოეული კვანძის CPU-ზე:

თავად პრობლემა ის არის, რომ ზოგჯერ cron task pod-ების დაგეგმვა შეჩერდა სამი კვანძიდან ერთ-ერთზე. ანუ, დროის გარკვეულ მომენტში, არც ერთი კვანძი არ იყო დაგეგმილი ერთ-ერთი კვანძისთვის, ხოლო დანარჩენ ორ კვანძზე მოქმედებდა დავალების 6-8 ასლი, რაც ქმნიდა CPU-ს დატვირთვის ~ 40-60%-ს:

პრობლემა განმეორდა აბსოლუტურად შემთხვევითი სიხშირით და ზოგჯერ კორელაციაში იყო კოდის ახალი ვერსიის გამოშვების მომენტთან.

kube-scheduler logging დონის 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-scheduler-ის პოლიტიკა. თუმცა, აქ ორი მნიშვნელოვანი სირთულის წინაშე ვდგავართ:

ჭრის მაქსიმალურ დონეზე (10) აისახება მხოლოდ ზოგიერთი პრიორიტეტისათვის მოპოვებული ქულები. ჟურნალების ზემოხსენებულ ამონარიდში ხედავთ, რომ ჟურნალებში ასახული ყველა პრიორიტეტისთვის, კვანძები ერთსა და იმავე რაოდენობას აგროვებენ ნორმალურ და პრობლემის დაგეგმვაში, მაგრამ საბოლოო შედეგი პრობლემის დაგეგმვის შემთხვევაში განსხვავებულია. ამრიგად, შეგვიძლია დავასკვნათ, რომ ზოგიერთი პრიორიტეტისთვის, ქულები ხდება „კულისებში“ და ჩვენ არ გვაქვს საშუალება გავიგოთ, რომელი პრიორიტეტისთვის კვანძმა არ მიიღო ქულები. ჩვენ დეტალურად აღვწერეთ ეს პრობლემა საკითხი Kubernetes-ის საცავი Github-ზე. წერის დროს მიიღეს პასუხი დეველოპერებისგან, რომ ლოგის მხარდაჭერა დაემატება Kubernetes v1.15,1.16, 1.17 და XNUMX განახლებებს.
არ არსებობს მარტივი გზა იმის გასაგებად, თუ რომელ კონკრეტულ პოლიტიკით მუშაობს kube-scheduler ამჟამად. დიახ, შიგნით დოკუმენტაცია ეს სია ჩამოთვლილია, მაგრამ ის არ შეიცავს ინფორმაციას იმის შესახებ, თუ რა კონკრეტული წონა ენიჭება თითოეულ პრიორიტეტულ პოლიტიკას. თქვენ შეგიძლიათ ნახოთ წონები ან დაარედაქტიროთ ნაგულისხმევი kube-scheduler-ის წესები მხოლოდ აქ წყარო კოდები.

აღსანიშნავია, რომ ერთხელ ჩვენ შევძელით ჩაწერა, რომ კვანძმა არ მიიღო ქულები ImageLocalityPriority პოლიტიკის მიხედვით, რომელიც ანიჭებს ქულებს კვანძს, თუ მას უკვე აქვს აპლიკაციის გასაშვებად საჭირო სურათი. ანუ, იმ დროს, როდესაც აპლიკაციის ახალი ვერსია გამოვიდა, cron ამოცანამ მოახერხა ორ კვანძზე გაშვება, მათზე ახალი სურათის ჩამოტვირთვა დოკერის რეესტრიდან და, ამრიგად, ორმა კვანძმა მიიღო უფრო მაღალი საბოლოო ქულა მესამესთან შედარებით. .

როგორც ზემოთ დავწერე, ჟურნალებში ჩვენ ვერ ვხედავთ ინფორმაციას ImageLocalityPriority პოლიტიკის შეფასების შესახებ, ასე რომ, ჩვენი ვარაუდის შესამოწმებლად, ჩვენ გადავიტანეთ სურათი აპლიკაციის ახალი ვერსიით მესამე კვანძში, რის შემდეგაც დაგეგმვა სწორად მუშაობდა. . ზუსტად ImageLocalityPriority პოლიტიკის გამო იყო, რომ დაგეგმვის პრობლემა საკმაოდ იშვიათად შეინიშნებოდა, უფრო ხშირად ის სხვა რამესთან იყო დაკავშირებული. იმის გამო, რომ ჩვენ ვერ მოვახერხეთ ნაგულისხმევი kube-scheduler-ის პრიორიტეტების ჩამონათვალში თითოეული პოლიტიკის სრულად გამართვა, ჩვენ გვქონდა საჭიროება pod-ის დაგეგმვის პოლიტიკის მოქნილი მართვა.

პრობლემის შესახებ განცხადება

ჩვენ გვინდოდა, რომ პრობლემის გადაჭრა მაქსიმალურად კონკრეტული ყოფილიყო, ანუ Kubernetes-ის ძირითადი ერთეულები (აქ ვგულისხმობთ ნაგულისხმევი kube-scheduler) უნდა დარჩეს უცვლელი. არ გვინდოდა პრობლემა ერთ ადგილას გადაგვეჭრა და მეორეში შეგვექმნა. ამრიგად, ჩვენ მივედით პრობლემის გადაჭრის ორ ვარიანტამდე, რომელიც გამოცხადდა სტატიის შესავალში - დამატებითი გრაფიკის შექმნა ან საკუთარის დაწერა. Cron ამოცანების დაგეგმვის მთავარი მოთხოვნა არის დატვირთვის თანაბრად განაწილება სამ კვანძზე. ამ მოთხოვნას შეიძლება დააკმაყოფილოს არსებული kube-scheduler პოლიტიკა, ამიტომ ჩვენი პრობლემის გადასაჭრელად აზრი არ აქვს საკუთარი განრიგის დაწერას.

დამატებითი კუბე-დისპეჩერის შექმნისა და დანერგვის ინსტრუქციები აღწერილია აქ დოკუმენტაცია. თუმცა, ჩვენ გვეჩვენა, რომ Deployment ერთეული არ იყო საკმარისი იმისათვის, რომ უზრუნველყოფილიყო ხარვეზების ტოლერანტობა ისეთი კრიტიკული სერვისის ფუნქციონირებაში, როგორიცაა kube-scheduler, ამიტომ გადავწყვიტეთ გამოგვეყენებინა ახალი kube-scheduler, როგორც Static Pod, რომელიც უშუალოდ მონიტორინგდებოდა. კუბელეტის მიერ. ამდენად, ჩვენ გვაქვს შემდეგი მოთხოვნები ახალი kube-განმგეგმავისთვის:

სერვისი უნდა განთავსდეს როგორც Static Pod ყველა კლასტერზე
შეცდომის ტოლერანტობა უნდა იყოს უზრუნველყოფილი იმ შემთხვევაში, თუ აქტიური პოდიუმი kube-scheduler-ით მიუწვდომელია
დაგეგმვისას მთავარი პრიორიტეტი უნდა იყოს კვანძზე არსებული რესურსების რაოდენობა (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

მოკლედ ძირითადი ცვლილებების შესახებ:

შეცვალა pod და კონტეინერის სახელი kube-scheduler-cron
მითითებულია 10151 და 10159 პორტების გამოყენება, როგორც ოფცია განისაზღვრა hostNetwork: true და ჩვენ არ შეგვიძლია გამოვიყენოთ იგივე პორტები, როგორც ნაგულისხმევი kube-scheduler (10251 და 10259)
--config პარამეტრის გამოყენებით, ჩვენ დავაზუსტეთ კონფიგურაციის ფაილი, რომლითაც უნდა დაიწყოს სერვისი
კონფიგურაციის ფაილის (scheduler-custom.conf) და პოლიტიკის ფაილის დაგეგმვის (scheduler-custom-policy-config.json) კონფიგურირებული მონტაჟი ჰოსტიდან

არ უნდა დაგვავიწყდეს, რომ ჩვენს kube-scheduler-ს დასჭირდება ნაგულისხმევის მსგავსი უფლებები. შეცვალეთ მისი კლასტერული როლი:

kubectl edit clusterrole system:kube-scheduler

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

ახლა მოდით ვისაუბროთ იმაზე, თუ რას უნდა შეიცავდეს კონფიგურაციის ფაილი და დაგეგმვის პოლიტიკის ფაილი:

კონფიგურაციის ფაილი (scheduler-custom.conf)
ნაგულისხმევი kube-scheduler კონფიგურაციის მისაღებად, თქვენ უნდა გამოიყენოთ პარამეტრი --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"

მოკლედ ძირითადი ცვლილებების შესახებ:

ჩვენ დავაყენეთ schedulerName ჩვენი kube-scheduler-cron სერვისის სახელზე.
პარამეტრში lockObjectName თქვენ ასევე უნდა დააყენოთ ჩვენი სერვისის სახელი და დარწმუნდეთ, რომ პარამეტრი leaderElect დაყენებულია true-ზე (თუ თქვენ გაქვთ ერთი ძირითადი კვანძი, შეგიძლიათ დააყენოთ იგი false-ზე).
მიუთითეთ ფაილის გზა პარამეტრში დაგეგმვის პოლიტიკის აღწერით algorithmSource.

ღირს ყურადღებით დავაკვირდეთ მეორე პუნქტს, სადაც ჩვენ ვასწორებთ პარამეტრებს გასაღებისთვის leaderElection. შეცდომების ტოლერანტობის უზრუნველსაყოფად, ჩვენ გავააქტიურეთ (leaderElect) ლიდერის (მაგისტრის) შერჩევის პროცესი ჩვენი კუბე-სქედულერის პოდებს შორის მათთვის ერთი საბოლოო წერტილის გამოყენებით (resourceLock) სახელად kube-scheduler-cron (lockObjectName) kube სისტემის სახელთა სივრცეში (lockObjectNamespace). როგორ უზრუნველყოფს Kubernetes ძირითადი კომპონენტების მაღალ ხელმისაწვდომობას (მათ შორის kube-scheduler), შეგიძლიათ იხილოთ მუხლი.

პოლიტიკის ფაილის დაგეგმვა (scheduler-custom-policy-config.json)
როგორც ადრე დავწერე, ჩვენ შეგვიძლია გავარკვიოთ რომელ კონკრეტულ პოლიტიკასთან მუშაობს ნაგულისხმევი kube-scheduler მხოლოდ მისი კოდის ანალიზით. ანუ, ჩვენ არ შეგვიძლია მივიღოთ ფაილი დაგეგმვის პოლიტიკით ნაგულისხმევი kube-scheduler-ისთვის ისევე, როგორც კონფიგურაციის ფაილი. მოდით აღვწეროთ დაგეგმვის პოლიტიკა, რომელიც გვაინტერესებს /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 ჯერ ადგენს კვანძების ჩამონათვალს, რომლებზედაც შესაძლებელია pod-ის დაგეგმვა GeneralPredicates პოლიტიკის მიხედვით (რომელიც მოიცავს PodFitsResources, PodFitsHostPorts, HostName და MatchNodeSelector პოლიტიკის კომპლექტს). და შემდეგ თითოეული კვანძი ფასდება პრიორიტეტების მასივის პოლიტიკის ნაკრების შესაბამისად. ჩვენი ამოცანის პირობების შესასრულებლად მივიჩნიეთ, რომ პოლიტიკის ასეთი ნაკრები იქნებოდა ოპტიმალური გადაწყვეტა. შეგახსენებთ, რომ პოლიტიკის კომპლექტი მათი დეტალური აღწერილობით ხელმისაწვდომია დოკუმენტაცია. თქვენი ამოცანის შესასრულებლად, შეგიძლიათ უბრალოდ შეცვალოთ გამოყენებული პოლიტიკის ნაკრები და მივანიჭოთ მათ შესაბამისი წონა.

მოდით ვუწოდოთ ახალი kube-scheduler-ის მანიფესტს, რომელიც შევქმენით თავის დასაწყისში, kube-scheduler-custom.yaml და მოვათავსოთ შემდეგ გზაზე /etc/kubernetes/manifests სამ მთავარ კვანძზე. თუ ყველაფერი სწორად გაკეთდა, Kubelet გამოუშვებს პოდს თითოეულ კვანძზე და ჩვენი ახალი kube-scheduler-ის ჟურნალებში ვნახავთ ინფორმაციას, რომ ჩვენი პოლიტიკის ფაილი წარმატებით იქნა გამოყენებული:

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-ის სპეციფიკაციაში მითითება, რომ მისი პოდლების დაგეგმვის ყველა მოთხოვნა დამუშავებული უნდა იყოს ჩვენი ახალი კუბე-დისპეჩერის მიერ:

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

დასკვნა

საბოლოო ჯამში, ჩვენ მივიღეთ დამატებითი კუბე-დისპეჩერი, განრიგის პოლიტიკის უნიკალური ნაკრებით, რომლის მუშაობას უშუალოდ კუბელეტი აკონტროლებს. გარდა ამისა, ჩვენ დავაყენეთ ახალი ლიდერის არჩევა ჩვენი კუბე-განრიგის პოდებს შორის იმ შემთხვევაში, თუ ძველი ლიდერი რაიმე მიზეზით მიუწვდომელი გახდება.

რეგულარული აპლიკაციებისა და სერვისების დაგეგმვა გრძელდება ნაგულისხმევი kube-scheduler-ის მეშვეობით და ყველა cron ამოცანა მთლიანად გადავიდა ახალზე. cron ამოცანების მიერ შექმნილი დატვირთვა ახლა თანაბრად ნაწილდება ყველა კვანძზე. იმის გათვალისწინებით, რომ კრონის ამოცანების უმეტესობა შესრულებულია იმავე კვანძებზე, როგორც პროექტის ძირითადი აპლიკაციები, ამან მნიშვნელოვნად შეამცირა პოდების გადაადგილების რისკი რესურსების ნაკლებობის გამო. დამატებითი kube-scheduler-ის შემოღების შემდეგ, პრობლემები აღარ წარმოიშვა cron ამოცანების არათანაბარი განრიგთან დაკავშირებით.

ასევე წაიკითხეთ სხვა სტატიები ჩვენს ბლოგზე:

წყარო: www.habr.com

დამატებითი კუბე-დისპეჩერის შექმნა დაგეგმვის წესების მორგებული ნაკრებით