הגדלת הקיבולת של אשכולות Google Distributed Cloud

בדומה לכל אשכול Kubernetes, למדרגיות של אשכול Google Distributed Cloud יש הרבה מאפיינים שקשורים זה לזה. המסמך הזה נועד לעזור לכם להבין את המאפיינים העיקריים שאפשר לשנות כדי להגדיל את האשכולות בלי לשבש את עומסי העבודה.

הסבר על המגבלות

‫Google Distributed Cloud היא מערכת מורכבת עם שטח אינטגרציה גדול. יש הרבה מאפיינים שמשפיעים על יכולת ההרחבה של האשכול. לדוגמה, מספר הצמתים הוא רק אחד מתוך הרבה ממדים שבהם אפשר להרחיב את Google Distributed Cloud. מאפיינים אחרים כוללים את המספר הכולל של Pods ו-Services. רבים מהמאפיינים האלה, כמו מספר הפודים לכל צומת ומספר הצמתים לכל אשכול, קשורים זה לזה. מידע נוסף על המאפיינים שמשפיעים על יכולת ההתאמה לגודל מופיע במאמר Kubernetes Scalability thresholds בקטע Scalability Special Interest Group (SIG) במאגר Kubernetes Community ב-GitHub.

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

למידע נוסף על המגבלות שחלות על אשכולות Google Distributed Cloud, אפשר לעיין במאמר בנושא מכסות ומגבלות.

הכנות להרחבת הפעילות

כשמתכוננים להרחבת האשכולות של Google Distributed Cloud, כדאי לעיין בדרישות ובמגבלות שמפורטות בקטעים הבאים.

דרישות המעבד (CPU) והזיכרון של צומת מישור הבקרה

בטבלה הבאה מפורטת תצורת המעבד והזיכרון המומלצת לצמתים של מישור הבקרה עבור אשכולות שמריצים עומסי עבודה של ייצור:

מספר הצמתים של האשכול מעבדי מישור בקרה מומלצים זיכרון מומלץ למישור הבקרה
1-50 ‫8 ליבות ‫‎32 GiB
51-100 ‫16 ליבות ‫64 GiB

מספר ה-Pods והשירותים

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

‫Pod CIDR ומספר הצמתים המקסימלי

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

כמה נקודות שכדאי לחשוב עליהן:

  • המספר הכולל של כתובות ה-IP ששמורות ל-Pods באשכול מוגדר באמצעות clusterNetwork.pods.cidrBlocks, שמקבל טווח של כתובות IP שמוגדרות בסימון CIDR. לדוגמה, הערך 192.168.0.0/16 שמופיע מראש מציין טווח של 65,536 כתובות IP מ-192.168.0.0 עד 192.168.255.255.

  • המספר המקסימלי של פודים שאפשר להריץ על צומת יחיד מצוין באמצעות nodeConfig.podDensity.maxPodsPerNode.

  • על סמך ההגדרה של מספר הפודים המקסימלי לכל צומת, Google Distributed Cloud מקצה לצומת בערך פי שניים כתובות IP. כתובות ה-IP הנוספות עוזרות למנוע שימוש חוזר לא מכוון בכתובות ה-IP של ה-Pod בפרק זמן קצר.

  • כדי לחשב את המספר הכולל של הצמתים שאפשר להוסיף לאשכול, מחלקים את המספר הכולל של כתובות ה-IP של ה-Pod במספר כתובות ה-IP של ה-Pod שהוקצו לכל צומת.

לדוגמה, אם ה-CIDR של ה-Pod הוא 192.168.0.0/17, יש לכם סך של 32,768 כתובות IP‏ (2(32-17) = 215 = 32,768). אם מגדירים את המספר המקסימלי של Pods לכל צומת ל-250, ‏ Google Distributed Cloud מקצה טווח של כ-500 כתובות IP, ששווה בערך לבלוק CIDR‏ /23 (‎2(32-23) = 29 = 512). לכן, המספר המקסימלי של צמתים במקרה הזה הוא 64 (215 כתובות/אשכול חלקי 29 כתובות/צומת = 2(15-9) צמתים/אשכול = 26 = 64 צמתים/אשכול).

