הסבר על הקצאת כתובות IP ב-GKE

כדי ליצור אשכולות Google Kubernetes Engine ‏ (GKE) שניתנים להרחבה ומאובטחים, צריך לנהל ביעילות את כתובות ה-IP. במאמר הזה מוסבר בצורה מקיפה איך GKE משתמש בכתובות IP לתקשורת בין אשכולות, מהם מודלים הרשת הנתמכים ומהן שיטות מומלצות לניהול יעיל של כתובות IP.

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

לפני שממשיכים, חשוב להכיר את המושגים הבאים:

איך כתובות IP מחברות בין רכיבי GKE

‫GKE מבוסס על מודל הרשת של Kubernetes, שבו כל רכיב צריך כתובת IP נפרדת כדי לתקשר. בקטעים הבאים מוסבר איך GKE מקצה כתובות IP ומשתמש בהן לרכיבי ליבה של אשכולות:

  • צמתים: ‏ GKE מקצה לכל צומת, שהוא מכונת VM של Compute Engine, כתובת IP פנימית מטווח כתובות ה-IP הראשי של רשת המשנה שמשויכת למאגר הצמתים. כתובת ה-IP הזו מאפשרת תקשורת בין הצומת לבין מישור הבקרה של Kubernetes. לצמתים יכולה להיות גם כתובת IP חיצונית לגישה לאינטרנט.

  • Pods: בהתאם למודל 'IP לכל Pod' של Kubernetes, ‏ GKE מקצה לכל Pod כתובת IP ייחודית מטווח CIDR של Pod שהוקצה לצומת. ב-GKE, רשת ה-VPC מנתבת באופן מקורי כתובות IP של Pod. יכולת הניתוב המובנית הזו מאפשרת תקשורת ישירה בין Pods – גם בין צמתים שונים – בלי שנדרש תרגום כתובות רשת (NAT). לכל הקונטיינרים באותו Pod יש את אותה כתובת IP והם יכולים לתקשר באמצעות localhost.

  • שירותים: פלטפורמת GKE מקצה לכל שירות Kubernetes כתובת IP וירטואלית ויציבה (ClusterIP) מתוך טווח כתובות IP משני ייעודי. ה-ClusterIP הזה מספק נקודת קצה יחידה ומהימנה לקבוצה של Pods. כששולחים תנועה אל ClusterIP, ‏ GKE מבצע איזון עומסים אוטומטי של התנועה אל Pod תקין בשירות הזה.

  • מישור הבקרה: באשכולות פרטיים, מישור הבקרה נמצא בפרויקט דייר שמנוהל על ידי Google, ומשתמש בטווח כתובות IP פנימי משלו. פרויקט הדייר הזה מתחבר לרשת ה-VPC שלכם, ומאפשר תקשורת מאובטחת בין מישור הבקרה לבין הצמתים ברשת ה-VPC של האשכול. החיבור הזה בדרך כלל משתמש ב-Private Service Connect.

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

בטבלה הבאה מפורט איך GKE מקצה כתובות IP לרכיבי האשכול:

רכיב איך מוקצות כתובות IP
Node ‫GKE מקצה כתובת IP פנימית לכל צומת. ‫GKE מקצה את כתובת ה-IP הזו מטווח כתובות ה-IP הראשי של תת-הרשת שמשויכת למאגר הצמתים של הצומת. רשת המשנה הזו יכולה להיות רשת המשנה שמוגדרת כברירת מחדל עבור האשכול, או רשת משנה נוספת.
Pod ‫GKE מקצה לכל Pod כתובת IP ייחודית מטווח ה-CIDR של ה-Pod שהוקצה לצומת שלו.
Service (ClusterIP) ‫GKE מקצה לכל שירות כתובת IP וירטואלית יציבה (ClusterIP) מטווח כתובות IP משני ייעודי ברשת ה-VPC של האשכול.
מישור הבקרה באשכולות פרטיים, למישור הבקרה של GKE יש טווח כתובות IP פנימי משלו בפרויקט דייר שמנוהל על ידי Google. פרויקט הדייר הזה מתחבר לרשת ה-VPC שלכם, בדרך כלל באמצעות Private Service Connect.
מאזן עומסים מאזני עומסים חיצוניים משתמשים בכתובות IP ציבוריות. מאזני עומסים פנימיים משתמשים בכתובות IP פנימיות מטווח כתובות ה-IP הראשי של רשת המשנה של האשכול.

הקצאת כתובות IP ב-Kubernetes והטמעה ב-GKE

