יצירה וניהול של אשכולות IPv6 עם מחסנית אחת

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

אתם יכולים להריץ עומסי עבודה בקונטיינרים בסביבת רשת IPv6 בלבד, כדי להימנע מניצול יתר של מרחב כתובות IPv4 פרטיות (RFC 1918). כשפורסים אשכול IPv6 עם מחסנית אחת, מקצים רק כתובות IPv6 לפודים, לצמתים ולשירותים, תוך שמירה על קישוריות נכנסת ויוצאת למשאבים פנימיים וחיצוניים.

סקירה כללית

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

באשכולות GKE עם מחסנית IPv6 יחידה, מקצים כתובות IPv6 רק במישור הנתונים של האשכול, ומסירים לחלוטין את המגבלות של כתובות IPv4. צומתי העובדים פועלים במכונות וירטואליות של Compute Engine עם מחסנית IPv6 יחידה, וה-Pods והשירותים מתקשרים באמצעות חיבורי IPv6.

הקצאת כתובות IP‏ (IPAM)

באשכולות IPv6 עם מחסנית אחת, כתובות IPv6 מוקצות ברשת המשנה, בצמתים, ב-Pods ובשירותים באמצעות גודלי הקידומות הבאים:

משאב קידומת של בלוק CIDR תיאור
רשת משנה /64 מוגדר כבלוק CIDR של רשת משנה עם IPv6 בלבד.
צומת /96 מוקצה באופן אוטומטי על ידי GKE מבלוק ה-CIDR של רשת המשנה, ומספק כ-4.29 מיליארד כתובות IPv6 ייחודיות לכל צומת.
Pod /112 מוקצה מקבוצת משנה של טווח המשנה /96 של הצומת.
שירות /64 מוקצה באופן אוטומטי על ידי GKE לשירותי ClusterIP מטווח כתובות ה-IPv6 של 2600:2D00:0:4::0:0/64.

סוגי גישה חיצוניים ופנימיים ל-IPv6

כשמגדירים את רשת המשנה של האשכול, אפשר לבחור בין שני סוגי גישה ל-IPv6 כדי לשלוט בניתוב לאינטרנט:

  • פנימי (ULA): רשתות משנה עם סוג הגישה INTERNAL משתמשות בכתובות Unique Local Unicast ‏(ULA) בטווח fd20::/20. התקשורת מוגבלת לרשת ה-VPC, לרשתות שכנות ולחיבורים היברידיים. צמתים ו-Pods לא יכולים להגיע ישירות למשאבי אינטרנט ציבוריים של IPv6 או לקבל תעבורת נתונים נכנסת ישירה מהאינטרנט.
  • חיצונית (GUA): רשתות משנה עם סוג הגישה EXTERNAL משתמשות בכתובות Global Unicast ‏(GUA). לצמתים ול-Pods מוקצות כתובות IPv6 ייחודיות באופן גלובלי, והם יכולים לתקשר עם משאבי אינטרנט ציבוריים של IPv6 גם בתעבורת נתונים נכנסת וגם בתעבורת נתונים יוצאת, בכפוף לכללי חומת האש של ה-VPC ולטבלאות הניתוב.

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

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

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

דרישות ומגבלות

