שיטות מומלצות לתכנון אשכולות GKE גדולים

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

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

למה כדאי לתכנן אשכולות GKE גדולים

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

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

כש-GKE משנה את גודל האשכול למספר גדול של צמתים, הוא מנסה לשנות את כמות המשאבים הזמינה כך שתתאים לצרכים של המערכת, תוך שמירה על היעדים למדידת רמת השירות (SLO) שלו. ‫Cloud de Confiance by S3NS תומך באשכולות גדולים. עם זאת, בהתאם לתרחיש השימוש, חשוב לקחת בחשבון את המגבלות של אשכולות גדולים כדי לתת מענה טוב יותר לדרישות שלכם לגבי גודל התשתית.

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

שיקולים כלליים לגבי העברת אשכולות

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

  • כדי להעביר אשכולות רגילים לפי תחום לאשכולות רגילים לפי אזור, צריך ליצור מחדש את האשכול כדי לקבל גישה למכסות גבוהות יותר של צמתים.
  • כדי לעבור לאשכולות שמשתמשים ב-Private Service Connect, צריך ליצור מחדש את האשכול כדי לגשת למכסת הצמתים הגבוהה יותר.

מגבלות ודרישות לגבי גודל האשכול

בטבלה הבאה מפורטות מגבלות ודרישות של GKE לגבי שינוי גודל, על סמך מספר צמתי היעד:

מגבלת הצמתים דרישות התשתית דרישות רשת הגבלות גישה דוגמאות לתרחישי שימוש
עד 1,000 זמין לכל האשכולות. אין דרישות נוספות. אין. ההגדלה של מספר הצמתים עד 1,000 היא אוטומטית. עומסי עבודה כלליים, פיתוח ובדיקות.
‫1,000 עד 5,000 האפשרות זמינה לאשכולות אזוריים מסוג Standard ולאשכולות מסוג Autopilot. אין. אם אתם עומדים בדרישות האחרות, המערכת תגדיל את מספר הצמתים ל-5,000 באופן אוטומטי. עבודות בנפח גבוה עם משך חיים קצר ושירותים לארגונים.
‫5,000 עד 15,000
  • האפשרות זמינה רק לאשכולות אזוריים רגילים.
  • כדי ליהנות משיפורים בביצועים של שינוי גודל של אשכולות גדולים, מומלץ להשתמש ב-GKE בגרסה 1.36 ואילך.
 כדי להגדיל את גודל האשכול ואת מכסת המגבלה, פונים ל-Cloud Customer Care. עומסי עבודה של HPC ועיבוד נתונים.
‫15,000 עד 65,000 כדי לבקש הגדלה של המכסות ולקבל עזרה בהגדלת המגבלות, פונים אל Cloud Customer Care. אימון מודלים גדולים.

שיטות מומלצות לפיצול עומסי עבודה בין כמה אשכולות

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

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

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

מגבלות ושיטות מומלצות

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

השיטות המומלצות האלה חלות על כל אשכול Kubernetes שמוגדר כברירת מחדל ושלא מותקנות בו תוספים. הרחבת אשכולות Kubernetes באמצעות ווּבְּהוּקים או הגדרות מותאמות אישית של משאבים (CRD) היא פעולה נפוצה, אבל היא עלולה להגביל את היכולת שלכם לשנות את גודל האשכול.

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

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

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

כדי לעקוב אחרי השימוש, אפשר להיעזר במקורות המידע הבאים:

  • כדי לראות את השימוש הנוכחי, עוברים אל הדף Quotas כדי לראות רשימה של מכסות GKE שסוננה מראש.
  • אפשר להשתמש בתובנות והמלצות כדי לקבל התראות לגבי אשכולות ברמת צריכה של 80%, 90% ו-95%.

