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

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

סקירה מרוכזת של כל השיטות המומלצות ל-GKE זמינה במאמר שיטות מומלצות ל-GKE.

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

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

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

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

בקטע הזה מתוארות הנחיות להתאמת המכסות של Google Cloudמשאבים שמשמשים עומסי עבודה ב-GKE. כדאי להתאים את המכסות לפרויקטים בהתאם להנחיות הבאות. במאמר הצגה וניהול של מכסות מוסבר איך משנים את המכסה דרך מסוף 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) מספר המעבדים שבהם נעשה שימוש בכל צמתי העובדים של כל האשכולות.
סוג המעבדים מספר המעבדים מכל סוג ספציפי שנעשה בהם שימוש בכל צמתי העובדים של כל האשכולות.
מכונות וירטואליות מספר כל צמתי העובדים. המיכסה הזו מחושבת באופן אוטומטי כ-10 פעמים מספר המעבדים.
מופעים לכל רשת VPC מספר כל צמתי העובדים שמחוברים לרשת ה-VPC.
standard persistent disk ‏ (GB) הגודל הכולל של דיסקים רגילים של אתחול מתמשך שמצורפים לכל צמתי העובדים.
דיסק מתמיד SSD ‏ (GB) הגודל הכולל של דיסקים קשיחים מסוג SSD שמשמשים לטעינת מערכת ההפעלה ומצורפים לכל צמתי העובדים.
אחסון SSD מקומי (GB) הגודל הכולל של דיסקים מקומיים מסוג SSD זמניים שמצורפים לכל צמתי העובדים.

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

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

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

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

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

  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,0�0.
בקשות קריאה של פעולות לדקה לכל אזור הקריאות האלה משמשות את 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 Standard תומכים בהרחבה של עד 65,000 צמתים. בהתאם למספר צמתי היעד, יש דרישות תשתית ספציפיות, ויכול להיות שתצטרכו לפנות ל-Cloud Customer Care. מידע מפורט זמין במאמר בנושא מגבלות ודרישות לגבי גודל האשכול.

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

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

מגבלה על מספר האשכולות שמשתמשים ב-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.

מה השלב הבא?