תכנון לעומסי עבודה גדולים

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

שיטות מומלצות להפצת עומסי עבודה ב-GKE בין כמה Google Cloud פרויקטים

כדי להגדיר בצורה טובה יותר את מבנה הפרויקט ואת חלוקת עומסי העבודה ב-GKE, בהתאם לדרישות העסקיות שלכם, מומלץ לבצע את פעולות התכנון והעיצוב הבאות: Google Cloud

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

שיטות מומלצות להתאמת מכסות לעומסי עבודה גדולים ב-GKE

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

מכסות ושיטות מומלצות לשימוש ב-Compute Engine

אשכולות GKE שפועלים במצב Autopilot ובמצב רגיל משתמשים במשאבי Compute Engine כדי להריץ את עומסי העבודה. בניגוד למשאבי מישור הבקרה של Kubernetes שמנוהלים באופן פנימי על ידי Google Cloud, אתם יכולים לנהל ולהעריך את המכסות של Compute Engine שבהן משתמשים תהליכי העבודה שלכם.

מכסות של Compute Engine, גם למשאבים וגם לממשקי API, משותפות לכל אשכולות GKE שמארחים באותו פרויקט ובאותו אזור. אותן מכסות משותפות גם למשאבים אחרים של Compute Engine (שלא קשורים ל-GKE), כמו מכונות וירטואליות עצמאיות או קבוצות של מופעים.

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

מכסות של משאבי Compute Engine שמשמשים את צמתי העובדים של GKE

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

מכסת משאבים תיאור
מעבדים (CPU) מספר יחידות העיבוד המרכזיות (CPU) שבהן נעשה שימוש בכל צמתי העובדים של כל האשכולות.
סוג המעבדים מספר המעבדים מכל סוג ספציפי שמשמשים את כל צמתי העובדים בכל האשכולות.
מכונות וירטואליות מספר כל צמתי העובדים. המכסה הזה מחושב אוטומטית כמספר המעבדים כפול 10.
מופעים לכל רשת VPC מספר כל צמתי העובדים שמחוברים לרשת ה-VPC.
standard persistent disk ‏ (GB) הגודל הכולל של דיסקים רגילים של אתחול מתמשך שמצורפים לכל צמתי העובדים.
‫Persistent Disk SSD (GB) הגודל הכולל של דיסקים קשיחים מסוג SSD persistent boot disks שמצורפים לכל צמתי העובדים.
אחסון SSD מקומי (GB) הגודל הכולל של דיסקים מקומיים מסוג SSD זמניים שמצורפים לכל צמתי העובדים.

חשוב גם להתאים את המכסות שמשמשות משאבים שעשויים להידרש לעומס העבודה, כמו מעבדי GPU, כתובות IP או משאבים שניתנים להפסקת פעולה.

מכסות לקריאות ל-Compute Engine API

באשכולות גדולים או באשכולות שניתנים להרחבה נדרש מספר גבוה יותר של קריאות ל-Compute Engine API. ‫GKE מבצע את הקריאות האלה ל-Compute Engine API במהלך פעילויות כמו:

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

כשמתכננים את ארכיטקטורת האשכולות הגדולים, מומלץ:

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

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

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

בפרויקטים ובאזורים עם כמה מאות צמתים דינמיים, צריך לשנות את הערך הזה ל-3,500.

בפרויקטים ובאזורים עם כמה אלפי צמתים דינמיים מאוד, כדאי לשנות את הערך הזה ל-6,000.
בקשות קריאה לדקה לכל אזור ‫GKE משתמש בקריאות האלה כדי לעקוב אחרי המצב של מכונות וירטואליות (צמתים).

בפרויקטים ובאזורים עם כמה מאות צמתים, כדאי לשנות את הערך הזה ל-12,000.

בפרויקטים ובאזורים עם אלפי צמתים, צריך לשנות את הערך הזה ל-20,000.
רשימת בקשות לדקה לכל אזור ‫GKE משתמש בקריאות האלה כדי לעקוב אחרי המצב של קבוצות המכונות (מאגרי הצמתים).

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

בפרויקטים ובאזורים עם אלפי צמתים דינמיים מאוד, בכמה מאגרי צמתים, צריך לשנות את הערך הזה ל-2,500.
Instance List Referrer requests per minute per region ‫GKE משתמש בקריאות האלה כדי לקבל מידע על מופעי מכונות וירטואליות (צמתים) שפועלים.

בפרויקטים ובאזורים עם אלפי צמתים דינמיים מאוד, כדאי לשנות את הערך הזה ל-6,000.
בקשות קריאה של פעולות לדקה לכל אזור הקריאות האלה משמשות את GKE כדי לקבל מידע על פעולות מתמשכות של Compute Engine API.

בפרויקטים ובאזורים עם אלפי צמתים דינמיים מאוד, כדאי לשנות את הערך הזה ל-3,000.

