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

בדף הזה מוסבר איך להגדיר אשכולות מקוריים של VPC ב-Google Kubernetes Engine ‏ (GKE).

מידע נוסף על היתרונות והדרישות של אשכולות המותאמים ל-VPC זמין בסקירה הכללית על אשכולות המותאמים ל-VPC.

באשכולות GKE Autopilot, רשתות מקומיות של VPC מופעלות כברירת מחדל ואי אפשר לשנות את ההגדרה הזו.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

מגבלות

• אי אפשר להמיר אשכול שמותאם ל-VPC לאשכול מבוסס-נתיבים, ואי אפשר להמיר אשכול מבוסס-נתיבים לאשכול שמותאם ל-VPC.

• אשכולות המותאמים ל-VPC דורשים רשתות VPC. אין תמיכה ברשתות מדור קודם.

• כמו בכל אשכול GKE, כתובות Service (ClusterIP) זמינות רק מתוך האשכול. אם אתם צריכים לגשת לשירות Kubernetes ממכונות וירטואליות מחוץ לאשכול, אבל בתוך רשת ה-VPC והאזור של האשכול, צרו מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.

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

יצירת אשכול

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

• ליצור אשכול ותת-רשת בו-זמנית.
• יצירת אשכול ברשת משנה קיימת.
• יוצרים אשכול ובוחרים את טווח כתובות ה-IP של מישור הבקרה.
• ליצור אשכול עם רשתות דו-ערכיות ברשת משנה חדשה (זמין באשכולות Autopilot מגרסה 1.25 ואילך, ובאשכולות רגילים מגרסה 1.24 ואילך).
• יצירה של אשכול עם תמיכה בשני פרוטוקולים ורשת משנה עם תמיכה בשני פרוטוקולים בו-זמנית (זמין באשכולות במצב Autopilot מגרסה 1.25 ואילך, ובאשכולות סטנדרטיים מגרסה 1.24 ואילך).

אפשר גם ליצור אשכול ולהפעיל בו ניהול אוטומטי של כתובות IP (בגרסת Preview). המשמעות היא ש-GKE יוצר באופן אוטומטי רשתות משנה ומנהל את כתובות ה-IP בשבילכם. מידע נוסף זמין במאמר בנושא שימוש בניהול אוטומטי של כתובות IP.

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

יצירה של אשכול ושל רשת משנה בו-זמנית

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

אם משתמשים ב-VPC משותף, אי אפשר ליצור את האשכול ואת רשת המשנה בו-זמנית. במקום זאת, אדמינים של הרשת בפרויקט המארח ב-VPC המשותף צריכים ליצור קודם את רשת המשנה. אחר כך תוכלו ליצור את האשכול ברשת משנה קיימת עם שיטת הקצאת טווח משני בניהול המשתמשים.

gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": SUBNET_NAME
  },
  ...
}

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

יצירת אשכול ברשת משנה קיימת

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

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 12.0"

  project_id        = "PROJECT_ID"
  name              = "CLUSTER_NAME"
  region            = "COMPUTE_LOCATION"
  network           = "NETWORK_NAME"
  subnetwork        = "SUBNET_NAME"
  ip_range_pods     = "SECONDARY_RANGE_PODS"
  ip_range_services = "SECONDARY_RANGE_SERVICES"
}

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

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

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

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

בקטעים הבאים מוסבר איך ליצור אשכול ולשנות את טווח רשת המשנה.

gcloud container clusters create CLUSTER_NAME \
    --enable-private-nodes \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

מטא-נתונים של פרויקט לטווחי כתובות IP משניות

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

מערכת GKE מנהלת את המטא-נתונים האלה באופן אוטומטי.

המטא-נתונים הם בפורמט הבא:

key:   gke-REGION-CLUSTER_NAME-GKE_UID-secondary-ranges
value: pods:SHARED_VPC_NETWORK:SHARED_VPC_SUBNETWORK:CLUSTER_PODS_SECONDARY_RANGE_NAME

where:

• ‫REGION: Cloud de Confiance by S3NS האזור שבו נמצא האשכול.

• ‫CLUSTER_NAME: השם של אשכול GKE.

• ‫GKE_UID: מזהה ייחודי של אשכול GKE.

• ‫VPC_NETWORK: השם של רשת ה-VPC שבה נעשה שימוש באשכול.

• ‫VPC_SUBNETWORK: השם של רשת המשנה ברשת ה-VPC שבה נעשה שימוש באשכול.

