🥇יצירת קובי-תזמון נוסף עם סט מותאם אישית של כללי תזמון

Kube-scheduler הוא רכיב אינטגרלי של Kubernetes, אשר אחראי על תזמון פודים על פני צמתים בהתאם למדיניות שצוינה. לעתים קרובות, במהלך ההפעלה של אשכול Kubernetes, איננו צריכים לחשוב על אילו מדיניות משמשות לתזמון פודים, מכיוון שמערכת המדיניות של ברירת המחדל של Kube-scheduler מתאימה לרוב המשימות היומיומיות. עם זאת, ישנם מצבים בהם חשוב לנו לכוונן את תהליך הקצאת התרמילים, ויש שתי דרכים לבצע משימה זו:

צור קובי-תזמן עם מערכת כללים מותאמת אישית
כתוב את מתזמן משלך ולמד אותו לעבוד עם בקשות שרת API

במאמר זה אתאר את יישום הנקודה הראשונה לפתרון הבעיה של תזמון לא אחיד של מוקדים באחד הפרויקטים שלנו.

הקדמה קצרה לאופן הפעולה של kube-scheduler

ראוי לציין במיוחד את העובדה ש-kube-scheduler אינו אחראי לתזמון ישיר של פודים - הוא אחראי רק לקביעת הצומת שעליו למקם את הפוד. במילים אחרות, התוצאה של העבודה של kube-scheduler היא שם הצומת, שהוא מחזיר לשרת ה-API לבקשת תזמון, ושם מסתיימת עבודתו.

ראשית, kube-scheduler מרכיב רשימה של צמתים עליהם ניתן לתזמן את הפוד בהתאם למדיניות הפרדיקטים. לאחר מכן, כל צומת מרשימה זו מקבל מספר מסוים של נקודות בהתאם למדיניות העדיפויות. כתוצאה מכך, הצומת עם מספר הנקודות המרבי נבחר. אם יש צמתים בעלי אותו ניקוד מקסימלי, נבחר אחד אקראי. ניתן למצוא רשימה ותיאור של מדיניות הפרדיקטים (סינון) והעדיפויות (ניקוד). תיעוד.

תיאור גוף הבעיה

למרות המספר הגדול של אשכולות Kubernetes השונים שמתוחזקים ב-Nixis, נתקלנו לראשונה בבעיה של תזמון פודים רק לאחרונה, כאשר אחד הפרויקטים שלנו היה צריך להפעיל מספר רב של משימות תקופתיות (~100 ישויות CronJob). כדי לפשט את תיאור הבעיה ככל האפשר, ניקח כדוגמה מיקרו-שירות אחד, שבתוכו מופעלת משימת cron פעם בדקה, ויוצרת עומס מסוים על ה-CPU. כדי להפעיל את משימת ה-cron, הוקצו שלושה צמתים בעלי מאפיינים זהים לחלוטין (24 vCPUs בכל אחד).

יחד עם זאת, אי אפשר לומר במדויק כמה זמן ייקח ל-CronJob לבצע, שכן נפח נתוני הקלט משתנה כל הזמן. בממוצע, במהלך פעולה רגילה של kube-scheduler, כל צומת מריץ 3-4 מופעי עבודה, שיוצרים ~20-30% מהעומס על ה-CPU של כל צומת:

הבעיה עצמה היא שלפעמים תרמימי משימות cron הפסיקו להיות מתוזמנים באחד משלושת הצמתים. כלומר, בנקודת זמן מסוימת, לא תוכנן פוד אחד עבור אחד הצמתים, בעוד שבשני הצמתים האחרים פעלו 6-8 עותקים של המשימה, ויצרו ~40-60% מעומס המעבד:

הבעיה חזרה על עצמה בתדירות אקראית לחלוטין ולעתים הייתה בקורלציה עם הרגע שבו גרסה חדשה של הקוד הופעלה.

על ידי הגדלת רמת הרישום של kube-scheduler לרמה 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), נקודות שנצברו רק עבור כמה סדרי עדיפויות באים לידי ביטוי. בקטע של יומנים לעיל, ניתן לראות שלכל סדרי העדיפויות המשתקפים ביומנים, צמתים זוכים לאותו מספר נקודות בתזמון רגיל ובתזמון בעיות, אך התוצאה הסופית במקרה של תכנון בעיה שונה. לפיכך, אנו יכולים להסיק שבסדרי עדיפויות מסוימים, הניקוד מתרחש "מאחורי הקלעים", ואין לנו דרך להבין על איזו עדיפות הצומת לא קיבל נקודות. תיארנו את הבעיה הזו בפירוט ב סוגיה מאגר Kubernetes ב- Github. בזמן כתיבת שורות אלה התקבלה תגובה מהמפתחים לפיה תתווסף תמיכה ברישום בעדכוני Kubernetes v1.15,1.16, 1.17 ו-XNUMX.
אין דרך קלה להבין עם איזה סט ספציפי של מדיניות kube-scheduler עובד כעת. כן ב תיעוד רשימה זו מופיעה ברשימה, אך היא אינה מכילה מידע על המשקלים הספציפיים המוקצים לכל אחת ממדיניות העדיפויות. אתה יכול לראות את המשקולות או לערוך את המדיניות של ברירת המחדל של מתזמן הקובייה רק ב קודי מקור.