כדי להשתמש באשכולות IPv6 עם מחסנית אחת, צריך לוודא שאתם עומדים בדרישות ובהגבלות הבאות:

  • באשכול צריכה לפעול גרסת GKE‏ 1.37.1-gke.3020000 ואילך.
  • האשכול צריך להיות אשכול המותאם ל-VPC שמשתמש ב-GKE Dataplane V2. אשכולות IPv6 עם מחסנית אחת לא תומכים באשכולות מבוססי-נתיבים.
  • אשכולות IPv6 עם מחסנית אחת תומכים רק במכונות וירטואליות של IPv6 עם מחסנית אחת כצומתי עובד, ולא תומכים במאגרי צמתים מעורבים או עם מחסנית כפולה.
  • אתם צריכים להשתמש ב-Cloud DNS כספק ה-DNS של האשכול (--cluster-dns=clouddns). אשכולות IPv6 עם מחסנית אחת לא תומכים ב-kube-dns.
  • הגישה למישור הבקרה באשכולות IPv6 עם מחסנית אחת משתמשת בשני נתיבים נפרדים:
    • לקוחות חיצוניים: לקוחות מחוץ לאשכול (לדוגמה, באמצעות kubectl) ניגשים למישור הבקרה דרך נקודת קצה (endpoint) מבוססת-דומיין באמצעות GKE Frontend‏ (GKFE).
    • עומסי עבודה פנימיים: צמתים ו-Pods מתחברים באופן מאובטח למישור הבקרה דרך Private Service Connect. כדי לתמוך בתקשורת הזו, צריך לספק או ליצור רשת משנה עם סוג גישה INTERNAL ל-IPv6‏ (--private-endpoint-subnetwork).
  • ברשתות משנה פנימיות (INTERNAL) של IPv6, צמתים ו-Pods יכולים להגיע ל-Google APIs ול-Artifact Registry דרך IPv6 בלי שער Cloud NAT. עם זאת, חשוב לזכור:
    • כדי להגיע לנקודות קצה חיצוניות של IPv4 בלבד (כמו מאגרי קונטיינרים חיצוניים של IPv4 בלבד), צריך להגדיר את DNS64 ו-Cloud NAT ‏(NAT64).
    • צמתים ו-Pods ברשתות משנה של INTERNAL לא יכולים להגיע לנקודות קצה (endpoints) ציבוריות חיצוניות של IPv6 מחוץ ל-Google, כי אי אפשר לנתב כתובות מקומיות ייחודיות (ULA) באינטרנט הציבורי של IPv6, ו-Cloud NAT לא תומך בתרגום IPv6 ל-IPv6 ‏(NAT66).
  • באשכולות IPv6 עם מחסנית אחת אין תמיכה בדגלי האשכול --private-ipv6-google-access-type ו---enable-private-nodes. במקום זאת, צריך להגדיר את הגישה הפרטית ל-Google ואת סוגי הגישה של IPv6‏ (INTERNAL או EXTERNAL) ישירות ברשת המשנה של ה-VPC.
  • אשכולות IPv6 עם מחסנית אחת לא תומכים בהגדרות של כמה רשתות משנה.
  • אשכולות IPv6 עם מחסנית אחת לא תומכים ב-GKE Ingress. כדי להגדיר מאזני עומסים של אפליקציות בשכבה 7, משתמשים ב-Gateway API.
  • ‫GKE multi-networking API לא תומך ברשתות Pod ב-IPv6. רשתות Pod משניות חייבות להיות ב-IPv4 בלבד. למידע נוסף, קראו את המאמר תמיכה בפודים בכמה רשתות.
  • אשכולות עם IPv6 בלבד לא תומכים ב-Cloud Service Mesh.
  • אתם יכולים להשתמש בכתובות IPv6 משלכם (BYOIPv6) באשכולות IPv6 עם מחסנית אחת. במאמר יצירה ושימוש בתחיליות משנה של IPv6 מוסבר על הדרישות שחלות על תחיליות BYOIPv6.

הגדרת שרת המטא-נתונים של עומס העבודה

עומסי עבודה שפועלים בפודים עם IPv6 בלבד לא יכולים להגיע לכתובת הסטנדרטית של שרת המטא-נתונים של IPv4‏ (169.254.169.254), לכן צריך לבצע את ההתאמות הבאות:

  • מגדירים את האפליקציות וספריות הלקוח כך שיוכלו לגשת לשרת המטא-נתונים באמצעות שם הדומיין metadata.google.internal (מומלץ) או כתובת ה-ULA IPv6 המילולית [fd20:ce::254].

  • אם אתם משתמשים בספריות לקוח או באפליקציות עם נקודות קצה של שרת מטא-נתונים ב-IPv4 בתוך הקוד (לדוגמה, גרסאות קודמות של ספריות לקוח של Google API), הגדירו את משתנה הסביבה GCE_METADATA_HOST בקובצי האימג' של הקונטיינרים או במפרטי ה-Pod:

    env:
- name: GCE_METADATA_HOST
  value: "metadata.google.internal"

יצירת אשכול IPv6 עם מחסנית אחת

אפשר ליצור אשכול IPv6 עם מחסנית אחת באמצעות Google Cloud CLI.

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

אם אין לכם רשתות משנה מותאמות אישית, אתם יכולים ליצור אשכול IPv6 עם מחסנית אחת ב-Standard, ולתת ל-GKE להקצות באופן אוטומטי את רשת המשנה הנדרשת של הצומת ואת --private-endpoint-subnetwork בפקודה אחת.

