כדי ליצור אשכולות מאובטחים וניתנים להתאמה של Google Kubernetes Engine (GKE), צריך לנהל ביעילות את כתובות ה-IP. במאמר הזה מוסבר בצורה מקיפה איך GKE משתמש בכתובות IP לתקשורת בין אשכולות, מהם מודלים הרשת הנתמכים ומהן שיטות מומלצות לניהול יעיל של כתובות IP.
המאמר הזה מיועד לארכיטקטים של ענן ולמומחי רשתות שתפקידם לתכנן את הרשת של הארגון שלהם. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה ב- Cloud de Confiance by S3NSזמין במאמר תפקידים ומשימות נפוצים של משתמשי GKE Enterprise.
לפני שממשיכים, חשוב להכיר את המושגים הבאים:
- ידע בסיסי ברשתות: כולל כתובות IP, CIDR, חומות אש ותרגום כתובות רשת (NAT).
- רכיבי ליבה של Kubernetes: כמו clusters, nodes, Pods ו-Services.
איך כתובות IP מחברות בין רכיבי GKE
GKE מבוסס על מודל הרשת של Kubernetes, שבו כל רכיב צריך כתובת IP נפרדת כדי לתקשר. בקטעים הבאים מוסבר איך GKE מקצה כתובות IP לרכיבי הליבה של האשכול ומשתמש בהן:
צמתים: GKE מקצה לכל צומת, שהוא מופע של מכונה וירטואלית ב-Compute Engine, כתובת IP פנימית מטווח כתובות ה-IP הראשי של רשת המשנה שמשויכת למאגר הצמתים. כתובת ה-IP הזו מאפשרת תקשורת בין הצומת לבין מישור הבקרה של Kubernetes. לצמתים יכולה להיות גם כתובת IP חיצונית לגישה לאינטרנט.
Pod: בהתאם למודל IP-per-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 מאזן את העומסים באופן אוטומטי ומעביר את התנועה לפוד תקין בתוך השירות.מישור הבקרה: באשכולות פרטיים, מישור הבקרה נמצא בפרויקט דייר שמנוהל על ידי Google, ומשתמש בטווח כתובות IP פנימי משלו. פרויקט הדייר הזה מתחבר לרשת ה-VPC שלכם, ומאפשר תקשורת מאובטחת בין מישור הבקרה לבין הצמתים ברשת ה-VPC של האשכול. בדרך כלל החיבור הזה משתמש ב-Private Service Connect.
מאזני עומסים: כדי לחשוף אפליקציות לאינטרנט או בתוך רשת ה-VPC, אתם יכולים להגדיר את GKE כך שישתמש במאזני עומסים שלCloud de Confiance by S3NS . מאזני עומסים חיצוניים משתמשים בכתובות IP ציבוריות. מאזני עומסים פנימיים משתמשים בכתובות 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 של האשכול. |
| Control plane | באשכולות פרטיים, למישור הבקרה של GKE יש טווח כתובות IP פנימיות משלו בתוך פרויקט דייר (tenant) שמנוהל על ידי Google. פרויקט הדייר הזה מתחבר לרשת ה-VPC שלכם, בדרך כלל באמצעות Private Service Connect. |
| מאזן עומסים | מאזני עומסים חיצוניים משתמשים בכתובות IP ציבוריות. מאזני עומסים פנימיים משתמשים בכתובות IP פנימיות מטווח כתובות ה-IP הראשי של רשת המשנה של האשכול. |
כתובות IP ב-Kubernetes והטמעה ב-GKE
כדי להשתמש ב-GKE בצורה יעילה, צריך להבין את ההבדלים בין מודל הרשתות המופשט של Kubernetes לבין האופן שבו GKE מיישם את המודל הזה ב- Cloud de Confiance by S3NS.
מודל הקצאת כתובות IP ב-Kubernetes: פרויקט Kubernetes בקוד פתוח מציין שכל Pod מקבל כתובת IP ייחודית. כל כתובות ה-IP של Pod יכולות לתקשר ישירות בלי תרגום כתובת רשת (NAT). הגישה הזו עוזרת להבטיח מרחב רשת שטוח שבו Pods יכולים להגיע אחד לשני באמצעות כתובות ה-IP שהוקצו להם.
הטמעה של הקצאת כתובות IP ב-GKE: GKE מטמיע את מודל הקצאת כתובות IP של Kubernetes ב- Cloud de Confiance by S3NS על ידי שילוב עם רישות מקורי של VPC. כשיוצרים Pod, GKE מקצה לו כתובת IP מטווח כתובות IP חלופיות של VPC. כך אפשר לנתב את כתובת ה-IP של כל Pod באופן מקורי בכל רשת ה-VPC. החיבור הזה מאפשר תקשורת ישירה לא רק בין ה-Pods, אלא גם עם משאבים Cloud de Confiance by S3NS אחרים, כמו מכונות וירטואליות של Compute Engine ומסדי נתונים של Cloud SQL. באופן דומה, GKE מנהל את כתובות ה-IP של Kubernetes
Service(כמוClusterIP) בתוך רשת ה-VPC. כשיוצרים שירותיLoadBalancerלחשיפה חיצונית, GKE מקצה מאזני עומסים (Load Balancers) מסוגCloud de Confiance by S3NS . מאזני העומסים האלה משתמשים בכתובות IP ציבוריות או פנימיות מרשת ה-VPC שלכם. GKE משתמש Cloud de Confiance by S3NSבתשתית חזקה של הקצאת כתובות IP ורישות כדי להטמיע מושגים של רישות מבוסס-IP של Kubernetes באופן ניתן להרחבה ומאובטח.
מודל הרישות של GKE: אשכולות המותאמים ל-VPC
GKE מטמיע את מודל הרשת של Kubernetes באמצעות רשתות מקוריות של VPC, שהן יכולת ליבה Cloud de Confiance by S3NS .
המודל הזה משתמש בטווחי כתובות IP חלופיות. באשכול המותאם ל-VPC, Kubernetes מגדיר את כתובות ה-IP של Pod כטווחי כתובות IP חלופיות בממשק הרשת הווירטואלית של הצומת.
להטמעה הזו יש כמה יתרונות מרכזיים:
- ניתוב מקורי של VPC: אפשר לנתב את כתובות ה-IP של הפודים ישירות ברשת ה-VPC. כך קל יותר לתכנן את הרשת, ומתאפשרת תקשורת ישירה עם זמן אחזור קצר בין ה-Pods לבין משאבים אחרים של Cloud de Confiance by S3NS , כמו מכונות של Compute Engine ומכונות של Cloud SQL.
- חיסכון במכסת המסלולים: כשמשתמשים בכתובות IP חלופיות ל-Pods, GKE לא יוצר מסלולים סטטיים בהתאמה אישית לכל צומת. כך נשמרת מכסת הנתיבים של ה-VPC, וזה שיפור משמעותי לעומת אשכולות מבוססי-נתיבים מדור קודם. השיטה הזו חשובה לפריסות בקנה מידה גדול.
- שיפור האבטחה: אפשרות הניתוב המובנית ב-VPC מאפשרת להחיל כללי חומת אש מובנים ב-VPC ישירות על התנועה ב-Pod, וכך לשפר את האבטחה ברמת הרשת.
מצב הרשת VPC-native הוא ברירת המחדל והמצב המומלץ לכל אשכולות GKE.
למה ניהול יעיל של כתובות IP הוא קריטי
כדי לוודא שהאשכול יכול להתרחב ולשמור על תקינות האפליקציה, צריך לתכנן את מרחב כתובות ה-IP בצורה יעילה:
- הבטחת יכולת התרחבות: תכננו את טווחי כתובות ה-IP של הצמתים, הפודים והשירותים בצורה יעילה כדי למנוע ניצול מלא של כתובות ה-IP, ולאפשר לאשכול להתרחב בלי לשבש את הארכיטקטורה של הרשת.
- הבטחת אמינות: כדי למנוע חפיפה בטווח כתובות ה-IP בין אשכול GKE לבין רשתות אחרות, כמו סביבות מקומיות שמחוברות דרך Cloud VPN. טווחים חופפים עלולים לגרום להתנגשויות בניתוב, להתנהגות בלתי צפויה ולשיבושים בשירות.
- שיפור האבטחה: ניהול יעיל של כתובות IP כדי לשפר את אבטחת הרשת. הגדרת מדיניות רשת ב-Kubernetes כדי לשלוט בתעבורת נתונים בין Pods והגדרת כללי חומת אש לבידוד עומסי עבודה ברמת הרשת.
בחירת מודל הקצאת כתובות IP לאשכול
GKE תומך בכמה הגדרות של מקבצי רשת (network stack) כדי לעמוד בדרישות הרשת שלכם, כולל IPv4 בלבד, סטאק כפול (IPv4 ו-IPv6) ואפשרויות של IPv6 בלבד שיהיו זמינות בקרוב.
IPv4 בלבד (מחסנית אחת)
זו ההגדרה הרגילה והנפוצה ביותר, שבה כל רכיבי האשכול משתמשים בכתובות IPv4. גם במודל IPv4 בלבד, GKE מספק גמישות:
- כתובות IP פרטיות מסוג RFC 1918: שימוש בטווחי כתובות IP פרטיות מסוג RFC 1918 (לדוגמה,
10.0.0.0/8) באשכול. - כתובות IP ציבוריות לשימוש פרטי (PUPI): אם לארגון שלכם אין מספיק מרחב כתובות IP פרטיות, אתם יכולים להשתמש בטווחים של כתובות IP ציבוריות לשימוש פנימי ברשת ה-VPC. כשמשתמשים ב-PUPI, צריך להגדיר את סוכן הסתרת ה-IP. הסוכן הזה מבצע תרגום כתובת רשת (SNAT) של המקור בתנועה יוצאת (outbound) מה-Pods. בלי SNAT, תעבורת הנתונים שחוזרת ל-Pod שמשתמש ב-PUPI מנותבת דרך האינטרנט הציבורי ונכשלת. סוכן הסתרת ה-IP מונע את זה על ידי שינוי כתובת ה-IP של המקור של חבילות הנתונים היוצאות, מכתובת ה-PUPI של ה-Pod לכתובת ה-IP הפנימית של הצומת. כך אפשר לוודא שתנועת החזרה מנותבת בצורה נכונה חזרה לצומת, ואז מועברת ל-Pod המקורי.
מערך כפול (IPv4 ו-IPv6)
באשכול עם תמיכה כפולה בפרוטוקולים נעשה שימוש בפרוטוקולים IPv4 ו-IPv6. GKE מקצה גם כתובת IPv4 וגם כתובת IPv6 לצמתים, לפודים ולשירותים באשכול עם סטאק כפול. המודל הזה מתאים במיוחד ל:
- הקלה על מעבר הדרגתי ל-IPv6.
- תאימות גם לעומסי עבודה שתומכים ב-IPv6 וגם ללקוחות ולשירותים קיימים שתומכים רק ב-IPv4.
אפשר להפעיל רשתות עם מחסנית כפולה כשיוצרים אשכול, או לעדכן אשכול קיים עם מחסנית אחת למחסנית כפולה.
המאמרים הבאים
- מידע נוסף על היתרונות של מצב הרשת שמוגדר כברירת מחדל ב-GKE זמין במאמר מידע על אשכולות מקוריים של VPC.
- כדי להתחיל, כדאי ללמוד איך ליצור אשכול מקורי של VPC.
- במאמר תכנון טווח כתובות IP לאשכולות המותאמים ל-VPC מוסבר איך לקבוע את הגודל של טווחי כתובות ה-IP של האשכול.
- לקבלת עזרה בפתרון בעיות נפוצות, אפשר לעיין במאמר בנושא פתרון בעיות ב-IP Masquerade Agent.