מידע נוסף על דרכי פעולה כשמתקרבים למגבלה זמין במאמר זיהוי אשכולות שבהם השימוש ב-etcd מתקרב למגבלה.
הגודל הכולל של אובייקטים מסוג etcd לכל סוג הגודל הכולל של כל האובייקטים מסוג המשאב הנתון לא יכול לחרוג מ-800 MB. לדוגמה, אפשר ליצור 750 MB של מופעי Pod ו-750 MB של Secrets, אבל אי אפשר ליצור 850 MB של Secrets. אם תיצרו אובייקטים בגודל של יותר מ-800 MB, יכול להיות שהבקרי Kubernetes או הבקרים המותאמים אישית לא יאותחלו וייגרמו שיבושים.

הגודל הכולל של כל האובייקטים מכל סוג שמאוחסנים ב-etcd צריך להיות מתחת ל-800 MB. האפשרות הזו רלוונטית במיוחד לאשכולות שמשתמשים בהרבה סודות או ConfigMap בגודל גדול, או בכמות גדולה של CRD.
מספר השירותים באשכולות שבהם GKE Dataplane V2 לא מופעל הביצועים של iptables שמשמש את kube-proxy יורדים אם מתרחש אחד מהמקרים הבאים:
  • יש יותר מדי שירותים.
  • מספר הקצה העורפי מאחורי שירות גבוה.

המגבלה הזו לא קיימת כשמופעל GKE Dataplane V2.

מספר השירותים באשכול צריך להיות מתחת ל-10,000.

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

מספר השירותים בכל מרחב שמות צריך להיות מתחת ל-5,000.

אתם יכולים לבחור שלא לאכלס את משתני הסביבה האלה. במסמכי התיעוד מוסבר איך להגדיר את enableServiceLinks ב-PodSpec כ-false.

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

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

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

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

מספר ה-Pods שמאחורי שירות יחיד צריך להיות נמוך מ-10,000.

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

מספר ה-Pods שמאחורי שירות יחיד באשכולות שבהם מופעל GKE Dataplane V2

‫GKE Dataplane V2 כולל מגבלות על מספר ה-Pods שנחשפים על ידי Service יחיד.

אותה מגבלה חלה על אשכולות Autopilot כי הם משתמשים ב-GKE Dataplane V2.

ב-GKE 1.23 ובגרסאות קודמות, כדאי להקפיד שמספר ה-Pods שמאחורי Service יחיד יהיה נמוך מ-1,000.

ב-GKE 1.24 ואילך, מומלץ לשמור על מספר נמוך מ-10,000 של Pods מאחורי Service יחיד.

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

מספר רשומות ה-DNS לכל שירות Headless מוגבל גם ב-kube-dns וגם ב-Cloud DNS.

מספר רשומות ה-DNS לכל שירות headless צריך להיות מתחת ל-1,000 עבור kube-dns ומתחת ל-3,500/2,000 (IPv4/IPv6) עבור Cloud DNS.
מספר כל נקודות הקצה של השירות מספר נקודות הקצה בכל השירותים עשוי להגיע למגבלות. הפעולה הזו עלולה להגדיל את זמן האחזור של התכנות או לגרום לכך שלא תהיה אפשרות לתכנת נקודות קצה חדשות בכלל.

מספר נקודות הקצה בכל השירותים צריך להיות מתחת ל-260,000.

‫GKE Dataplane V2, שהוא מישור הנתונים שמוגדר כברירת מחדל ב-GKE Autopilot, מסתמך על מיפוי eBPF שמוגבל כרגע ל-260,000 נקודות קצה בכל השירותים.
מספר האובייקטים של HorizontalPodAutoscaler בכל אשכול

כל HorizontalPodAutoscaler (HPA) עובר עיבוד כל 15 שניות.

כברירת מחדל, GKE תומך בעד 300 אובייקטים של HPA. כדי להגדיל את המגבלות, פרופיל הביצועים של HPA מגדיל את התמיכה ל-1,000 אובייקטים של HPA בגרסה 1.31 ואילך, ועד 5,000 אובייקטים של HPA בגרסה 1.33 ואילך. חריגה מהמגבלות האלה עלולה לגרום לירידה ליניארית בביצועים.