• ‫CLUSTER_PODS_SECONDARY_RANGE_NAME: השם של טווח כתובות ה-IP המשני שמשמש את ה-Pods של האשכול.

יצירת אשכול עם רשתות בעלות פרוטוקול כפול

אפשר ליצור אשכול עם רשת IPv4/IPv6 dual-stack ברשת משנה חדשה או קיימת של dual-stack. רשת משנה עם תמיכה ב-IPv4 ו-IPv6 זמינה באשכולות Autopilot בגרסה 1.25 ואילך, ובאשכולות Standard בגרסה 1.24 ואילך. אין תמיכה ברשתות משנה עם פרוטוקול כפול במאגרי צמתים של Windows Server.

לפני שמגדירים אשכולות עם תמיכה ב-IPv4 ו-IPv6, מומלץ לבצע את הפעולות הבאות:

• מידע נוסף על היתרונות והדרישות של אשכולות GKE עם רשתות דו-ערכיות.
• הגבלות ומגבלות של רשתות עם פרוטוקול כפול

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

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

   gcloud compute networks subnets create SUBNET_NAME \
       --stack-type=ipv4-ipv6 \
       --ipv6-access-type=ACCESS_TYPE \
       --network=NETWORK_NAME \
       --range=PRIMARY_RANGE \
       --region=COMPUTE_REGION
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫SUBNET_NAME: השם של תת-הרשת שבחרתם.
   • ‫ACCESS_TYPE: אפשרות הניתוב לאינטרנט הציבורי. משתמשים ב-INTERNAL לכתובות IPv6 פנימיות או ב-EXTERNAL לכתובות IPv6 חיצוניות. אם לא מציינים את --ipv6-access-type, סוג הגישה שמוגדר כברירת מחדל הוא EXTERNAL.
   • ‫NETWORK_NAME: השם של הרשת שתכיל את תת-הרשת החדשה. הרשת הזו צריכה לעמוד בתנאים הבאים:
     • היא חייבת להיות רשת VPC בהתאמה אישית. מידע נוסף זמין במאמר בנושא איך מעבירים רשת VPC ממצב אוטומטי למצב מותאם אישית.
     • אם מחליפים את ACCESS_TYPE ב-INTERNAL, הרשת חייבת להשתמש בכתובות IPv6 יוניקאסט מקומיות (ULA).
   • ‫PRIMARY_RANGE: טווח כתובות ה-IP הראשי של IPv4 עבור תת-הרשת החדשה, בסימון CIDR. מידע נוסף מופיע במאמר בנושא טווחים של רשתות משנה.
   • ‫COMPUTE_REGION: אזור המחשוב של האשכול.

2. כדי ליצור אשכול עם רשת משנה כפולה, משתמשים ב-gcloud CLI או במסוף Cloud de Confiance :

יצירה של אשכול ושל רשת משנה עם כתובות IPv4 ו-IPv6 בו-זמנית

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

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

• לגבי אשכולות של Autopilot, מריצים את הפקודה הבאה:

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --network=NETWORK_NAME \
      --create-subnetwork name=SUBNET_NAME
  

  מחליפים את מה שכתוב בשדות הבאים:

  • ‫CLUSTER_NAME: השם של אשכול Autopilot החדש.
  • ‫COMPUTE_LOCATION: המיקום של Compute Engine של האשכול.
  • ‫NETWORK_NAME: השם של רשת ה-VPC שמכילה את תת-הרשת. רשת ה-VPC הזו צריכה להיות רשת VPC במצב מותאם אישית שמשתמשת בכתובות ULA (כתובות יוניקאסט מקומיות ייחודיות) של IPv6. מידע נוסף זמין במאמר בנושא מעבר מרשת VPC במצב אוטומטי לרשת VPC במצב מותאם אישית.
  • ‫SUBNET_NAME: השם של תת-הרשת החדשה. ‫GKE יכול ליצור את תת-הרשת על סמך מדיניות הארגון:
    • אם מדיניות הארגון מאפשרת שימוש ב-dual-stack, והרשת היא במצב מותאם אישית, GKE יוצר רשת משנה מסוג dual-stack ומקצה לרשת המשנה טווח ראשי חיצוני של IPv6 .
    • אם מדיניות הארגון לא מאפשרת שימוש ב-dual-stack, או אם הרשת במצב אוטומטי, ‏ GKE יוצר רשת משנה (subnet) עם מחסנית אחת (IPv4).

