תובנות לגבי ניצול כתובות IP ב-GKE

בדף הזה מתוארים התובנות של Network Analyzer לגבי ניצול כתובות ה-IP ב-Google Kubernetes Engine ‏ (GKE). מידע על כל סוגי התובנות זמין במאמר קבוצות וסוגים של תובנות.

צפייה בתובנות ב-Recommender API

כדי לראות את התובנות האלה ב-CLI של gcloud או ב-Recommender API, משתמשים בסוג התובנה הבא:

  • google.networkanalyzer.container.ipAddressInsight

נדרשות ההרשאות הבאות:

  • recommender.networkAnalyzerGkeIpAddressInsights.list
  • recommender.networkAnalyzerGkeIpAddressInsights.get

מידע נוסף על השימוש ב-Recommender API לתובנות של Network Analyzer זמין במאמר שימוש ב-Recommender CLI וב-API.

הקצאה של טווחי Pods גדולים ב-GKE

התובנה הזו מציינת שהניצול של כתובות ה-IP בטווח כתובות ה-Pod באשכול GKE גבוה מ-80%. מדיניות הקצאת כתובות ה-IP של רכיבי ה-Pod ב-GKE משתנה בהתאם לסוג האשכול שנוצר: אשכול המותאם ל-VPC או אשכול מבוסס-נתיבים.

אשכולות מבוססי-נתיבים

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

לאשכול מבוסס-ניתוב יש טווח של כתובות IP שמשמשות ל-Pods ולשירותים. למרות שהטווח משמש גם ל-Pods וגם לשירותים, הוא נקרא טווח כתובות ה-Pod.

החלק האחרון /20 של טווח הכתובות של ה-Pod משמש לשירותים. טווח של /20 כתובות מכיל /20 כתובות.212 = 4096 לכן, כתובות 4096 משמשות לשירותים, ושאר הטווח משמש ל-Pods.

לכל צומת בטווח כתובות ה-IP של ה-Pod יש /24 טווח של כתובות IP עבור ה-Pods. בטווח /24 יש 28 = 256 כתובות. כדאי לזכור שכתובות 4096 בטווח הכתובות של ה-Pod משמשות לשירותים. החלק שנותר בטווח הכתובות של ה-Pod משמש ל-Pods, והוא צריך להיות גדול מספיק כדי להכיל את מספר הצמתים כפול 256 כתובות.

יחס ההקצאה של טווח הכתובות של ה-Pod מחושב באופן הבא:

‫$ rac{ ext {GKE node count} imes {256}}{ ext {גודל טווח כתובות ה-Pod}-{4096}}$

לדוגמה, אתם מתכננים ליצור אשכול צמתים 900. לאחר מכן, תצטרכו כתובות 900 x 256 = 230,400 עבור ה-Pods. נניח שיש לכם טווח כתובות של /14 Pod. טווח של /14 כולל 218 = 262,144 כתובות. מפחיתים את 4096 הכתובות שמשמשות לשירותים, ומקבלים 258,048, שזה מספיק ל-900 צמתים.

אשכולות המותאמים ל-VPC

ב-GKE, אפשר להבחין בין אשכולות לפי האופן שבו הם מנתבים תנועה מ-Pod אחד ל-Pod אחר. קלאסטר שמשתמש בטווחי כתובות IP של כינויים נקרא אשכול המותאם ל-VPC. מידע נוסף זמין במאמר בנושא אשכולות מקוריים של VPC.

כשיוצרים מאגר צמתים באשכול המותאם ל-VPC, בוחרים טווח כתובות משני להקצאת כתובות IP ל-Pods של GKE. מאגרי צמתים שונים יכולים להשתמש בטווחים משניים שונים כדי להקצות כתובות IP של Pod. מידע נוסף מופיע במאמר בנושא CIDR מרובה-Pod. Network Analyzer מחשב את יחס ההקצאה של כל טווח כתובות IP משני שמשמש להקצאת כתובות IP של Pod לאשכול נתון. אם יחס ההקצאה הכולל גדול מ-80%, תקבלו תובנה לגבי ניצול גבוה.

יחס ההקצאה של טווח כתובות IP משני יחיד מחושב באופן הבא:

‫$\frac{\text {IP addresses from the secondary range allocated to nodes}}{\text {Secondary range size}}$