מכסות ושיטות מומלצות לשימוש ב-Cloud Logging API וב-Cloud Monitoring API

בהתאם להגדרת האשכול, עומסי עבודה גדולים שפועלים באשכולות GKE עשויים ליצור נפח גדול של מידע אבחוני. כשחורגים מהמכסות של Cloud Logging API או Cloud Monitoring API, יכול להיות שנתוני הרישום והמעקב יאבדו. מומלץ להגדיר את רמת הפירוט של היומנים ולשנות את מכסות Cloud Logging API ו-Cloud Monitoring API כדי לתעד את המידע הדיאגנוסטי שנוצר. השירות המנוהל ל-Prometheus צורך מכסות של Cloud Monitoring.

כל עומס עבודה שונה, ולכן מומלץ לבצע את הפעולות הבאות:

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

בטבלה הבאה מפורטות המכסות לקריאות ל-Cloud Logging API ול-Cloud Monitoring API. המכסות האלה מוגדרות לכל פרויקט, ומשותפות לכל אשכולות GKE שמתארחים באותו פרויקט.

שירות מכסה תיאור שיטות מומלצות
Cloud Logging API בקשות כתיבה לדקה ‫GKE משתמש במכסת הנתונים הזו כשמוסיפים רשומות לקובצי יומן שמאוחסנים ב-Cloud Logging.

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

מידע נוסף זמין במאמר בנושא ניהול יומנים ב-GKE.
Cloud Monitoring API בקשות להוספת נתונים של סדרות זמן לדקה

‫GKE משתמש במכסה הזו כששולח מדדי Prometheus ל-Cloud Monitoring:

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

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

מידע נוסף זמין במאמר בנושא ניהול מדדים של GKE.

מכסת הצמתים ב-GKE ושיטות מומלצות

‫GKE תומך במגבלות הבאות:

  • עד 15,000 צמתים באותו אשכול, עם מכסת ברירת מחדל של 5,000 צמתים. המכסה הזו מוגדרת בנפרד לכל אשכול GKE, ולא לכל פרויקט כמו מכסות אחרות.
  • בגרסה 1.31 ואילך, ‏ GKE תומך באשכולות גדולים של עד 65,000 צמתים.

אם אתם מתכננים להגדיל את האשכול מעל 5,000 צמתים, אתם צריכים לבצע את השלבים הבאים:

  1. מזהים את האשכול שרוצים להגדיל את מספר הצמתים שלו מעבר ל-5,000.
  2. חשוב לוודא שעומס העבודה נשאר במסגרת המגבלות של האשכול והמכסות של GKE אחרי ההתאמה.
  3. חשוב להגדיל את המכסות של Compute Engine בהתאם לצורך בעומס העבודה המוגדל.
  4. מוודאים שסוג הזמינות של האשכול הוא אזורי ושהאשכול משתמש ב-Private Service Connect.
  5. כדי לבקש הגדלה של המכסה למספר הצמתים בכל אשכול, פונים ל-Cloud Customer Care. צוות GKE ייצור איתכם קשר כדי לוודא שעומס העבודה שלכם עומד בשיטות המומלצות בנושא יכולת הרחבה, ומוכן להתרחבות מעבר ל-5,000 צמתים באותו אשכול.

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

מגבלה על מספר האשכולות שמשתמשים ב-VPC Network Peering לכל רשת ולכל מיקום

אפשר ליצור עד 75 אשכולות שמשתמשים בקישור בין רשתות שכנות (peering) של VPC באותה רשת VPC לכל מיקום (אזורים ומיקומים גיאוגרפיים נחשבים למיקומים נפרדים). ניסיונות ליצור אשכולות נוספים מעבר למגבלה ייכשלו עם שגיאה דומה לזו:

CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.

באשכולות GKE עם צמתים פרטיים שנוצרו לפני גרסה 1.29, נעשה שימוש ב-VPC Network Peering כדי לספק תקשורת פנימית בין שרת Kubernetes API (בניהול Google) לבין צמתים פרטיים שיש להם רק כתובות פנימיות.

כדי לפתור את הבעיה הזו, אפשר להשתמש באשכולות שמשתמשים בקישוריות של Private Service Connect ‏ (PSC). אשכולות עם קישוריות PSC מספקים את אותו בידוד כמו אשכול שמשתמש ב-VPC Network Peering, בלי ההגבלה של 75 אשכולות. באשכולות עם קישוריות PSC לא נעשה שימוש בקישור בין רשתות VPC שכנות, והם לא מושפעים מהמגבלה על מספר הקישורים בין רשתות VPC שכנות.