כדי להשתמש ב-GKE בצורה יעילה, צריך להבין את ההבדלים בין מודל הרשתות המופשט של Kubernetes לבין האופן שבו GKE מיישם את המודל הזה ב- Google Cloud.

  • מודל כתובות ה-IP של Kubernetes: פרויקט Kubernetes בקוד פתוח מציין שכל Pod מקבל כתובת IP ייחודית. כל כתובות ה-IP של ה-Pod יכולות לתקשר ישירות בלי תרגום כתובות רשת (NAT). כך נוצר מרחב רשת שטוח שבו פודים יכולים להגיע זה לזה באמצעות כתובות ה-IP שהוקצו להם.

  • הטמעה של הקצאת כתובות IP ב-GKE: ‏ GKE מטמיע את מודל הקצאת כתובות ה-IP של Kubernetes ב- Google Cloud על ידי שילוב עם רשתות מקוריות של VPC. כשיוצרים Pod,‏ GKE מקצה לו כתובת IP מטווח כתובות IP של כינוי VPC. כך אפשר לנתב את כתובת ה-IP של כל Pod באופן מקורי בכל רשת ה-VPC. האפשרות הזו מאפשרת תקשורת ישירה לא רק בין פודים, אלא גם עם משאבים אחרים Google Cloud , כמו מכונות של Compute Engine ומסדי נתונים של Cloud SQL. באופן דומה, GKE מנהל כתובות IP של Kubernetes ‏ (כמו Service) בתוך רשת ה-VPC.ClusterIP כשיוצרים LoadBalancerשירותים לחשיפה חיצונית, GKE מקצהGoogle Cloud מאזני עומסים. מאזני העומסים האלה משתמשים בכתובות IP ציבוריות או פנימיות מרשת ה-VPC שלכם. ‫GKE משתמש בתשתית חזקה של הקצאת כתובות IP ורישות כדי להטמיע מושגים של רישות מבוסס-IP של Kubernetes באופן ניתן להרחבה ומאובטח. Google Cloud

מודל הרשת של GKE: אשכולות המותאמים ל-VPC

‫GKE מטמיע את מודל הרשת של Kubernetes באמצעות רשתות מקוריות של VPC, שהן יכולת ליבה Google Cloud .

המודל הזה משתמש בטווחי כתובות IP של כינויים. באשכול מקורי של VPC,‏ Kubernetes מגדיר כתובות IP של Pod כטווחי כתובות IP של כינוי בממשק הרשת הווירטואלי של הצומת.

להטמעה הזו יש כמה יתרונות מרכזיים:

  • ניתוב מקורי של VPC: אפשר לנתב את כתובות ה-IP של הפודים ישירות ברשת ה-VPC. האפשרות הזו מפשטת את תכנון הרשת ומאפשרת תקשורת ישירה עם זמן אחזור נמוך בין ה-Pods לבין משאבים אחרים של Google Cloud , כמו מכונות של Compute Engine ומופעים של Cloud SQL.
  • חיסכון במכסת הנתיבים: באמצעות שימוש בכתובות IP של כינויים עבור Pods,‏ GKE לא יוצר נתיבים סטטיים מותאמים אישית לכל צומת. השיטה הזו חוסכת את מכסת הנתיבים של ה-VPC, וזה שיפור משמעותי לעומת אשכולות מדור קודם שמבוססים על נתיבים. היא חשובה לפריסות בקנה מידה גדול.
  • שיפור האבטחה: ניתוב מקורי של VPC מאפשר להחיל כללי חומת אש מקוריים של VPC ישירות על התנועה ב-Pod, וכך לשפר את האבטחה ברמת הרשת.

ההגדרה המומלצת ומוגדרת כברירת מחדל לכל אשכולות GKE היא VPC-native.

למה ניהול יעיל של כתובות IP הוא חיוני

כדי לוודא שהאשכול יכול להתרחב ולשמור על תקינות האפליקציה, צריך לתכנן את מרחב כתובות ה-IP בצורה יעילה:

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

בחירת מודל הקצאת כתובות IP לאשכול

‫GKE תומך בכמה הגדרות של מחסנית רשת כדי לענות על דרישות הרשת שלכם, כולל IPv4 בלבד, מחסנית כפולה (IPv4 ו-IPv6) ואפשרויות עתידיות של IPv6 בלבד.

‫IPv4 בלבד (single stack)

זו ההגדרה הרגילה והנפוצה ביותר, שבה כל רכיבי האשכול משתמשים בכתובות IPv4. גם במודל IPv4 בלבד, GKE מספק גמישות:

  • כתובות IP פרטיות מסוג RFC 1918: משתמשים בטווחים של כתובות IP פרטיות מסוג RFC 1918 (לדוגמה, 10.0.0.0/8) עבור האשכול.
  • כתובות IP ציבוריות לשימוש פרטי (PUPI): אם לארגון שלכם אין מספיק מרחב כתובות IP פרטיות, אתם יכולים להשתמש בטווחים של כתובות IP ציבוריות לשימוש פנימי ברשת ה-VPC. כשמשתמשים ב-PUPI, צריך להגדיר את סוכן הסוואת כתובת ה-IP. הסוכן הזה מבצע תרגום כתובות רשת (SNAT) בתעבורה יוצאת מ-Pods. בלי SNAT, תעבורת נתונים חוזרת אל Pod שמשתמש ב-PUPI מנותבת דרך האינטרנט הציבורי ונכשלת. הסוכן IP Masquerade מונע את זה על ידי שינוי כתובת ה-IP של המקור של מנות יוצאות מ-PUPI של ה-Pod לכתובת ה-IP הפנימית של הצומת. כך אפשר לוודא שתנועת החזרה מנותבת בחזרה לצומת ואז מועברת אל ה-Pod המקורי.

ערימה כפולה (IPv4 ו-IPv6)

באשכול עם תמיכה כפולה בפרוטוקולים נעשה שימוש בפרוטוקולים IPv4 ו-IPv6. ‫GKE מקצה כתובות IPv4 ו-IPv6 לצמתים, ל-Pods ולשירותים באשכול דו-ערכי. המודל הזה מתאים במיוחד ל:

  • הקלה על מעבר הדרגתי ל-IPv6.
  • הבטחת תאימות לעומסי עבודה שמוכנים ל-IPv6 וללקוחות ולשירותים קיימים של IPv4 בלבד.

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

המאמרים הבאים