לדוגמה, טווח משני של Pod‏ /24 יכול להכיל 256‏ Pods. אם יש רק צומת 1 עם הפעלת פודים של ברירת מחדל max_pods_per_node, 110 ו-16, היחס יהיה 100% (256/256) במקום 6.25% (16/256), כי למרות שכתובות ה-IP של פוד 240 לא נמצאות בשימוש, הן עדיין שייכות לצומת הזה. אפשר ליצור עוד צומת חדש רק אם יש 256 כתובות IP של Pod שלא נמצאות בשימוש.

ההקצאה הכוללת מחושבת כך:

‫$ rac{ ext {Sum of allocated IPs across all secondary IP address ranges used to allocate Pod IP addresses}}{ ext {Sum of secondary IP address range sizes used to allocate Pod IP addresses}}$

לדוגמה, אם כתובת ה-IP של הפוד שמוגדרת כברירת מחדל וטווח כתובות ה-IPv4 הנוסף של הפוד מוגדרים כ-/22 ויש 2 מאגרי צמתים, מאגר צמתים אחד משתמש בטווח כתובות ה-IP של הפוד שמוגדר כברירת מחדל ויש בו 3 צמתים, ומאגר הצמתים השני משתמש בטווח כתובות IP נוסף של הפוד ויש בו גם 3 צמתים, כאשר מספר הפודים המקסימלי שמוגדר כברירת מחדל הוא 110. ‫Kubernetes מקצה טווח CIDR של /24 לצמתים באשכול. אם יש 6 צמתים ומוקצה טווח CIDR של /24, יש בסך הכול 256 * 6 = 1536 כתובות IP. זהו 75% מהמספר הכולל של כתובות ה-IP שזמינות בשני טווחי כתובות ה-IP של ה-Pod‏ (1024 * 2 = 2048).

חשוב לציין שאם כתובת ה-IP המשנית משותפת בין אשכולות שונים, התובנות יציגו את הערך הכולל המצטבר של כל האשכולות. כדי לראות את הניצול של טווח כתובות IP של אשכול יחיד, אפשר להריץ את הפקודה gcloud container cluster describe CLUSTER_NAME כדי לראות את סטטוס הניצול של כל כתובת IP משנית. מחליפים את CLUSTER_NAME בשם האשכול.

המלצות

הקצאה של טווחי כתובות IP של GKE Pod מגבילה את ההתאמה האוטומטית לעומס (automatic scaling)

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

התובנה הזו נוצרת על ידי Network Analyzer כשהערך של ניצול כתובות ה-IP שניתנות להרחבה אוטומטית מלאה חורג מ-100%.

ערך הניצול של כתובות ה-IP עם שינוי גודל אוטומטי מלא חורג מ-100% אם מספר כתובות ה-IP של ה-Pod שנדרשות לתמיכה במספר המקסימלי של הצמתים באשכול חורג ממספר כתובות ה-IP בטווחים של כתובות ה-IP של ה-Pod באשכול. מספר הצמתים המקסימלי באשכול הוא הסכום של מספר הצמתים המקסימלי בכל מאגר צמתים באשכול (maxNodeCount).

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

אשכולות מבוססי-נתיבים

התובנה הזו נוצרת כשיחס ההקצאה של טווח כתובות ה-Pod הוא יותר מ-100% וכל מאגרי הצמתים מוגדלים אוטומטית באופן מלא. צמתי GKE לא ייווצרו בגלל חוסר במרחב של כתובות IP.

אשכולות המותאמים ל-VPC

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

מידע נוסף זמין במאמרים שיטות מומלצות לרישות ב-GKE ומגבלות של Cluster Autoscaler.

המלצות

  • באשכולות מבוססי-נתיבים, צריך ליצור מחדש את האשכול עם טווח כתובות Pod גדול יותר. יוצרים את האשכול הזה כאשכול מקורי של VPC כי זהו מצב הרשת המומלץ. מידע נוסף על אשכולות מותאמים ל-VPC ואשכולות מבוססי-נתיבים
  • במקרה של אשכולות המותאמים ל-VPC, מוסיפים טווחי Pod נוספים לרמת האשכול באמצעות multi-pod CIDR ומפעילים הקצאת צמתים אוטומטית (NAP) כדי לבצע אוטומציה של שינוי גודל הצמתים עם הקצאה אוטומטית של כתובות IP של Pod. אם אתם רוצים יותר שליטה בכתובות ה-IP של ה-Pods שמשמשות למאגר הצמתים, אתם יכולים ליצור את מאגרי הצמתים שמשתמשים בטווח כתובות IP משני ספציפי באמצעות CIDR של כמה Pods. עם זאת, האפשרות הזו רלוונטית רק לאשכולות רגילים.