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

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

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

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

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

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

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

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

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

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

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

מספר הפודים והשירותים

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

Service 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 דורש קישוריות ברמה 2 בין הצמתים של איזון העומסים. במקרה כזה, יכול להיות שתהיו מוגבלים במספר הצמתים עם קישוריות Layer 2 שבהם אפשר להציב רכיבי MetalLB.

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

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

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

הוספה של צמתים, Pods ושירותים היא דרך להגדיל את קנה המידה של האשכול. בקטעים הבאים מפורטות כמה הגדרות ותצורות נוספות שכדאי לקחת בחשבון כשמגדילים את מספר הצמתים, ה-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 אחד שמשרת כתובת IP וירטואלית מסוימת.LoadBalancer

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

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

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

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

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

אם מרחיבים אשכול ליותר צמתי עובדים, עדיף להרחיב אותו בשלבים. מומלץ להוסיף עד 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 והדיסק, משתמשים במדדים הבאים של השהיית קלט/פלט של 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?‎ ו-What does the etcd warning "failed to send out heartbeat on time" mean?‎.

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care. אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל:

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

מה השלב הבא?