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

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

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

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

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

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

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

אשכולות עם עד 5,000 צמתים

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

אם אתם מתכננים להרחיב את האשכול מעבר ל-5,000 צמתים, אתם צריכים לפנות אל Cloud Customer Care כדי להגדיל את גודל האשכול ואת מגבלת המכסה.

אשכולות עם יותר מ-5,000 צמתים

‫GKE תומך באשכולות גדולים רגילים עם עד 15,000 צמתים. בגרסה 1.31 ואילך, ‏ GKE תומך באשכולות גדולים של עד 65,000 צמתים. המכסה של 65,000 נועדה להרצת עומסי עבודה גדולים של AI.

אם אתם מתכננים להגדיל את מספר הצמתים באשכול ל-15,000 או ל-65,000, אתם צריכים לבצע את המשימות הבאות:

  1. חשוב להביא בחשבון את המגבלות הבאות:

  2. כדי להגדיל את גודל האשכול ואת מכסת המגבלה ל-15,000 צמתים או ל-65,000 צמתים, בהתאם לצרכי ההתאמה לעומס, צריך לפנות אל Cloud Customer Care.

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

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

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

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

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

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

השיטות המומלצות האלה חלות על כל אשכול Kubernetes שמוגדר כברירת מחדל ושלא מותקנות בו תוספים. הרחבת אשכולות Kubernetes באמצעות Webhook או הגדרות מותאמות אישית של משאבים (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 שמאחורי Service יחיד צריך להיות נמוך מ-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 ואילך, מומלץ להגביל את מספר ה-Pods מאחורי Service יחיד ל-10,000.

מידע נוסף זמין במאמר חשיפת אפליקציות באמצעות שירותים.
רשומות 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 נקודות קצה בכל השירותים.
מספר האובייקטים של Horizontal Pod Autoscaler בכל אשכול

כל Horizontal Pod Autoscaler (HPA) מעובד כל 15 שניות.

יותר מ-300 אובייקטים של HPA עלולים לגרום לירידה לינארית בביצועים.

חשוב לשמור על מספר האובייקטים של HPA במסגרת המגבלה הזו, אחרת יכול להיות שתחוו ירידה ליניארית בתדירות של עיבוד HPA. לדוגמה, ב-GKE 1.22 עם 2,000 רכיבי HPA, רכיב HPA יחיד יעבור עיבוד מחדש כל דקה ו-40 שניות.

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

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

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

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

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

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

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

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

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

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

הצמתים יוצרים מעקב לכל 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 כדי לנהל Google Cloud משאבים באמצעות Kubernetes. ל-Config Connector יש שני מצבי פעולה:

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

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

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

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

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

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

מה השלב הבא?