כדי ליצור אשכולות מאובטחים וניתנים להתאמה של Google Kubernetes Engine (GKE), צריך לנהל ביעילות את כתובות ה-IP. במאמר הזה נסביר איך GKE משתמש בכתובות IP לתקשורת באשכול, אילו מודלים של רשתות נתמכים ומהן השיטות המומלצות לניהול יעיל של כתובות IP.
המאמר הזה מיועד לאדריכלי ענן ולמומחי רשתות שמתכננים ומעצבים את הרשת של הארגון שלהם. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה ב- Google Cloudזמין במאמר תפקידים ומשימות נפוצים של משתמשי GKE Enterprise.
לפני שתמשיכו, חשוב שתכירו את המושגים הבאים:
- רשתות בסיסיות: כולל כתובות IP, CIDR, חומות אש ותרגום כתובות רשת (NAT).
- רכיבי ליבה של Kubernetes: כמו אשכולות, צמתים, Pods ושירותים.
איך כתובות IP מחברות בין רכיבי GKE
GKE מבוסס על מודל הרשת של Kubernetes, שבו לכל רכיב צריכה להיות כתובת IP נפרדת לתקשורת. בקטעים הבאים מוסבר איך GKE מקצה כתובות IP לרכיבי הליבה של האשכול ומשתמש בהן:
צמתים: GKE מקצה לכל צומת, שהוא מכונה וירטואלית של Compute Engine, כתובת IP פנימית מטווח כתובות ה-IP הראשי של רשת המשנה שמשויכת למאגר הצמתים שלו. כתובת ה-IP הזו מאפשרת תקשורת בין הצומת לבין מישור הבקרה של Kubernetes. לצמתים יכולה להיות גם כתובת IP חיצונית לגישה לאינטרנט.
Pods: בהתאם למודל IP-per-Pod של Kubernetes, GKE מקצה לכל Pod כתובת IP ייחודית מטווח ה-CIDR של ה-Pod שהוקצה לצומת. ב-GKE, רשת ה-VPC מנתבת באופן מקורי כתובות IP של Pods. יכולת הניתוב המובנית הזו מאפשרת תקשורת ישירה בין Pods, אפילו בין צמתים שונים, בלי צורך בתרגום כתובת רשת (NAT). כל הקונטיינרים ב-Pod אחד חולקים את אותה כתובת IP ויכולים לתקשר דרך
localhost.שירותים (
ClusterIP): GKE מקצה לכל שירותClusterIP,NodePortו-LoadBalancerכתובת IP וירטואלית פנימית יציבה (ClusterIP). לשירותי IPv4, GKE מקצה את הכתובת הזו מטווח כתובות IP משני ייעודי (או מהטווח34.118.224.0/20). בשירותי IPv6 (באשכולות IPv6 עם סטאק כפול וסטאק יחיד), GKE לא משתמש בטווח כתובות IP משני. במקום זאת, GKE מקצה כתובות מטווח כתובות ה-IPv6 הפרטיות שבבעלות Google, 2600:2D00:0:4::0:0/64.ClusterIPמספק נקודת קצה פנימית אחת ואמינה לקבוצה של Pods. כששולחים תנועה אלClusterIP, GKE מאזן את העומסים באופן אוטומטי ומפנה את התנועה לפוד תקין בתוך השירות.מישור הבקרה: באשכולות פרטיים, מישור הבקרה נמצא בפרויקט דייר (tenant) שמנוהל על ידי Google, ומשתמש בטווח כתובות IP פנימיות משלו. פרויקט הדייר הזה מתחבר לרשת ה-VPC שלכם, ומאפשר תקשורת מאובטחת בין מישור הבקרה לבין הצמתים ברשת ה-VPC של האשכול. בדרך כלל החיבור הזה משתמש ב-Private Service Connect.
מאזני עומסים: כדי לחשוף אפליקציות לאינטרנט או בתוך רשת ה-VPC, אתם יכולים להגדיר את GKE כך שישתמש במאזני עומסים שלGoogle Cloud . מאזני עומסים חיצוניים משתמשים בכתובות IP ציבוריות. מאזני עומסים פנימיים משתמשים בכתובות IP פנימיות מטווח רשת המשנה הראשי של רשת ה-VPC.
בטבלה הבאה מפורט איך GKE מקצה כתובות IP לרכיבי אשכול:
| רכיב | איך מוקצות כתובות IP |
|---|---|
| צומת | GKE מקצה כתובת IP פנימית לכל צומת. GKE מקצה את כתובת ה-IP הזו מטווח כתובות ה-IP הראשי של רשת המשנה שמשויכת למאגר הצמתים של הצומת. רשת המשנה הזו יכולה להיות רשת המשנה שמוגדרת כברירת מחדל באשכול, או רשת משנה נוספת. |
| Pod | GKE מקצה לכל Pod כתובת IP ייחודית מטווח ה-CIDR של ה-Pod שהוקצה לצומת שלו. |
| Service (ClusterIP) | GKE מקצה לכל שירות כתובת IP וירטואלית יציבה (ClusterIP). לשירותי IPv4, GKE מקצה את הכתובת הזו מטווח כתובות IP משני ייעודי ברשת ה-VPC של האשכול (או מ-34.118.224.0/20). לשירותי IPv6, GKE לא משתמש בטווח כתובות IP משני. במקום זאת, GKE מקצה כתובות מהטווח 2600:2D00:0:4::0:0/64. |
| מישור הבקרה | באשכולות פרטיים, למישור הבקרה של GKE יש טווח כתובות IP פנימי משלו בתוך פרויקט דייר (tenant) שמנוהל על ידי Google. הפרויקט של הדייר הזה מתחבר לרשת ה-VPC שלכם, בדרך כלל באמצעות Private Service Connect. |
| מאזן עומסים | מאזני עומסים חיצוניים משתמשים בכתובות IP ציבוריות. מאזני עומסים פנימיים משתמשים בכתובות IP פנימיות מטווח כתובות ה-IP הראשי של רשת המשנה של האשכול. |
כתובות IP ב-Kubernetes והטמעה ב-GKE
כדי להשתמש ב-GKE בצורה יעילה, חשוב להבין את ההבדלים בין מודל הרשת המופשט של Kubernetes לבין האופן שבו GKE מטמיע את המודל הזה ב- Google Cloud.
מודל כתובות ה-IP של Kubernetes: פרויקט הקוד הפתוח של Kubernetes מציין שכל Pod מקבל כתובת IP ייחודית. כל כתובות ה-IP של Pod יכולות לתקשר ישירות בלי תרגום כתובת רשת (NAT). הגישה הזו עוזרת להבטיח מרחב רשת שטוח שבו Pods יכולים להגיע זה לזה באמצעות כתובות ה-IP שהוקצו להם.
הטמעה של כתובות IP ב-GKE: ב-GKE, מודל כתובות ה-IP של Kubernetes מוטמע ב- Google Cloud באמצעות שילוב עם רשתות VPC-native. באשכולות IPv4 ובאשכולות עם שני סוגי כתובות, כשיוצרים פוד, GKE מקצה לו כתובת IP מטווח כתובות IP חלופיות של VPC. באשכולות IPv6 עם מחסנית אחת, GKE לא משתמש בטווחי כתובות IP חלופיות. במקום זאת, GKE מקצה כתובות IP לפודים ישירות מטווח משנה בצומת. כך אפשר לנתב באופן מקורי את כתובת ה-IP של כל Pod בתוך כל רשת ה-VPC. כך אפשר לתקשר ישירות לא רק בין Pods, אלא גם עם משאבים אחרים שלGoogle Cloud , כמו מכונות של Compute Engine ומסדי נתונים של Cloud SQL. באופן דומה, GKE מנהל את כתובות ה-IP של Kubernetes
Service(כמוClusterIP) בתוך רשת ה-VPC. כשיוצרים שירותיLoadBalancerלחשיפה חיצונית, GKE מקצה מאזני עומסים מסוגGoogle Cloud . מאזני העומסים האלה משתמשים בכתובות IP ציבוריות או פנימיות מרשת ה-VPC שלכם. GKE משתמש בתשתית החזקה של Google Cloudלהקצאת כתובות IP ולרישות, כדי להטמיע מושגים של רישות מבוסס-IP ב-Kubernetes באופן מאובטח וניתן להתאמה לעומס.
מודל הרשת של GKE: אשכולות המותאמים ל-VPC
ב-GKE, מודל הרשת של Kubernetes מיושם באמצעות רשתות VPC-native, שהיא יכולת ליבה של Google Cloud .
באשכולות IPv4 ובאשכולות עם שני סוגי כתובות IP, המודל הזה משתמש בטווחי כתובות IP חלופיות: באשכול המותאם ל-VPC, Kubernetes מגדיר כתובות IP של Pod כטווחי כתובות IP חלופיות בממשק הרשת הווירטואלית של הצומת. באשכולות IPv6 עם מחסנית אחת, טווחי כתובות ה-IP של הצמתים וה-Pod מוקצים ישירות מבלוק ה-CIDR של רשת המשנה, בלי להשתמש בטווחי כתובות IP חלופיות.
להטמעה הזו יש כמה יתרונות מרכזיים:
- ניתוב מותאם ל-VPC: אפשר לנתב ישירות כתובות IP של Pod בתוך רשת ה-VPC. כך קל יותר לתכנן את הרשת, ומתאפשרת תקשורת ישירה עם זמן אחזור קצר בין ה-Pods לבין משאבים אחרים של Google Cloud , כמו מכונות של Compute Engine ושל Cloud SQL.
- חיסכון במכסת המסלולים: כשמשתמשים בכתובות IP חלופיות ל-Pods, GKE לא יוצר מסלולים סטטיים בהתאמה אישית לכל צומת. כך נשמרת מכסת הנתיבים של ה-VPC, וזה שיפור משמעותי לעומת אשכולות מבוססי-נתיבים מדור קודם, שחשוב לפריסות בקנה מידה גדול.
- אבטחה משופרת: יכולת הניתוב של VPC-native מאפשרת להחיל כללי חומת אש של VPC-native ישירות על תנועת ה-Pod, וכך לשפר את האבטחה ברמת הרשת.
מצב הרשת המקורי של VPC הוא ברירת המחדל והמצב המומלץ לכל אשכולות GKE.
למה חשוב לנהל את כתובות ה-IP בצורה יעילה
כדי לוודא שהאשכול יוכל לגדול ולשמור על תקינות האפליקציה, צריך לתכנן את מרחב כתובות ה-IP בצורה יעילה:
- הבטחת יכולת התרחבות: תכננו ביעילות את טווחי כתובות ה-IP של הצמתים, ה-Pods והשירותים כדי למנוע ניצול מלא של כתובות ה-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.
אפשר להפעיל רשתות עם מחסנית כפולה כשיוצרים אשכול, או לעדכן אשכול קיים עם מחסנית IPv4 יחידה למחסנית כפולה.
IPv6 במחסנית יחידה (גרסת טרום-השקה)
באשכול IPv6 עם מחסנית אחת מוקצות רק כתובות IPv6 בכל מישור הנתונים של האשכול (פודים, צמתים ושירותים). המודל הזה עוקף את צווארי הבקבוק של מיצוי כתובות IPv4 פרטיות (RFC 1918), תוך שמירה על קישוריות מאובטחת של תעבורת נתונים נכנסת ויוצאת, פנימית או חיצונית. בניגוד לאשכולות IPv4 ואשכולות עם מחסנית כפולה שמשתמשים בטווחי כתובות IP חלופיות, אשכולות IPv6 עם מחסנית אחת מקצים /96 טווח משנה של כתובות IPv6 לכל צומת ישירות מרשת המשנה (/64), ומקצים טווח כתובות /112 ל-Pods בכל צומת. השירותים (ClusterIP) מקבלים כתובות מטווח כתובות IPv6 פרטיות שבבעלות Google (2600:2D00:0:4::0:0/64). אשכולות IPv6 עם סטאק יחיד תומכים גם בטווחי כתובות IPv6 מסוג BYOIP, שמוגדרים באמצעות תהליך BYOIPv6 EAP.
מידע נוסף על ההתנהגות וההקצאה של כתובות IPv6 במחסנית יחידה זמין במאמר יצירה וניהול של אשכולות IPv6 במחסנית יחידה.
המאמרים הבאים
- מידע נוסף על היתרונות של מצב ברירת המחדל של רשתות ב-GKE זמין במאמר מידע על אשכולות המותאמים ל-VPC.
- כדי להתחיל, קראו את המאמר יצירת אשכול המותאם ל-VPC.
- כדי ליצור אשכול IPv6 בלבד, קראו את המאמר יצירה וניהול של אשכולות IPv6 במחסנית יחידה.
- במאמר תכנון טווח כתובות IP לאשכולות המותאמים ל-VPC מוסבר איך לקבוע את הגודל של טווחי כתובות ה-IP של האשכול.
- לקבלת עזרה בנושא בעיות נפוצות, אפשר לעיין בקטע פתרון בעיות בסוכן הסתרת ה-IP.