• במקרה של אשכולות רגילים, מריצים את הפקודה הבאה:

  gcloud container clusters create CLUSTER_NAME \
      --enable-ip-alias \
      --stack-type=ipv4-ipv6 \
      --ipv6-access-type=ACCESS_TYPE \
      --network=NETWORK_NAME \
      --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
      --location=COMPUTE_LOCATION
  

  מחליפים את מה שכתוב בשדות הבאים:

  • ‫CLUSTER_NAME: השם של האשכול החדש שבחרתם.
  • ‫ACCESS_TYPE: האפשרות לניתוב לאינטרנט הציבורי. משתמשים ב-INTERNAL לכתובות IPv6 פנימיות או ב-EXTERNAL לכתובות IPv6 חיצוניות. אם לא מציינים את הערך --ipv6-access-type, סוג הגישה שמוגדר כברירת מחדל הוא EXTERNAL.
  • ‫NETWORK_NAME: השם של הרשת שתכיל את תת-הרשת החדשה. הרשת הזו צריכה לעמוד בתנאים הבאים:
    • היא חייבת להיות רשת VPC בהתאמה אישית. מידע נוסף זמין במאמר בנושא איך מעבירים רשת VPC ממצב אוטומטי למצב מותאם אישית.
    • אם מחליפים את ACCESS_TYPE ב-INTERNAL, הרשת חייבת להשתמש בכתובות IPv6 חד-שידור מקומיות ייחודיות (ULA).
  • ‫SUBNET_NAME: השם של תת-הרשת החדשה שבוחרים.
  • ‫PRIMARY_RANGE: טווח כתובות ה-IPv4 הראשי של תת-הרשת החדשה, בסימון CIDR. מידע נוסף מופיע במאמר בנושא טווחים של רשתות משנה.
  • ‫COMPUTE_LOCATION: המיקום של Compute Engine של האשכול.

עדכון סוג הערימה

אתם יכולים לשנות את סוג ה-stack של אשכול קיים או לעדכן רשת משנה קיימת לרשת משנה עם dual-stack.

עדכון סוג ה-stack באשכול קיים

לפני שמשנים את סוג ה-stack באשכול קיים, חשוב לקחת בחשבון את המגבלות הבאות:

• אפשר לשנות את סוג ה-stack באשכולות GKE חדשים שפועלת בהם גרסה 1.25 ואילך. יכול להיות שבאשכולות GKE ששודרגו מגרסה 1.24 לגרסה 1.25 או 1.26 יופיעו שגיאות אימות כשמפעילים רשת עם כתובות IPv4 ו-IPv6.

• שינוי סוג ה-stack הוא פעולה שגורמת לשיבוש, כי GKE מפעיל מחדש רכיבים במישור הבקרה ובצמתים.

• ‫GKE מכבד את חלונות הזמן לתחזוקה שהגדרתם כשיוצרים מחדש צמתים. המשמעות היא שסוג מחסנית האשכול לא יפעל באשכול עד לחלון זמן לתחזוקה הבא. אם אתם לא רוצים לחכות, אתם יכולים לשדרג את מאגר הצמתים באופן ידני על ידי הגדרת הדגל --cluster-version לאותה גרסת GKE שמישור הבקרה כבר פועל בה. אם משתמשים בפתרון העקיף הזה, צריך להשתמש ב-CLI של gcloud. מידע נוסף מופיע במאמר בנושא הערות לגבי חלונות תחזוקה.

• שינוי סוג הערימה לא משנה אוטומטית את משפחת ה-IP של שירותים קיימים. התנאים הבאים חלים:

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

כדי לעדכן אשכול קיים שמותאם ל-VPC, אפשר להשתמש ב-gcloud CLI או במסוף Cloud de Confiance :

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE \
      --location=COMPUTE_LOCATION

עדכון של רשת משנה קיימת לרשת משנה עם תמיכה כפולה (זמין באשכולות Autopilot בגרסה 1.25 ואילך, ובאשכולות Standard בגרסה 1.24 ואילך).

עדכון של רשת משנה קיימת לרשת משנה עם כתובות כפולות

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

gcloud compute networks subnets update SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --region=COMPUTE_REGION

מחליפים את מה שכתוב בשדות הבאים:

• ‫SUBNET_NAME: שם רשת המשנה.
• ‫ACCESS_TYPE: אפשרות הניתוב לאינטרנט הציבורי. משתמשים ב-INTERNAL לכתובות IPv6 פנימיות או ב-EXTERNAL לכתובות IPv6 חיצוניות. אם לא מציינים את --ipv6-access-type, סוג הגישה שמוגדר כברירת מחדל הוא EXTERNAL.
• ‫COMPUTE_REGION: אזור המחשוב של האשכול.