ראוי לציין שפעם הצלחנו לרשום שצומת לא קיבל נקודות לפי מדיניות ImageLocalityPriority, המעניקה נקודות לצומת אם כבר יש לו את התמונה הדרושה להפעלת האפליקציה. כלומר, בזמן שהושקה גרסה חדשה של האפליקציה, משימת ה-cron הצליחה לרוץ על שני צמתים, להוריד להם תמונה חדשה מה-docer registry, וכך שני צמתים קיבלו ציון סופי גבוה יותר ביחס לשלישי. .

כפי שכתבתי למעלה, ביומנים איננו רואים מידע על הערכת מדיניות ImageLocalityPriority, אז כדי לבדוק את ההנחה שלנו, זרקנו את התמונה עם הגרסה החדשה של האפליקציה לצומת השלישי, ולאחר מכן התזמון עבד כמו שצריך . בדיוק בגלל מדיניות ImageLocalityPriority בעיית התזמון נצפתה לעתים רחוקות למדי; לעתים קרובות יותר היא הייתה קשורה למשהו אחר. בשל העובדה שלא יכולנו לנפות באגים מלא בכל אחת מהמדיניות ברשימת העדיפויות של ברירת המחדל של kube-scheduler, היה לנו צורך בניהול גמיש של מדיניות תזמון הפוד.

הצהרת הבעיה

רצינו שהפתרון לבעיה יהיה כמה שיותר ספציפי, כלומר, הישויות העיקריות של Kubernetes (כאן אנחנו מתכוונים ל-kube-scheduler ברירת המחדל) צריכות להישאר ללא שינוי. לא רצינו לפתור בעיה במקום אחד וליצור אותה במקום אחר. כך הגענו לשתי אפשרויות לפתרון הבעיה, שהוכרזו במבוא לכתבה – יצירת מתזמן נוסף או כתיבה משלכם. הדרישה העיקרית לתזמון משימות cron היא חלוקת העומס באופן שווה על פני שלושה צמתים. דרישה זו יכולה להיות מרוצה על ידי מדיניות Kube- Scheduler הקיימת, אז כדי לפתור את הבעיה שלנו אין טעם לכתוב את המתזמן שלך.

הוראות ליצירה ופריסה של מתזמן kube נוסף מתוארות ב תיעוד. עם זאת, נראה היה לנו שישות ה-Deployment לא מספיקה כדי להבטיח סובלנות תקלות בהפעלת שירות כה קריטי כמו kube-scheduler, ולכן החלטנו לפרוס kube-scheduler חדש כ-Static Pod, אשר יהיה במעקב ישיר. מאת Kubelet. לפיכך, יש לנו את הדרישות הבאות ל-kube-scheduler החדש:

יש לפרוס את השירות כ-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

בקצרה על השינויים העיקריים:

שינה את השם של הפוד והמיכל ל-kube-scheduler-cron
ציין את השימוש ביציאות 10151 ו-10159 כפי שהוגדרה האפשרות hostNetwork: true ואיננו יכולים להשתמש באותן יציאות כמו ברירת המחדל של kube-scheduler (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-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) תהליך בחירת מנהיג (מאסטר) בין התרמילים של מתזמן ה-kube-scheduler שלנו באמצעות נקודת קצה אחת עבורם (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 מרכיב תחילה רשימה של צמתים אליהם ניתן לתזמן פוד בהתאם למדיניות 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 מופץ כעת באופן שווה על פני כל הצמתים. בהתחשב בכך שרוב משימות ה-cron מבוצעות באותם צמתים כמו היישומים העיקריים של הפרויקט, הדבר הפחית משמעותית את הסיכון להזזת פודים עקב מחסור במשאבים. לאחר הצגת ה-kube-scheduler הנוסף, כבר לא התעוררו בעיות בתזמון לא אחיד של משימות cron.

קרא גם מאמרים אחרים בבלוג שלנו:

מקור: www.habr.com

יצירת קובי-תזמון נוסף עם סט מותאם אישית של כללי תזמון