הערכים של clusterNetwork.pods.cidrBlocks ושל nodeConfig.podDensity.maxPodsPerNode הם קבועים, לכן חשוב לתכנן בקפידה את הגידול העתידי של האשכול כדי להימנע ממצב שבו לא תהיה קיבולת מספיקה לצמתים. ההמלצות לגבי המספר המקסימלי של Pods לכל אשכול, Pods לכל צומת וצמתים לכל אשכול על סמך בדיקות מפורטות במאמר בנושא מגבלות.

CIDR של השירות

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

משאבים ששמורים לדמונים של המערכת

כברירת מחדל, מערכת Google Distributed Cloud שומרת באופן אוטומטי משאבים בצומת עבור דמונים של המערכת, כמו sshd או udev. משאבי המעבד (CPU) והזיכרון שמורים בצומת עבור תהליכי רקע של המערכת, כדי שהתהליכים האלה יקבלו את המשאבים שהם צריכים. בלי התכונה הזו, יכול להיות ש-Pods ינצלו את רוב המשאבים בצומת, כך ששדי מערכת לא יוכלו להשלים את המשימות שלהם.

בפרט, Google Distributed Cloud שומרת 80 מילי-ליבות של מעבד (80 mCPU) ו-280 מביבייט (280 MiB) של זיכרון בכל צומת עבור שדי מערכת. הערה: יחידת המעבד mCPU מייצגת אלפית של ליבה, ולכן 80/1000 או 8% מליבה בכל צומת שמורים לדמונים של המערכת. כמות המשאבים שמוקצים קטנה ולא משפיעה באופן משמעותי על הביצועים של ה-Pod. עם זאת, יכול להיות ש-kubelet בצומת יסלק קבוצות Pod אם השימוש שלהן במעבד או בזיכרון חורג מהכמויות שהוקצו להן.

הגדרת רשת באמצעות MetalLB

כדאי להגדיל את מספר הרמקולים של MetalLB כדי לטפל בהיבטים הבאים:

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

  • עמידות בפני תקלות: ככל שיש יותר רמקולים, ההשפעה הכוללת של תקלה ברמקול אחד קטנה יותר.

‫MetalLB דורש קישוריות Layer 2 בין הצמתים של איזון העומסים. במקרה כזה, יכול להיות שתהיו מוגבלים במספר הצמתים עם קישוריות Layer 2 שבהם אפשר להציב רכיבי MetalLB speaker.

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

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

הפעלת הרבה צמתים, Pods ושירותים

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

יצירת אשכול בלי kube-proxy

כדי ליצור אשכול עם ביצועים גבוהים שאפשר להרחיב אותו כדי להשתמש במספר גדול של שירותים ונקודות קצה, מומלץ ליצור את האשכול בלי kube-proxy. בלי kube-proxy, האשכול משתמש ב-GKE Dataplane V2 במצב kube-proxy-replacement. במצב הזה לא מתבצע שימוש במשאבים שנדרש כדי לתחזק קבוצה גדולה של כללי iptables.

אי אפשר להשבית את השימוש ב-kube-proxy באשכול קיים. צריך להגדיר את התצורה הזו כשיוצרים את האשכול. הוראות ומידע נוסף זמינים במאמר בנושא יצירת אשכול ללא kube-proxy.

הגדרת CoreDNS

בקטע הזה מוסבר על היבטים של CoreDNS שמשפיעים על יכולת ההתאמה של האשכולות שלכם.

Pod DNS

כברירת מחדל, אשכולות Google Distributed Cloud מזריקים ל-Pods את resolv.conf שדומה לזה:

nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5

האפשרות ndots:5 מציינת ששמות מארחים עם פחות מ-5 נקודות לא נחשבים לשם דומיין מוגדר במלואו (FQDN). שרת ה-DNS מוסיף את כל דומייני החיפוש שצוינו לפני שהוא מחפש את שם המארח המקורי שנדרש, ולכן הוא מבצע את החיפושים לפי הסדר הבא כשמנסים לפתור את google.com:

  1. google.com.NAMESPACE.svc.cluster.local
  2. google.com.svc.cluster.local
  3. google.com.cluster.local
  4. google.com.c.PROJECT_ID.internal
  5. google.com.google.internal
  6. google.com

