כיצד לגשת למשאבי Kubernetes Pod

הפרס מאת Tohad

כאשר מתחילים עם Kubernetes, נפוץ לשכוח מהגדרת משאבי מיכל. בשלב זה, זה מספיק כדי להבטיח שתמונת Docker עובדת וניתן לפרוס אותה באשכול Kubernetes.

אבל מאוחר יותר יש לפרוס את האפליקציה באשכול ייצור יחד עם יישומים אחרים. לשם כך צריך להקצות משאבים לקונטיינר ולוודא שיש מספיק מהם כדי להפעיל את האפליקציה, ושאפליקציות פועלות אחרות לא יתקלו בבעיות.

קבוצה Kubernetes aaS מ-Mail.ru תרגם מאמר על משאבי מיכל (CPU & MEM), בקשות ומגבלות משאבים. תלמד את היתרונות של הגדרות אלה ומה קורה אם לא תגדיר אותן.

משאבי מחשוב

יש לנו שני סוגים של משאבים עם היחידות הבאות:

• יחידת עיבוד מרכזית (CPU) - ליבות;
• זיכרון (MEM) - בתים.

משאבים מצוינים עבור כל מיכל. בקובץ Pod YAML הבא, תראה קטע משאבים המכיל את המשאבים המבוקשים והמגבילים:

• משאבי פוד מבוקשים = סכום המשאבים המבוקשים של כל הקונטיינרים;
• מגבלת משאבי הפוד = סכום כל מגבלות המשאבים של הפוד.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

דוגמה למשאבים מבוקשים ומוגבלים

שדה resources.requested מהמפרט Pod הוא אחד האלמנטים המשמשים למציאת הצומת הרצוי. אתה כבר יכול לתכנן עבורו פריסת Pod. איך מוצאים צומת מתאים?

Kubernetes מורכב ממספר רכיבים, כולל צומת מאסטר או צומת מאסטר (Kubernetes Control Plane). לצומת הראשי יש מספר תהליכים: kube-apiserver, kube-controller-manager ו-kube-scheduler.

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

היכן ימוקם התרמיל הסגול?

בתמונה ניתן לראות ש-kube-scheduler אמור לתזמן פוד סגול חדש. אשכול Kubernetes מכיל שני צמתים: A ו-B. כפי שאתה יכול לראות, kube-scheduler לא יכול לתזמן Pod בצומת A - המשאבים הזמינים (הלא מתבקשים) אינם תואמים לבקשות של הפוד הסגול. לכן, 1 GB של זיכרון המבוקש על ידי Pod הסגול לא יתאים לצומת A, מכיוון שהזיכרון הזמין הוא 0,5 GB. אבל לצומת B יש מספיק משאבים. כתוצאה מכך, kube-scheduler מחליט שהיעד של הפוד הסגול הוא צומת B.

כעת אנו יודעים כיצד המשאבים המבוקשים משפיעים על בחירת הצומת להפעלת הפוד. אבל מה ההשפעה של משאבים שוליים?

מגבלת המשאבים היא גבול שה-CPU/MEM אינו יכול לחצות. עם זאת, משאב ה-CPU גמיש, כך שמיכלים שיגיעו למגבלות ה-CPU שלהם לא יגרמו לפוד לצאת. במקום זאת, הצערת המעבד תתחיל. אם תגיע למגבלת השימוש ב-MEM, המכולה יופסק עקב OOM-Killer ויופעל מחדש אם מותר על ידי הגדרת RestartPolicy.

משאבים מבוקשים ומקסימום בפירוט

תקשורת משאבים בין Docker ל-Kubernetes

הדרך הטובה ביותר להסביר כיצד בקשות משאבים ומגבלות משאבים פועלות היא להציג את הקשר בין Kubernetes ל-Docker. בתמונה למעלה תוכלו לראות כיצד שדות Kubernetes ודגלי ההפעלה של Docker קשורים זה לזה.

זיכרון: בקשה והגבלה

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

כפי שהוזכר לעיל, הזיכרון נמדד בבייטים. מבוסס על תיעוד Kubernetes, נוכל לציין זיכרון כמספר. בדרך כלל זה מספר שלם, למשל 2678 - כלומר 2678 בתים. אתה יכול גם להשתמש בסיומות G и Gi, העיקר לזכור שהם לא שווים. הראשון הוא עשרוני והשני הוא בינארי. כמו הדוגמה שהוזכרה בתיעוד k8s: 128974848, 129e6, 129M, 123Mi - הם כמעט שוות ערך.

אפשרות Kubernetes limits.memory תואם את הדגל --memory מ-Docker. במקרה request.memory אין חץ עבור Docker כי Docker אינו משתמש בשדה זה. אתה יכול לשאול, האם זה בכלל הכרחי? כן צריך. כפי שאמרתי קודם, התחום חשוב עבור Kubernetes. בהתבסס על המידע ממנו, kube-scheduler מחליט באיזה צומת לתזמן את הפוד.