אפשר להשתמש בהוראות שמופיעות במאמר בנושא שימוש חוזר בקישור בין רשתות VPC שכנות (peering) כדי לזהות אם האשכולות שלכם משתמשים בקישור בין רשתות VPC שכנות.

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

  1. מוודאים שהאשכול משתמש ב-PSC.
  2. מגדירים את הבידוד של מאגרי הצמתים כך שיהפכו לפרטיים באמצעות הפרמטר enable-private-nodes לכל מאגר צמתים.
  3. אם רוצים, אפשר להגדיר את הבידוד של מישור הבקרה באמצעות הפרמטר enable-private-endpoint ברמת האשכול. מידע נוסף זמין במאמר בנושא התאמה אישית של בידוד הרשת.

אפשר גם לפנות ל Google Cloud צוות התמיכה כדי להגדיל את המגבלה של 75 אשכולות באמצעות קישור בין רשתות שכנות (peering) של VPC. בקשות כאלה נבדקות על בסיס כל מקרה לגופו, ואם אפשר להגדיל את המגבלה, היא מוגדלת בספרה אחת.

אופטימיזציה של מדרגיות ואמינות באמצעות HTTP/2

כדי להריץ עומסי עבודה גדולים ב-GKE, צריך להשתמש ב-HTTP/2 במקום ב-HTTP/1.1. פרוטוקול HTTP/2 משפר את הביצועים ואת מהימנות החיבור בסביבות עם תנועה גבוהה או חביון גבוה.

היתרונות של HTTP/2

  • צמצום מספר החיבורים: פרוטוקול HTTP/2 מאפשר לשלוח הרבה בקשות ולקבל הרבה תגובות דרך חיבור אחד. כך מצטמצם העומס על רכיבי המערכת כמו מאזני עומסים, שרתי proxy ושערי NAT.

  • שיפור העקביות בביצועים: ב-HTTP/1.1, בדרך כלל כל בקשה צריכה חיבור משלה. אם יש בעיות בחיבור אחד, הוא עלול לעכב את הבקשה או לגרום לביטול שלה. לדוגמה, אם חיבור TCP אחד מפיל מנות או חווה השהיה גבוהה, יכול להיות שזה ישפיע על כל הבקשות שמתבצעות בחיבור הזה, וזה עלול לגרום לעיכובים או לשגיאות באפליקציה. ב-HTTP/2, כמה בקשות חולקות את אותו חיבור, ולכן בעיות ברשת משפיעות על כל הבקשות באותו אופן, מה שהופך את הביצועים לצפויים יותר.

  • כולל תכונות מובנות לשמירה על חיבורים אמינים:

    • בקרה על זרימת נתונים: בקרה על זרימת נתונים עוזרת לנהל את כמות הנתונים שנשלחים בכל פעם. הוא מונע משולחים להציף את הנמענים ועוזר למנוע עומס ברשת.

    • מסגרות פינג: מסגרות פינג הן אותות קלים שבודקים אם החיבור עדיין פעיל. האותות האלה עוזרים לשמור על חיבורים קבועים ולמנוע ניתוקים שנגרמים על ידי מערכות ביניים (כמו חומות אש או שרתי proxy) שעלולות לסגור חיבורים בלי פעילות.

      ב-HTTP/1.1, החיבורים יכולים להתנתק באופן לא צפוי אם לא מתבצעת תנועה במשך תקופה מסוימת. המצב הזה נפוץ במיוחד כשחומות אש או שרתי proxy סוגרים חיבורים בלי פעילות כדי לפנות משאבים. ב-HTTP/2, פריימים של פינג שומרים על החיבורים פעילים על ידי בדיקה קבועה של סטטוס החיבור.

    • Multiplexing: ב-HTTP/1.1, כששולחים כמה בקשות בו-זמנית באמצעות חיבורים נפרדים, הסדר שבו מתקבלות התשובות עלול לגרום לבעיות אם בקשה אחת תלויה בבקשה אחרת. לדוגמה, אם בקשה אחת מסתיימת ראשונה אבל לבקשה אחרת יש עיכוב ברשת, התוצאה יכולה להיות תגובה שגויה או לא מסודרת. הבעיה הזו עלולה לגרום למרוץ תהליכים. פרוטוקול HTTP/2 מונע את זה באמצעות ריבוב של כל הבקשות בחיבור יחיד, וכך עוזר לוודא שהתשובות מיושרות בצורה נכונה.

שיטות מומלצות לשימוש ב-HTTP/2

  • מומלץ להשתמש ב-HTTP/2 לאפליקציות שמטפלות בנפח תנועה גבוה או שזקוקות לתקשורת עם השהיה נמוכה.
  • כדי שהחיבורים יישארו פתוחים, צריך להגדיר keepalives ברמת האפליקציה. איך פועלים הקישורים?
  • כדאי לעקוב אחרי התנועה כדי לוודא שהיא משתמשת ב-HTTP/2.

מידע נוסף מופיע במאמר תמיכה ב-HTTP/2 ב-Cloud Load Balancing.

מה השלב הבא?