אימות סוג המערך, ה-Pod וטווח כתובות ה-IP של השירות

אחרי שיוצרים אשכול המותאם ל-VPC, אפשר לאמת את טווחי ה-Pod והשירות שלו.

gcloud container clusters describe CLUSTER_NAME

מחיקת האשכול

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

מערכת GKE מנסה לנקות את רשת המשנה שנוצרה כשמ删除ים את האשכול. אבל אם רשת המשנה נמצאת בשימוש של משאבים אחרים, GKE לא מוחק את רשת המשנה, ואתם צריכים לנהל את מחזור החיים של רשת המשנה בעצמכם.

הגדרה מתקדמת של כתובות IP פנימיות

בסעיפים הבאים מוסבר איך להשתמש בטווחים של כתובות IP פרטיות שאינן RFC 1918 ואיך להפעיל טווחים של כתובות IP ציבוריות לשימוש פרטי.

שימוש בטווחים של כתובות IP שהם לא RFC 1918

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

התכונה הזו לא נתמכת במאגרי צמתים של Windows Server.

טווחים פרטיים שאינם RFC 1918 הם טווחים של רשתות משנה – אפשר להשתמש בהם באופן בלעדי או בשילוב עם טווחים של רשתות משנה RFC 1918. צמתים, פודים ושירותים ממשיכים להשתמש בטווחים של רשתות משנה, כמו שמתואר בטווחים של כתובות IP לאשכולות מקוריים של VPC. אם אתם משתמשים בטווחים שאינם RFC 1918, חשוב לזכור את הנקודות הבאות:

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

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

יכול להיות שיהיה קשה ליעדים מחוץ לאשכול לקבל תנועה מטווחים פרטיים שאינם RFC 1918. לדוגמה, טווחים פרטיים של RFC 1112 (class E) משמשים בדרך כלל ככתובות מולטיקאסט. אם יעד מחוץ לאשכול לא יכול לעבד חבילות שהמקורות שלהן הם כתובות IP פרטיות מחוץ לטווח RFC 1918, אפשר לבצע את הפעולות הבאות:

• צריך להשתמש בטווח RFC 1918 לטווח כתובות ה-IP הראשי של תת-הרשת. כך, הצמתים באשכול משתמשים בכתובות RFC 1918.

• מוודאים שבאשכול פועל סוכן של הסתרת כתובת IP ושהיעדים לא מופיעים ברשימה nonMasqueradeCIDRs. כך, המקורות של מנות (packets) שנשלחות מ-Pods משתנים (SNAT) לכתובות של צמתים, שהן RFC 1918.

הפעלת טווחי כתובות IP חיצוניות לשימוש פרטי

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

האשכול חייב להיות אשכול המותאם ל-VPC כדי להשתמש בטווחים של כתובות IP חיצוניות לשימוש פרטי. אין תמיכה באשכולות מבוססי-נתיבים.

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

• כשמשתמשים בטווח כתובות IP חיצוניות כטווח של תת-רשת, האשכול לא יכול יותר לתקשר עם מערכות באינטרנט שמשתמשות בטווח החיצוני הזה. הטווח הופך לטווח כתובות IP פנימיות ברשת ה-VPC של האשכול.

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

כברירת מחדל, ב-GKE מופעל SNAT בצמתים ליעדי כתובות IP חיצוניות. אם הגדרתם את ה-CIDR של ה-Pod לשימוש בכתובות IP חיצוניות, כללי ה-SNAT חלים על תנועה מ-Pod ל-Pod. כדי להימנע מכך, יש 2 אפשרויות:

• יוצרים את האשכול באמצעות הדגל --disable-default-snat. פרטים נוספים על הדגל הזה זמינים במאמר בנושא הסתרת כתובות IP ב-GKE.
• מגדירים את configMap ip-masq-agent, כולל ברשימה nonMasqueradeCIDRs לפחות את Pod CIDR, ‏ Service CIDR ורשת המשנה של הצמתים.

באשכולות Standard, אם גרסת האשכול היא 1.14 ואילך, שתי האפשרויות יפעלו. אם גרסת האשכול שלכם מוקדמת מגרסה 1.14, אתם יכולים להשתמש רק באפשרות השנייה (הגדרה של ip-masq-agent).

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

• סקירה כללית על רשת GKE
• מידע נוסף על איזון עומסים פנימי
• מידע על הגדרת רשתות מורשות
• מידע נוסף על יצירת כללי מדיניות ברשת של אשכול