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

• נדרש GKE Dataplane V2. מידע נוסף זמין במאמר בנושא מגבלות הצמתים ב-GKE Dataplane V2.
• נדרש Private Service Connect.

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

• נדרש GKE Dataplane V2. מידע נוסף זמין במאמר מגבלות על צמתים ב-GKE Dataplane V2.
• נדרש Private Service Connect.

• נדרשת גרסת GKE‏ 1.31 ואילך.
• כדי ליהנות משיפורים בביצועים של התאמת קנה המידה של אשכולות גדולים, מומלץ להשתמש בגרסה 1.36 של GKE או בגרסה חדשה יותר.
• זמין רק לאשכולות אזוריים רגילים.
• אין תמיכה במידרוג אוטומטי של האשכול. במקום זאת, אפשר להגדיל או להקטין את מספר הצמתים במאגר באמצעות GKE API.
• שירותים עם יותר מ-100 פודים צריכים להיות headless.
• כל Pod צריך לפעול בצומת משלו, למעט DaemonSets של המערכת. כדי לתזמן קבוצות Pod בצמתים ספציפיים, משתמשים בזיקה או אנטי-זיקה של Kubernetes Pod.

• נדרש GKE Dataplane V2. מידע נוסף זמין במאמר בנושא מגבלות הצמתים ב-GKE Dataplane V2.
• נדרש Private Service Connect.
• אין תמיכה בכמה רשתות עבור Pods.

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

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

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

הגודל הכולל של כל האובייקטים מכל סוג שמאוחסנים ב-etcd צריך להיות קטן מ-800 MB. זה רלוונטי במיוחד לאשכולות שמשתמשים בהרבה Secrets או ConfigMaps גדולים, או בנפח גבוה של CRDs.

• יש יותר מדי שירותים.
• מספר הקצוות העורפיים של השירות גבוה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מספר רשומות ה-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‏ (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.

מומלץ להשתמש בצמתי עובד עם לפחות vCPU אחד לכל 10 Podים.

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

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

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

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

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

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

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

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

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

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

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

מידע נוסף זמין בהשוואה בין סדרות מכונות.

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

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

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

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

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

הקריאה ל-webhooks של בקרת הגישה מתבצעת במקביל (אימות) או ברצף (שינוי). בכל מקרה, נוסף עיכוב מסוים לכל בקשה מוגדרת שתואמת לבוררים של ה-webhook. כשמבצעים את ה-webhook, עיכובים קצרים ועקביים, כמו 50-100 אלפיות השנייה, עלולים להוביל לירידה משמעותית בביצועים.

מגדירים את ה-webhooks כך שזמן האחזור הממוצע שלהם יהיה מתחת ל-10 אלפיות השנייה. מציינים את הפעולה, את סוגי המשאבים ואת מרחבי השמות שאליהם ה-webhook צריך להתייחס. מומלץ להימנע מתיעוד אירועים, כי זה עלול לגרום לבעיות בביצועים, למשל טעינה מראש איטית יותר של תמונות. הפעלת כמה מופעים של נקודות קצה של webhook בצמתים נפרדים מעומס העבודה ושמירה על זמן אחזור נמוך. מומלץ להפעיל את failurePolicy: Ignore ולהגדיר זמן קצר לתפוגה (באמצעות timeoutSeconds).

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

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

כדאי לעיין במגבלות של Backup for GKE.

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

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

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

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

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

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

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