שערי Cloud NAT לאשכולות רגילים

‫Google Distributed Cloud‏ (GDC) עם בידוד פיזי תומך באשכולות רגילים, באשכול Kubernetes בשירות עצמי עם פרויקט יחיד שמנוהל על ידי קבוצת מפעילים של אפליקציות ומציע גמישות רבה יותר לעומסי עבודה בהתאמה אישית. בדף הזה מוסבר איך להגדיר Cloud NAT לאשכולות רגילים, ומתוארות כמה מגבלות על הגדרות NAT לסוג האשכול הזה.

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

לפני שמגדירים שער, צריך לקבל הרשאות מתאימות לניהול זהויות והרשאות גישה (IAM), לוודא שלפרויקט יש מדיניות רשת מתאימה ולהפעיל תעבורת נתונים יוצאת (egress).

פרטים נוספים מופיעים במאמר לפני שמתחילים להשתמש ב-Cloud NAT.

שער Cloud NAT משתמש ברשתות משנה חיצוניות leaf כקלט. מידע נוסף על הגדרת רשתות משנה חיצוניות ל-Cloud NAT זמין במאמר יצירת רשתות משנה חיצוניות ל-Cloud NAT.

סקירה כללית

תרשים שמציג הגדרה של שער Cloud NAT לאשכול רגיל

אפשר להגדיר שערי Cloud NAT לטיפול בתעבורת נתונים יוצאת (egress) עבור עומסי העבודה שפועלים באשכולות רגילים בשתי דרכים:

  • שער בהיקף פרויקט: שער שחל על כל תנועת העומסים באשכולות בפרויקט, כולל כל האשכולות המשותפים והרגילים. זו ההגדרה שמתוארת במאמר יצירת שער Cloud NAT.
  • שער בהיקף אשכול: שער שחל רק על עומסי עבודה באשכול רגיל יחיד שצוין. זהו סוג השער שמוצג בדף הזה.

שתי השיטות האלה מיועדות באופן בלעדי לעומסי עבודה, והן לא חלות על הצמתים שמרכיבים אשכול רגיל. כדי להפעיל Cloud NAT עבור הצמתים שמרכיבים אשכול רגיל, מוסיפים את התווית cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" לאובייקט של האשכול הרגיל.

יצירת שער Cloud NAT

תהליך היצירה של שער לאשכול רגיל נשאר זהה לתהליך היצירה של כל שער Cloud NAT בהיקף פרויקט.

במקרה הזה, אנחנו מתמקדים ביכולת הסינון של אשכולות עבור Cloud NAT של אשכול רגיל, ויוצרים הגדרה שדומה לתרחיש הראשון, אבל מציינים את השם של האשכול הרגיל user-vc-1 שבו נמצאות נקודות הקצה שינתבו את התנועה דרך השער. כתוצאה מכך, השער הזה יהיה בהיקף של האשכול הספציפי הזה.

apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  namespace: project-1
  name: gateway-1
spec:
  workloadSelector:    # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: user-vc-1
  subnetRefs:           # Mutable
  - subnet-1
  - subnet-2

ההגדרה הזו תבחר את כל עומסי העבודה עם התוויות app: aa בכל מרחבי השמות באשכול הרגיל user-vc-1.

בדיקת הסטטוס של שער התשלומים

מריצים את הפקודה kubectl הבאה כדי לבדוק את הסטטוס של השערים.

export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
kubectl get cloudnatgateways gateway-1 -n project-1 --kubeconfig "${MGMT_KUBECONFIG:?}"

אם ההגדרה תקינה, בשדה של תנאי הסטטוס של שער Cloud NAT אמור להופיע התנאי מהסוג Ready שהוגדר לערך true, ורשתות המשנה אמורות להיות מסומנות בערך OK, כמו שמוצג בפלט לדוגמה הבא:

apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  namespace: project-1
  name: gateway-1
spec:
  workloadSelector:       # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: user-vc-1
  subnetRefs:       # Mutable
  - subnet-1
  - subnet-2
status:
  conditions:
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: SubnetsReady
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: PerimeterConfigurationReady
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: EgressRoutesReady
  subnets:
  - name: subnet-1
    status: OK
  - name: subnet-2
    status: OK

תנועת בדיקה

כדי לבדוק את תעבורת הנתונים, מריצים פקודת curl מאחד הפודים או המכונות הווירטואליות שהוקצו לשער באשכול הרגיל, לכיוון נקודת קצה חיצונית. נקודת הקצה המקבלת אמורה לראות חבילה מאחת מכתובות ה-IP של תעבורת הנתונים היוצאת שמשויכות לשער. נקודות קצה באשכולות משותפים עם אותן תוויות לא יכולות להעביר תעבורת נתונים יוצאת (egress) באמצעות השער הזה.

מגבלות על הגדרות שער ספציפיות לאשכול

התאמות של תוויות עומסי עבודה (workloadSelector.labelSelector.workloads.matchLabels) משערי גישה בהיקף אשכול לא יכולות לחפוף להתאמות של תוויות עומסי עבודה משערי גישה אחרים בהיקף פרויקט. כפי שמוסבר במאמר מגבלות על ההגדרה של Cloud NAT, כתובות ה-workloadSelector.labelSelector.workloads.matchLabels לא יכולות להיות חופפות בין שערים באותו פרויקט ואזור.

האילוצים האחרים שמפורטים במאמר אילוצים על הגדרת Cloud NAT חלים גם על הגדרות של שערים בהיקף אשכול.