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

דרישות מוקדמות
לפני שמגדירים שער, צריך לקבל הרשאות מתאימות לניהול זהויות והרשאות גישה (IAM), לוודא שלפרויקט יש מדיניות רשת מתאימה ולהפעיל תעבורת נתונים יוצאת (egress).
פרטים נוספים מופיעים במאמר לפני שמתחילים להשתמש ב-Cloud NAT.
שער Cloud NAT משתמש ברשתות משנה חיצוניות leaf כקלט. מידע נוסף על הגדרת רשתות משנה חיצוניות ל-Cloud NAT זמין במאמר יצירת רשתות משנה חיצוניות ל-Cloud NAT.
בדיקה של תצורת ה-VM או ה-Pod
כמו שצוין בסקירה הכללית על NAT, Cloud NAT לא תואם להגדרת היציאה מהפרויקט שמוגדרת כברירת מחדל. מוודאים שלכל פוד או מכונה וירטואלית שרוצים להשתמש בהם עם Cloud NAT אין את התווית egress.networking.gke.io/enabled:true.
כברירת מחדל, הגדרה של גישה חיצונית למכונה וירטואלית (VMEA) מגדירה מכונה וירטואלית להוצאת תעבורת נתונים באמצעות הגדרת ברירת המחדל של הוצאת תעבורת נתונים מהפרויקט. במילים אחרות, התווית egress.networking.gke.io/enabled:"true" נוספת באופן אוטומטי למכונה הווירטואלית. אם מכונת ה-VM מוגדרת גם להעברת תעבורת נתונים יוצאת באמצעות שער Cloud NAT, תהיה התנגשות בין הגדרות ה-NAT. כדי למנוע התנגשות כזו, לכל כתובת VMEA שמשויכת למכונה וירטואלית שהוגדרה להוצאת תעבורת נתונים יוצאת (egress) דרך שער Cloud NAT, צריך לוודא שלכתובת ה-VMEA שמשויכת למכונה הווירטואלית הזו יש את ההערה egress.networking.gke.io/use-cloud-nat:"true".
התנועה היוצאת של המכונה הווירטואלית המשויכת תעבור רק דרך שער Cloud NAT.
יצירת שערי Cloud NAT
בדוגמה הבאה מוגדר שער Cloud NAT עם שתי רשתות משנה חיצוניות מסוג leaf (subnet-1 ו-subnet-2). השער ישתמש בכל כתובות ה-IP ברשתות המשנה האלה, אחת מ-subnet-1 וארבע מ-subnet-2, ויקצה אותן באופן אוטומטי לנקודות הקצה מכל מכונה וירטואלית או פוד עם התוויות שצוינו. יכול להיות שלכמה פודים או מכונות וירטואליות (VM) תוקצה אותה כתובת IP ליציאה.
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
namespace: project-1
name: gateway-1
spec:
workloadSelector: # Immutable
labelSelector:
workloads:
matchLabels:
app: aa
subnetRefs: # Mutable
- subnet-1
- subnet-2
בדיקת הסטטוס של השערים
מריצים את הפקודה 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:
labelSelector:
workloads:
matchLabels:
app: aa
subnetRefs:
- 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
סטטוס השער של Cloud NAT כולל 4 תנאים מהסוגים הבאים:
-
Ready: התנאי הזה מסכם את הסטטוס של שער Cloud NAT. התנאי הזה מוגדר כ-True אם השער מוגדר באופן מלא. -
SubnetsReady: התנאי הזה מציין אם רשתות המשנה שהוקצו לשער תקפות. -
PerimeterConfigurationReady: התנאי הזה מציין אם הגדרת גבולות הגזרה כבר הוגדרה (למשל, כתובות IP חיצוניות שהוקצו לצמתים שפונים כלפי חוץ וכו'). -
EgressRoutesReady: התנאי הזה מציין אם המסלולים לתעבורת נתונים יוצאת מנקודות הקצה של המקור כבר הוגדרו.
תנועת בדיקה
אפשר לבדוק את התעבורה באמצעות הפעלת פקודה curl מאחד הפודים או המכונות הווירטואליות שהוקצו לשער, לכיוון נקודת קצה חיצונית. נקודת הקצה המקבלת צריכה לראות אחת מכתובות ה-IP של היציאה שמשויכות לשער.