חשוב לשמור על מספר האובייקטים של HPA במסגרת המגבלה הנתמכת של הפרופיל של האשכול (300, 1,000 או 5,000 אובייקטים). אחרת, יכול להיות שתחוו ירידה ליניארית בתדירות העיבוד של HPA. לדוגמה, אם יש 2,000 רכיבי HPA עם הגדרות רגילות, כל רכיב HPA יעבור עיבוד מחדש רק פעם אחת בכל דקה ו-40 שניות.

מידע נוסף זמין במאמרים התאמת גודל אוטומטית על סמך ניצול משאבים, התאמה אוטומטית של קבוצות Pod לעומס (HPA) והגדרת פרופיל הביצועים של HPA.
מספר ה-Pods בכל צומת ב-GKE יש מגבלה קשיחה של 256 פודים לכל צומת. ההנחה היא שבכל Pod יש בממוצע שני קונטיינרים או פחות. אם מגדילים את מספר הקונטיינרים לכל Pod, יכול להיות שהמגבלה הזו תהיה נמוכה יותר כי GKE מקצה יותר משאבים לכל קונטיינר.

מומלץ להשתמש בצמתי עובדים עם לפחות ליבת CPU וירטואלית אחת לכל 10 פודים.

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

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

במקרים של אשכולות עם עד 500 צמתים, אפשר לצפות לקצב ממוצע של 20 יחידות Pod שנוצרות בשנייה ו-20 יחידות Pod שנמחקות בשנייה.

במקרים של אשכולות עם יותר מ-500 צמתים, אפשר לצפות לשיעור ממוצע של 100 יחידות Pod שנוצרות בשנייה ו-100 יחידות Pod שנמחקות בשנייה.

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

התפוקה של מחיקת פודים משותפת עם סוגים אחרים של משאבים (לדוגמה, EndpointSlices). אפשר להגדיר Pods כחלק משירות כדי להקטין את קצב המחיקה.

כדי לאפשר ל-Cluster Autoscaler להסיר ביעילות פודים מצמתים שלא מנוצלים מספיק, מומלץ להימנע משימוש בPodDisruptionBudgets ובתקופות חסד ארוכות מדי לסיום.

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

הצמתים יוצרים שעון לכל Secret ו-ConfigMaps שמוגדרים עבור ה-Pods. המספר הכולל של הצפיות שנוצרות על ידי כל הצמתים עשוי ליצור עומס משמעותי במישור הבקרה של האשכול.

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

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

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

כשמשתמשים בהצפנת סודות בשכבת האפליקציה, צריך לאחסן פחות מ-30,000 סודות.

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

יש מגבלה על הכמות המקסימלית של יומנים שכל צומת יכול לשלוח ל-Cloud Logging API. המגבלה שמוגדרת כברירת מחדל משתנה בין 100 Kbps לבין 500 Kbps, בהתאם לעומס. במקרים של אשכולות רגילים, אפשר להגדיל את המגבלה ל-10 MiB על ידי פריסת הגדרה של סוכן Logging עם תפוקה גבוהה. חריגה מהמגבלה הזו עלולה לגרום להשמטת רשומות ביומן.

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

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

אתם יכולים להשתמש ב-Backup for GKE כדי לגבות ולשחזר את עומסי העבודה שלכם ב-GKE.

הגיבוי ל-GKE כפוף למגבלות שחשוב להכיר כשמגדירים תוכניות גיבוי.

בדקו את המגבלות של Backup for GKE.

אם יש סיכוי שעומס העבודה שלכם יחרוג מהמגבלות האלה, מומלץ ליצור כמה תוכניות גיבוי כדי לחלק את הגיבוי ולהישאר במסגרת המגבלות.
מגבלות של Config Connector

אתם יכולים להשתמש ב-Config Connector כדי לנהל Cloud de Confiance משאבים באמצעות Kubernetes. ל-Config Connector יש שני מצבי פעולה:

  • מצב Cluster, שבו יש מופע יחיד של Config Connector לכל אשכול GKE.

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

  • מצב מרחב שמות, שבו לכל מרחב שמות באשכול יש מופע נפרד של Config Connector.

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

לכל מצב יש מאפייני מדרגיות ומגבלות שונים.

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

מה השלב הבא?