מריצים את הפקודה הבאה:

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME \
    --ipv6-access-type=ACCESS_TYPE \
    --location=COMPUTE_LOCATION

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

  • ‫CLUSTER_NAME: השם של האשכול החדש.
  • ‫VERSION: גרסת GKE‏ 1.37.1-gke.3020000 ואילך.
  • ‫NETWORK_NAME: השם של רשת VPC קיימת במצב בהתאמה אישית.
  • ‫SUBNET_NAME: השם של רשת המשנה החדשה של הצומת שרוצים ליצור.
  • ‫ACCESS_TYPE: יכולת הניתוב באינטרנט של רשת המשנה. מציינים INTERNAL לכתובות ULA פרטיות או EXTERNAL לכתובות GUA ציבוריות. אם לא מציינים ערך, ברירת המחדל היא EXTERNAL.
  • ‫COMPUTE_LOCATION: אזור ה-Compute או התחום של האשכול.

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

כדי להשתמש ברשתות משנה קיימות או בהתאמה אישית, צריך ליצור את רשת ה-VPC, את רשת המשנה של מישור הבקרה של PSC ואת רשת המשנה של הצומת לפני שיוצרים את האשכול.

  1. יוצרים רשת VPC במצב בהתאמה אישית עם כתובות IPv6 פנימיות מסוג ULA:

    gcloud compute networks create NETWORK_NAME \
    --subnet-mode=CUSTOM \
    --enable-ula-internal-ipv6

  2. יוצרים את רשת המשנה הייעודית של מישור הבקרה הפנימי של PSC:

    gcloud compute networks subnets create PSC_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=INTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    מחליפים את COMPUTE_REGION באזור שבו פורסים את האשכול (לדוגמה, us-central1). אפשר גם לציין את --stack-type=ipv4_ipv6 לרשת המשנה של מישור הבקרה של PSC.

  3. יוצרים את רשת המשנה של הצומת. בוחרים גישה פנימית (INTERNAL) או גישה חיצונית (EXTERNAL):

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  4. יוצרים את האשכול הסטנדרטי של IPv6 במחסנית יחידה, שמפנה לשתי רשתות המשנה:

    gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

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

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

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

  2. יוצרים את אשכול Autopilot:

    gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=VERSION \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

יצירת אשכול רגיל עם צמתים מנוהלים

אפשר גם ליצור אשכול Standard עם IPv6 במחסנית אחת, שמשתמש בצמתים מנוהלים שמוגדרים ברמת עומס העבודה. מידע נוסף על הגדרת ComputeClasses מנוהלים באשכולות Standard זמין במאמר מחלקות Autopilot באשכולות Standard.

שימוש בכתובות IPv6 משלכם לצמתים ול-Pods

אתם יכולים ליצור אשכול IPv6 עם מחסנית אחת, שהצמתים וה-Pods שלו משתמשים בכתובות IPv6 משלכם (BYOIPv6) במקום בכתובות ש-Google מספקת. כדי לעשות את זה, יוצרים את רשת המשנה של הצומת עם טווח כתובות IPv6 חיצוניות שמגיע מקידומת משנה אזורית של IPv6 של הקידומת שהוקצתה לציבור (PDP). לאחר מכן, הצמתים וה-Pods מקבלים כתובות IPv6 מהקידומת הזו ומתקשרים עם האינטרנט וביניהם באמצעות הכתובות האלה.

  1. יוצרים קידומת משנה אזורית של IPv6 לקידומת שהוקצתה באופן ציבורי במצב EXTERNAL_IPV6_SUBNETWORK_CREATION. מידע נוסף זמין במאמר יצירת קידומות משנה של IPv6.

  2. יוצרים את רשת המשנה של הצומת עם סוג גישה EXTERNAL IPv6 ומפנים לתחילית המשנה באמצעות הדגל --ip-collection. ‫Compute Engine מקצה את טווח כתובות ה-IPv6 של תת-הרשת /64 מהקידומת המשנית:

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=EXTERNAL \
    --ip-collection=SUB_PREFIX_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    מחליפים את SUB_PREFIX_NAME בשם של הקידומת המשנית שיצרתם בשלב הקודם. הקידומת המשנית צריכה להיות באותו אזור של רשת המשנה. כדי לבחור טווח /64 ספציפי מהקידומת המשנית במקום לאפשר ל-Compute Engine להקצות טווח, מוסיפים את הדגל --external-ipv6-prefix.

  3. יוצרים את האשכול ברשת המשנה הזו של הצומת לפי השלבים שמפורטים במאמר יצירת אשכול Standard ברשתות משנה בהתאמה אישית או יצירת אשכול Autopilot ברשתות משנה בהתאמה אישית. רשת המשנה של מישור הבקרה של PSC לא צריכה טווח כתובות BYOIPv6.

  4. אחרי ש-GKE יוצר את האשכול, מוודאים שלצמתים ול-Pods יש כתובות IPv6 מהקידומת שלכם:

    kubectl get nodes -o wide