כל אחד מהחיפושים מתבצע עבור IPv4 (רשומת A) ו-IPv6 (רשומת AAAA), מה שמוביל ל-12 בקשות DNS לכל שאילתה שאינה FQDN, ומגדיל באופן משמעותי את תנועת ה-DNS. כדי לפתור את הבעיה, מומלץ להצהיר על שם המארח לחיפוש כ-FQDN על ידי הוספת נקודה בסוף (google.com.). צריך לבצע את ההצהרה הזו ברמת עומס העבודה של האפליקציה. מידע נוסף זמין בדף ההוראות של resolv.conf.

IPv6

אם האשכול לא משתמש ב-IPv6, אפשר לצמצם את בקשות ה-DNS בחצי על ידי ביטול בדיקת הרשומה AAAA בשרת ה-DNS במעלה הזרם. אם אתם צריכים עזרה בהשבתת בדיקות ה-AAAA, אתם יכולים לפנות אל Cloud Customer Care.

מאגר צמתים ייעודי

בגלל האופי הקריטי של שאילתות DNS במחזורי החיים של האפליקציות, מומלץ להשתמש בצמתים ייעודיים לפריסת coredns. הפריסה הזו שייכת לדומיין כשל שונה מאפליקציות רגילות. אם אתם צריכים עזרה בהגדרת צמתים ייעודיים לפריסת coredns, אתם יכולים לפנות אל Cloud Customer Care.

בעיות מדרגיות ב-MetalLB

‫MetalLB פועל במצב פעיל-סביל, כלומר בכל נקודת זמן, יש רק רכיב MetalLB speaker אחד שמשרת LoadBalancer כתובת IP וירטואלית מסוימת.

מעבר לגיבוי (Failover)

לפני גרסה 1.28.0 של Google Distributed Cloud, במקרים של פריסה רחבת היקף, יכול להיות שמעבר הגיבוי האוטומטי של MetalLB ייקח הרבה זמן, ועלול להוות סיכון לאמינות של האשכול.

מגבלות על חיבורים

אם יש LoadBalancerכתובת IP וירטואלית מסוימת, כמו Ingress Service, שצפויים לה כמעט 30,000 חיבורים בו-זמניים או יותר, סביר להניח שצומת הרמקול שמטפל בכתובת ה-IP הווירטואלית ימצה את היציאות הזמינות. בגלל מגבלה בארכיטקטורה, אין פתרון לבעיה הזו מ-MetalLB. כדאי לעבור אל איזון עומסים בחבילה עם BGP לפני יצירת אשכול או להשתמש במחלקת כניסה אחרת. מידע נוסף מופיע במאמר בנושא הגדרת Ingress.

רמקולים של מאזן עומסים

כברירת מחדל, ב-Google Distributed Cloud נעשה שימוש באותו מאגר צמתים של איזון עומסים גם למישור הבקרה וגם למישור הנתונים. אם לא מציינים מאגר צמתים של מאזן עומסים (loadBalancer.nodePoolSpec), נעשה שימוש במאגר הצמתים של מישור הבקרה (controlPlane.nodePoolSpec).

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

הגדרות של Ingress

אם אתם צופים שיתבצעו כמעט 30,000 חיבורים בו-זמנית לכתובת VIP אחת של שירות LoadBalancer, יכול להיות ש-MetalLB לא יוכל לתמוך בכך.

אפשר לחשוף את כתובת ה-VIP באמצעות מנגנונים אחרים, כמו F5 BIG-IP. לחלופין, אפשר ליצור אשכול חדש באמצעות איזון עומסים בחבילה עם BGP, שבו אין את אותה מגבלה.

שיפור הרכיבים של Cloud Logging ו-Cloud Monitoring

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

בפרט, kube-state-metrics באשכולות עם מספר גדול של שירותים ונקודות קצה עלול לגרום לשימוש מוגזם בזיכרון גם ב-kube-state-metrics עצמו וגם ב-gke-metrics-agent באותו צומת. גם השימוש במשאבים של metrics-server יכול להתרחב מבחינת צמתים, Pods ושירותים. אם נתקלים בבעיות במשאבים ברכיבים האלה, אפשר לפנות אל Cloud Customer Care.

שימוש ב-sysctl כדי להגדיר את מערכת ההפעלה