מה קורה אם אתה מגדיר לא מספיק זיכרון לבקשה?

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

מה קורה אם מגדירים את מגבלת הזיכרון נמוכה מדי?

אם המיכל חורג ממגבלת הזיכרון, הוא יופסק עקב OOM-Killed. ויפעיל מחדש אם אפשר בהתבסס על RestartPolicy שבו ערך ברירת המחדל הוא Always.

מה קורה אם לא תציין את הזיכרון המבוקש?

Kubernetes ייקח את ערך הגבול ותגדיר אותו כערך ברירת המחדל.

מה יכול לקרות אם לא תציין מגבלת זיכרון?

למיכל אין הגבלות; הוא יכול להשתמש בכמות הזיכרון שהוא רוצה. אם הוא יתחיל להשתמש בכל הזיכרון הזמין של הצומת, אז OOM יהרוג אותו. לאחר מכן, המיכל יופעל מחדש במידת האפשר בהתבסס על RestartPolicy.

מה קורה אם לא מציינים מגבלות זיכרון?

זהו התרחיש הגרוע ביותר: המתזמן לא יודע כמה משאבים המיכל דורש, וזה יכול לגרום לבעיות רציניות בצומת. במקרה זה, זה יהיה נחמד לקבל מגבלות ברירת מחדל על מרחב השמות (שנקבע על ידי LimitRange). אין מגבלות ברירת מחדל - לפוד אין מגבלות, הוא יכול להשתמש בכמה זיכרון שהוא רוצה.

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

בדרך כלל מומלץ להגדיר את אותו ערך עבור request.memory и limit.memory. זה מבטיח ש-Kubernetes לא יתזמן Pod בצומת שיש לו מספיק זיכרון כדי להפעיל את הפוד אבל לא מספיק כדי להפעיל אותו. זכור: תכנון Pod Kubernetes לוקח בחשבון רק requests.memoryו - limits.memory לא לוקח בחשבון.

CPU: בקשה והגבלה

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

עם מעבד הכל קצת יותר מסובך. אם נחזור לתמונה של מערכת היחסים בין Kubernetes ל-Docker, אתה יכול לראות את זה request.cpu מתאים --cpu-shares, ואילו limit.cpu תואם את הדגל cpus ב-Docker.

המעבד שמבקש Kubernetes מוכפל ב-1024, השיעור של מחזורי המעבד. אם אתה רוצה לבקש ליבה אחת מלאה, עליך להוסיף cpu: 1כפי שמוצג לעיל.

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

בקשת CPU - מערכת ליבה אחת

בואו נדמיין שיש לכם מערכת מארח עם ליבה אחת שמפעילה קונטיינרים. אמא (Kubernetes) אפתה פשטידה (CPU) ורוצה לחלק אותה בין ילדים (מכולות). שלושה ילדים רוצים פשטידה שלמה (פרופורציה = 1024), ילד אחר רוצה חצי פשטידה (512). אמא רוצה להיות הוגנת ועושה חישוב פשוט.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

לפי החישוב, שלושה ילדים יקבלו 28% מהליבה, ולא את כל הליבה. הילד הרביעי יקבל 14% מהגרעין המלא, לא חצי. אבל הדברים יהיו שונים אם יש לך מערכת מרובת ליבות.

בקשת מעבד - מערכת מרובת ליבות (4).

בתמונה למעלה ניתן לראות ששלושה ילדים רוצים פשטידה שלמה, ואחד רוצה חצי. מכיוון שאמא אפתה ארבע פשטידות, כל אחד מילדיה יקבל כמה שירצה. במערכת מרובת ליבות, משאבי המעבד מחולקים על פני כל ליבות המעבד הזמינות. אם מיכל מוגבל לפחות מליבת מעבד אחת מלאה, הוא עדיין יכול להשתמש בו ב-100%.

החישובים שלעיל מפושטים כדי להבין כיצד המעבד מחולק בין מיכלים. כמובן, מלבד הקונטיינרים עצמם, ישנם תהליכים נוספים שמשתמשים גם במשאבי CPU. כאשר תהליכים במיכל אחד אינם פעילים, אחרים יכולים להשתמש במשאב שלו. CPU: "200m" מתאים CPU: 0,2, כלומר בערך 20% מליבה אחת.

עכשיו בואו נדבר על limit.cpu. המעבד ש-Kubernetes מגביל מוכפל ב-100. התוצאה היא משך הזמן שהמיכל יכול להשתמש בכל 100 µs (cpu-period).

limit.cpu תואם את דגל Docker --cpus. זהו שילוב חדש של ישן --cpu-period и --cpu-quota. על ידי הגדרתו, אנו מציינים כמה משאבי מעבד זמינים המיכל יכול להשתמש בצורה מקסימלית לפני תחילת המצערת:

