שיטות עבודה מומלצות של Kubernetes. הגדרת בקשות ומגבלות משאבים

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

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

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

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

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

כל מיכל בתרמיל יכול להגדיר שאילתות ומגבלות משלו, הכל תוסף. משאבי המעבד מוגדרים במילילייבות. אם המיכל שלך צריך שתי ליבות מלאות כדי לפעול, אתה מגדיר את הערך ל-2000 מ'. אם המיכל צריך רק את ההספק של 1/4 מהליבה, הערך יהיה 250 מ'. זכור שאם אתה מקצה ערך משאב CPU גדול ממספר הליבות של הצומת הגדול ביותר, הפוד שלך לא יתזמן להתחיל בכלל. מצב דומה יתרחש אם יש לך Pod שצריך ארבע ליבות, ואשכול Kubernetes מורכב משתי מכונות וירטואליות עיקריות בלבד.

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

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

משאבי זיכרון מוגדרים בבתים. בדרך כלל הערך בהגדרות נמדד ב-mebibytes Mib, אך ניתן להגדיר כל ערך, מ-bytes ועד petabytes. אותו מצב חל כאן כמו עם ה-CPU - אם אתה מציב בקשה לכמות זיכרון גדולה מכמות הזיכרון בצמתים שלך, הפוד הזה לא יתוזמן לביצוע. אבל בניגוד למשאבי CPU, הזיכרון אינו דחוס כי אין דרך להגביל את השימוש בו. לכן, ביצוע המכולה יופסק ברגע שהוא יחרוג מהזיכרון שהוקצה לו.

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

בעולם אידיאלי, הגדרות ברירת המחדל של המכולה יספיקו כדי לשמור על זרימות עבודה חלקות. אבל העולם האמיתי הוא לא כזה, אנשים יכולים בקלות לשכוח להגדיר את השימוש במשאבים, או שהאקרים יגדירו בקשות והגבלות החורגות מהיכולות האמיתיות של התשתית. כדי למנוע תרחישים כאלה להתרחש, אתה יכול להגדיר את מכסות המשאבים של ResourceQuota ו-LimitRange.

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

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

בואו נסתכל על כל אחד מהם. Requests.cpu הוא המספר המרבי של בקשות מעבד משולבות שיכולות להגיע מכל המכילים במרחב השמות. בדוגמה זו, אתה יכול לקבל 50 מכולות עם בקשות של 10 מ', חמש מכולות עם בקשות של 100 מ', או רק מיכל אחד עם בקשות של 500 מ'. כל עוד המספר הכולל של requests.cpu של מרחב שמות נתון הוא פחות מ-500 מ', הכל יהיה בסדר.

Memory requested requests.memory הוא הכמות המקסימלית של בקשות זיכרון משולבות שיכולות להיות לכל המכילים במרחב השמות. כמו במקרה הקודם, אתה יכול לקבל 50 מיכלים של 2 מ"ב, חמישה מכולות של 20 מ"ב או קונטיינר בודד של 100 מ"ב כל עוד כמות הזיכרון הכוללת המבוקשת במרחב השמות היא פחות מ-100 מבייט.

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

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

טווח המגבלה מספק הגבלות שיכולות:

• הבטח שימוש מינימלי ומקסימלי במשאבי מחשוב עבור כל מודול או מיכל במרחב השמות;
• לאכוף מינימום ומקסימום בקשות אחסון Starage Request עבור כל PersistentVolumeClaim במרחב השמות;
• לאכוף קשר בין בקשה למגבלה עבור משאב במרחב שמות;
• הגדר בקשות/מגבלות ברירת מחדל עבור משאבי מחשוב במרחב השמות והחדר אותם אוטומטית למכולות בזמן ריצה.

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

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

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

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

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

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

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

Kubernetes יבדוק אם ל-Node 1 יש מספיק משאבים למילוי בקשות ממכולות הפוד, ואם לא, הוא יעבור לצומת הבא. אם אף אחד מהצמתים במערכת אינו מסוגל לספק את הבקשות, הפודים יעברו למצב Pending. באמצעות תכונות מנוע Google Kubernetes כגון קנה מידה אוטומטי של צמתים, GKE יכול לזהות אוטומטית את מצב ההמתנה וליצור עוד מספר צמתים נוספים.

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

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

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

בואו נדמיין תרחיש שבו יש לך מכונה שנגמר לו הזיכרון - איך Kubernetes יתמודד עם זה?

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

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

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

שיטות עבודה מומלצות של Kubernetes. כיבוי נכון סיום

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com