מומלץ לכוונן את הגדרות מערכת ההפעלה של הצמתים כך שיתאימו בצורה הטובה ביותר לתרחיש לדוגמה של עומס העבודה. לפעמים צריך לשנות את הפרמטרים fs.inotify.max_user_watches ו-fs.inotify.max_user_instances ששולטים במספר המשאבים של inotify. לדוגמה, אם מופיעות הודעות שגיאה כמו אלה שבהמשך, כדאי לבדוק אם צריך לשנות את הפרמטרים האלה:

The configured user limit (128) on the number of inotify instances has been reached

ENOSPC: System limit for number of file watchers reached...

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

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

בקטע הזה מתוארות שיטות מומלצות להרחבת האשכול.

שינוי קנה מידה של מאפיין אחד בכל פעם

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

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

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

יצירת אשכולות היברידיים או עצמאיים ללא צמתי עובדים

אם אתם יוצרים אשכול גדול היברידי או עצמאי עם יותר מ-50 צמתי עובדים, עדיף ליצור קודם אשכול זמינות גבוהה (HA) עם צמתי מישור בקרה, ואז להגדיל את קנה המידה בהדרגה. בפעולת יצירת האשכול נעשה שימוש באשכול אתחול, שהוא לא HA ולכן הוא פחות אמין. אחרי שיוצרים את האשכול העצמאי או ההיברידי של HA, אפשר להשתמש בו כדי להגדיל את מספר הצמתים.

הגדלת מספר צמתי העובדים באצוות

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

הפעלת משיכות מקבילות של תמונות

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

כדי לצמצם את הסיכון הזה, מומלץ להגדיר את serializeImagePulls ל-false בהגדרה מותאמת אישית של kubelet. הוראות ומידע נוסף זמינים במאמר הגדרת אפשרויות משיכת תמונות של kubelet. הפעלת משיכות תמונות מקבילות עלולה לגרום לעליות חדות בצריכת רוחב הפס של הרשת או בקלט/פלט של הדיסק.

שיפור ההגדרות של בקשות למשאבי אפליקציות ומגבלות

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

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

שימוש בשותף אחסון

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

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

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

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

חשוב גם לבצע ביקורת ברכיבים אחרים, כולל:

  • ספק האחסון
  • ‫Cluster webhooks

מעקב אחרי השימוש במשאבים

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

מעקב צמוד אחרי מדדי הניצול

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

מעקב אחרי צריכת רוחב הפס

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

שיפור הביצועים של etcd

מהירות הדיסק היא קריטית לביצועים וליציבות של etcd. דיסק איטי מגדיל את זמן האחזור של בקשות etcd, מה שעלול לגרום לבעיות ביציבות האשכול. כדי לשפר את הביצועים של האשכול, Google Distributed Cloud מאחסן אובייקטים של אירועים במופע etcd נפרד וייעודי. מופע etcd רגיל משתמש ב-/var/lib/etcd כספריית הנתונים שלו ובפורט 2379 לבקשות של לקוחות. מופע etcd-events משתמש ב-/var/lib/etcd-events בתור ספריית הנתונים ובפורט 2382 לבקשות של לקוחות.

מומלץ להשתמש בדיסק SSD לאחסון נתוני etcd. כדי להשיג ביצועים אופטימליים, כדאי לטעון דיסקים נפרדים ל-/var/lib/etcd ול-/var/lib/etcd-events. שימוש בדיסקים ייעודיים מבטיח ששני מופעי etcd לא ישתפו קלט/פלט של דיסקים.

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

כדי לבדוק את הביצועים של etcd והדיסק, משתמשים במדדים הבאים של זמן האחזור של קלט/פלט (I/O) ב-etcd ב-Metrics Explorer:

  • ‫etcd_disk_backend_commit_duration_seconds: משך הזמן צריך להיות פחות מ-25 אלפיות השנייה באחוזון 99 (p99).
  • ‫etcd_disk_wal_fsync_duration_seconds: משך הזמן צריך להיות פחות מ-10 אלפיות השנייה לאחוזון 99 (p99).

מידע נוסף על הביצועים של etcd זמין במאמרים What does the etcd warning "apply entries took too long" mean? and What does the etcd warning "failed to send out heartbeat on time" mean?.

אם אתם צריכים עזרה נוספת, אתם יכולים לפנות אל

מה השלב הבא?