• מעבד - שילוב cpu-period и cpu-quota. cpus = 1.5 שווה ערך להגדרה cpu-period = 100000 и cpu-quota = 150000;
• תקופת המעבד - פרק זמן מתזמן CPU CFS, ברירת מחדל 100 מיקרו שניות;
• מכסת מעבד - מספר מיקרו-שניות בפנים cpu-period, אשר תחום על ידי המיכל.

מה קורה אם אתה מתקין לא מספיק מעבד מבוקש?

אם המיכל צריך יותר ממה שהותקן, הוא יגנוב מעבד מתהליכים אחרים.

מה קורה אם מגדירים את מגבלת המעבד נמוך מדי?

מאחר ומשאב ה-CPU ניתן להתאמה, המצערת תופעל.

מה קורה אם לא תציין בקשת מעבד?

כמו בזיכרון, ערך הבקשה שווה לגבול.

מה קורה אם לא מציינים מגבלת מעבד?

המיכל ישתמש בכמות המעבד הדרושה לו. אם מדיניות ברירת מחדל של CPU (LimitRange) מוגדרת במרחב השמות, מגבלה זו משמשת גם עבור המיכל.

מה קורה אם לא תציין בקשה או מגבלת מעבד?

כמו בזיכרון, זה התרחיש הגרוע ביותר. המתזמן לא יודע כמה משאבים המיכל שלך צריך, וזה יכול לגרום לבעיות רציניות בצומת. כדי להימנע מכך, עליך להגדיר מגבלות ברירת מחדל עבור מרחבי שמות (LimitRange).

זכור: אם אתה מבקש יותר CPU ממה שהצמתים יכולים לספק, הפוד לא יתוזמן. Requests.cpu - לא הערך המינימלי, אלא ערך מספיק כדי להפעיל את הפוד ולעבוד ללא תקלות. אם האפליקציה לא מבצעת חישובים מורכבים, האפשרות הטובה ביותר היא להתקין request.cpu <= 1 ולהפעיל כמה העתקים שצריך.

כמות אידיאלית של משאבים מבוקשים או מגבלת משאבים

למדנו על המגבלה של משאבי מחשוב. עכשיו הגיע הזמן לענות על השאלה: "כמה משאבים צריך הפוד שלי כדי להפעיל את האפליקציה ללא בעיות? מהי הכמות האידיאלית?

למרבה הצער, אין תשובות ברורות לשאלות אלו. אם אינך יודע כיצד היישום שלך עובד או כמה מעבד או זיכרון הוא צריך, האפשרות הטובה ביותר היא לתת ליישום הרבה זיכרון ומעבד ולאחר מכן להריץ מבחני ביצועים.

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

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

מסקנה

בקשה והגבלת משאבים עוזרת לשמור על בריאות אשכול Kubernetes שלך. תצורת מגבלה נכונה ממזערת עלויות ושומרת על יישומים פועלים בכל עת.

בקיצור, יש כמה דברים שכדאי לזכור:

1. המשאבים המבוקשים הם תצורה שנלקחת בחשבון בזמן ההפעלה (כאשר Kubernetes מתכננת לארח את האפליקציה). לעומת זאת, הגבלת משאבים חשובה בזמן ריצה - כאשר האפליקציה כבר פועלת על הצומת.
2. בהשוואה לזיכרון, המעבד הוא משאב מוסדר. אם אין מספיק מעבד, הפוד שלך לא יכבה ומנגנון המצערת יופעל.
3. המשאבים המבוקשים ומגבלת המשאבים אינם ערכי מינימום ומקסימום! על ידי הגדרת המשאבים המבוקשים, אתה מבטיח שהאפליקציה תפעל ללא בעיות.
4. תרגול טוב הוא להגדיר את בקשת הזיכרון שווה למגבלת הזיכרון.
5. התבקשה התקנה בסדר CPU <=1, אם האפליקציה לא מבצעת חישובים מורכבים.
6. אם תבקש יותר משאבים ממה שזמינים בצומת, הפוד לעולם לא יתזמן לצומת זה.
7. כדי לקבוע את הכמות הנכונה של מגבלות המשאבים/משאבים המבוקשים, השתמש בבדיקת עומס ובניטור.

אני מקווה שמאמר זה יעזור לך להבין את הרעיון הבסיסי של הגבלת משאבים. ותוכל ליישם את הידע הזה בעבודתך.

מזל טוב!

מה עוד לקרוא:

1. צפיות SRE: מרחבי שמות ומבנה מטרי.
2. 90+ כלים שימושיים עבור Kubernetes: פריסה, ניהול, ניטור, אבטחה ועוד.
3. הערוץ שלנו Around Kubernetes בטלגרם.

מקור: www.habr.com