kubectl get pods --all-namespaces -o wide

חשוב לזכור:

  • בתהליך הזה משתמשים ברשת משנה של צמתים עם סוג הגישה EXTERNAL ל-IPv6, כך שהצמתים וה-Pods מקבלים כתובות שניתנות לניתוב גלובלי מהקידומת שלכם. אפשר גם להשתמש ברשת משנה של צמתים עם סוג הגישה INTERNAL ל-IPv6, על ידי הפניה לקידומת משנה במצב INTERNAL_IPV6_SUBNETWORK_CREATION. במקרה כזה, הצמתים וה-Pods מקבלים כתובות BYOIPv6 פנימיות, וחלות מגבלות הקישוריות של סוג הגישה הפנימית ל-IPv6. מידע נוסף זמין במאמר חיבור למשאבים חיצוניים ופרטיים.
  • כדי לחשוף עומסי עבודה בכתובות BYOIPv6 עם שירותי LoadBalancer, קראו את המאמר העברת כתובות IPv6 משלכם (BYOIPv6), שלא דורשת רשת משנה של צומת BYOIPv6.
  • הדרישות שחלות על קידומות BYOIPv6 מפורטות במאמר יצירה ושימוש בקידומות משנה של IPv6.

אימות סוג המחסנית של האשכול

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

gcloud beta container clusters list

הפלט מאשר שהעמודה STACK_TYPE מוגדרת ל-IPV6:

NAME               LOCATION       MASTER_VERSION      MASTER_IP                                 MACHINE_TYPE  NODE_VERSION        NUM_NODES  STACK_TYPE  STATUS
v6-only-cluster-1  us-central1-c  1.37.0-gke.1000000  gke-3a3234-123456.us-central1-c.gke.goog  e2-medium     1.37.0-gke.1000000  1          IPV6        RUNNING

איזון עומסים באשכולות IPv6 עם מחסנית אחת

אתם יכולים לחשוף אפליקציות שפועלות בתוך אשכולות IPv6 עם מחסנית אחת, באמצעות מאזני עומסים בשכבה 7 ובשכבה 4:

  • איזון עומסים של אפליקציות בשכבה 7 (Gateway API): משתמשים ב-Kubernetes Gateway API כדי לפרוס מאזני עומסים של אפליקציות בשכבה 7 (gke-l7-rilb,‏ gke-l7-regional-external-managed או gke-l7-global-external-managed). שערי ה-Gateway האלה יכולים לשרת לקוחות IPv4 ו-IPv6 פנימיים וחיצוניים, תוך ניתוב התנועה באופן שקוף לנקודות קצה פנימיות של פודים עם IPv6 בלבד. שימו לב ש-GKE Ingress לא נתמך באשכולות IPv6 עם מחסנית יחידה. כשפורסים שערים אזוריים (gke-l7-rilb ו-gke-l7-regional-external-managed) באשכולות IPv6 עם מחסנית אחת, חשוב לזכור את הדרישות הבאות לגבי רשתות משנה:

    • רשת משנה של שרת proxy בלבד: באשכולות IPv6 עם מחסנית אחת, רשת המשנה האזורית של שרת proxy בלבד (--purpose=REGIONAL_MANAGED_PROXY) חייבת להיות עם מחסנית כפולה (--stack-type=IPV4_IPV6). באשכולות IPv4 בלבד ובאשכולות עם מחסנית כפולה, רשת המשנה יכולה להיות IPv4 בלבד או עם מחסנית כפולה.
    • רשת משנה של VIP לשער: בניגוד לשערים חיצוניים אזוריים של IPv4 (שלא מקצים כתובות VIP מרשת משנה), שערים חיצוניים אזוריים של IPv6 (gke-l7-regional-external-managed) דורשים רשת משנה עם גישה ל-IPv6 (EXTERNAL), ושערים פנימיים אזוריים (gke-l7-rilb) דורשים רשת משנה עם גישה ל-IPv6 (INTERNAL) (או טווח IPv4 ל-VIP פנימי של IPv4). כדי להקצות כתובת VIP זמנית של שער אזורי מרשת משנה בהתאמה אישית במקום מרשת המשנה של הצומת של האשכול, מציינים את שם רשת המשנה בשדה spec.default.subnetwork של GCPGatewayPolicy שמצורף לשער.

    להוראות הגדרה, ראו פריסת שערים.

  • איזון עומסים של מעבר בשכבה 4 (Service API): אתם יכולים לחשוף עומסי עבודה ללקוחות IPv6 באמצעות שירותי Kubernetes שמוגדרים עם type: LoadBalancer. בהתאם לסוג רשת המשנה שבה פועלים הצמתים באשכול, INTERNAL (ULA) או EXTERNAL (GUA), יכול להיות שתצטרכו להקצות רשת משנה ייעודית למאזן העומסים ולהפנות אליה באמצעות ההערה networking.gke.io/load-balancer-subnet:

חיבור למשאבים חיצוניים ופרטיים

עומסי עבודה באשכול IPv6 עם מחסנית אחת צריכים בדרך כלל לתקשר עם שירותים חיצוניים באינטרנט או עם שירותים פרטיים ב- Google Cloud.

התחברות למשאבי אינטרנט ציבוריים ב-IPv6

אם הצמתים באשכול פועלים ברשת משנה שמוגדרת עם סוג הגישה EXTERNAL ל-IPv6‏ (--ipv6-access-type=EXTERNAL), כברירת מחדל מופעלת קישוריות יוצאת ונכנסת לנקודות קצה (endpoints) של IPv6 באינטרנט הציבורי. מוודאים שהכללים של חומת האש ב-VPC מאפשרים את תעבורת הנתונים הנדרשת ב-IPv6. מידע נוסף זמין במאמר שימוש בכללים של חומת האש ב-VPC.

התחברות למשאבי אינטרנט ציבוריים ב-IPv4‏ (DNS64 ו-NAT64)

מכיוון של-Pods באשכול IPv6 עם מחסנית אחת יש רק כתובות IPv6, כדי להתחבר לנקודות קצה ציבוריות באינטרנט עם IPv4 בלבד נדרש תרגום רשת. אתם יכולים להגדיר את Cloud DNS ו-Cloud NAT ברשת ה-VPC כדי לספק תרגום אוטומטי של DNS64 ו-NAT64:

  1. יוצרים מדיניות שרת DNS64:

    gcloud dns policies create POLICY_NAME \
    --description="DNS64 policy for single-stack IPv6 cluster" \
    --networks=NETWORK_NAME \
    --enable-dns64-all-queries

  2. יוצרים Cloud Router באזור שבו האשכול פרוס:

    gcloud compute routers create ROUTER_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  3. יוצרים שער Cloud NAT שמוגדר לתרגום NAT64:

    gcloud compute routers nats create NAT_NAME \
    --router=ROUTER_NAME \
    --region=COMPUTE_REGION \
    --auto-allocate-nat-external-ips \
    --nat64-all-v6-subnet-ip-ranges

    כדי להגדיר NAT64 עם רשתות משנה ספציפיות או כתובות IP חיצוניות ידניות, צריך להשתמש ב---nat64-custom-v6-subnet-ip-ranges וב---nat-external-ip-pool.

מידע נוסף על תרגום כתובות זמין במאמרים הגדרת DNS64 ו-NAT64 ו-DNS64 ו-NAT64 לקישוריות 6to4.

חיבור לשירותים פרטיים באמצעות Private Service Connect

‫Private Service Connect ‏(PSC) תומך בתרגום כתובות מ-IPv6 ל-IPv4 בנקודות קצה ובכללי העברה. אתם יכולים לחבר עומסי עבודה באשכול IPv6 עם מחסנית אחת ל Google Cloud שירותים מנוהלים (כמו מכונות Cloud SQL) או לשירותים של ספקים מצד שלישי:

  1. שומרים כתובת IPv6 פנימית סטטית מרשת המשנה של ה-PSC של האשכול:

    gcloud compute addresses create ADDRESS_NAME \
    --ip-version=IPV6 \
    --subnet=PSC_SUBNET_NAME \
    --region=COMPUTE_REGION

  2. יוצרים כלל העברה של נקודת קצה (endpoint) מסוג PSC שמטרגט את צירוף השירות:

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --address=ADDRESS_NAME \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --target-service-attachment=SERVICE_ATTACHMENT_URL \
    --allow-psc-global-access

  3. אחזור של כתובת ה-IPv6 שהוקצתה:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
    --region=COMPUTE_REGION \
    --format='value(IPAddress)'

  4. משתמשים בכתובת ה-IPv6 שאוחזרה במחרוזות החיבור של האפליקציה. ‫PSC מתרגם את התנועה כדי שהפודים של IPv6 יוכלו להגיע בצורה מאובטחת לשירותים מנוהלים של IPv4 או של סטאק כפול.

מידע נוסף על צריכת שירותים שפורסמו זמין במאמרים יצירת נקודת קצה (endpoint) של Private Service Connect והתחברות ל-Cloud SQL באמצעות Private Service Connect. כדי לפרסם שירות LoadBalancer פנימי שפועל באשכול שלכם לצרכנים ברשתות VPC אחרות באמצעות משאב ServiceAttachment, קראו את המאמר יצירת מאזן עומסים פנימי באמצעות Private Service Connect.

הגדרות רשת מתקדמות ומאיצים

אתם יכולים להגדיר אשכולות IPv6 עם מחסנית אחת וממשקי רשת משניים למאגרי צמתים של מאיצים ול-Pods עם כמה רשתות.

רשתות של מאיצי חומרה עם כמה כרטיסי רשת (multi-NIC)

באשכולות IPv6 רגילים עם מחסנית אחת, אפשר לצרף רשתות נתונים משניות (RDMA או DIORITE) למאגרי צמתים של מאיצים (GPU ו-TPU) באמצעות רשתות אוטומטיות (--accelerator-network-profile=auto) או הגדרה ידנית של כמה רשתות (--additional-node-network). ממשקים משניים יכולים לפעול ברשתות משנה של IPv4, ברשתות משנה עם מחסנית כפולה או ברשתות משנה של IPv6 בלבד.

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

תמיכה במספר רשתות ל-Pods

אשכולות IPv6 עם מחסנית אחת תומכים בריבוי רשתות לפודים עם המאפיינים הבאים:

  • ממשק הרשת הראשי של Pod‏ (eth0) משתמש ברשת IPv6 עם מחסנית אחת.
  • ממשקי רשת נוספים של Pod חייבים להיות מסוג IPv4 בלבד (רשתות VPC בשכבה 3). אשכולות IPv6 עם מחסנית אחת לא תומכים ברשתות Pod מסוג IPv6 בממשקי רשת נוספים.
  • ההערה networking.gke.io/default-interface Pod מגדירה את ממשק ברירת המחדל לתנועת IPv4 בלבד. לא מוגדר ממשק ברירת מחדל לתנועת IPv6.

במאמר הגדרת תמיכה בכמה רשתות ל-Pods באשכולות IPv6 עם מחסנית יחידה מוסבר איך להגדיר רשתות Pod משניות של IPv4 שמגובות ברשתות משנה של VPC.

מעבר לאשכולות IPv6 עם מחסנית אחת

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

  1. בדיקת יחסי תלות: מוודאים שההגדרות של האפליקציות, ספריות הלקוח והסוכנים משתמשים בשמות DNS (כמו metadata.google.internal) ולא בכתובות IPv4 בתוך הקוד. אם צריך, מגדירים את GCE_METADATA_HOST.
  2. הקצאת אשכול ירוק: פריסת אשכול IPv6 חדש עם מחסנית אחת לצד האשכול הקיים, באותה רשת VPC או ברשת VPC מקושרת. מוודאים שכללי ההעברה של Cloud DNS,‏ DNS64,‏ Cloud NAT (NAT64) ו-PSC מוגדרים.
  3. פריסת עומסי עבודה: מחילים את המניפסטים של Kubernetes על האשכול הירוק, ומוודאים שה-Pods מתחילים ומתקשרים בהצלחה.
  4. העברת תנועה: משתמשים במאזני העומסים (מדיניות הניתוב של Gateway API או Cloud DNS) כדי להעביר בהדרגה את התנועה מהאשכול הקודם לאשכול החדש עם IPv6, תוך מעקב אחרי המדדים ושיעורי השגיאות.
  5. הוצאה משימוש של האשכול הקודם: אחרי שכל התנועה הועברה והאשכול הירוק אומת כיציב, מרוקנים ומוחקים את האשכול הישן.

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