ניהול ברירת המחדל של NAT ליציאה בפרויקט

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

סקירה כללית

בדף הזה מוסבר איך לבצע פעולות שקשורות לקישוריות יוצאת במכונה וירטואלית (VM) או בתרמיל בפרויקט, כדי לאפשר לעומסי עבודה לצאת מהארגון באמצעות אפשרות ההגדרה של NAT יוצאת שמוגדרת כברירת מחדל בפרויקט (האפשרות הזו הוצאה משימוש).

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

בתהליך הזה מוסבר איך להוסיף תווית חובה לפריסות כדי להפעיל באופן מפורש תנועה יוצאת ולאפשר לעומסי עבודה לתקשר מחוץ לארגון.

כברירת מחדל, ב-Google Distributed Cloud‏ (GDC) עם בידוד פיזי, עומסי עבודה בפרויקט נחסמים כדי שלא יוכלו לצאת מהארגון. עומסי עבודה יכולים לצאת מהארגון אם האדמין של הפלטפורמה השבית את ההגנה מפני העברת נתונים לא מורשית בפרויקט. כדי לעשות את זה, הם צריכים לצרף את התווית networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" לפרויקט. בנוסף להשבתת ההגנה מפני העברת נתונים לא מורשית, מפעיל האפליקציה (AO) צריך להוסיף את התווית egress.networking.gke.io/enabled: true לעומס העבודה של ה-Pod כדי להפעיל את הקישוריות של תעבורת נתונים יוצאת (egress) עבור ה-Pod הזה. כשמקצים כתובת IP מוכרת לפרויקט ומשתמשים בה, מתבצע תרגום כתובות רשת (NAT) של המקור בתנועה היוצאת מהארגון.

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

ניהול תעבורה יוצאת מעומסי עבודה בתרמיל

כדי להגדיר עומסי עבודה בתא לצורך קישוריות יוצאת, קודם צריך לוודא שההגנה מפני זליגת נתונים מושבתת בפרויקט. לאחר מכן, מוודאים שהתווית egress.networking.gke.io/enabled: true נוספה לפוד. אם אתם משתמשים במבנה ברמה גבוהה יותר, כמו מבני Deployment או Daemonset, כדי לנהל קבוצות של פודים, אתם צריכים להגדיר את התווית של הפוד במפרטים האלה.

בדוגמה הבאה אפשר לראות איך ליצור Deployment מקובץ המניפסט שלו. קובץ הדוגמה מכיל את הערך egress.networking.gke.io/enabled: true בשדה labels כדי להפעיל באופן מפורש תנועה יוצאת מהפרויקט. התווית הזו מתווספת לכל פוד בפריסה ומאפשרת לעומסי עבודה בפודים לצאת מהארגון.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels: # The labels given to each pod in the deployment, which are used
              # to manage all pods in the deployment.
        run: APP_NAME
        egress.networking.gke.io/enabled: true
    spec: # The pod specification, which defines how each pod runs in the deployment.
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
EOF

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

  • ‫USER_CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של אשכול המשתמש שאליו פורסים עומסי עבודה של קונטיינרים.

  • ‫DEPLOYMENT_NAME: קובץ ה-kubeconfig של אשכול המשתמשים שבו אתם פורסים עומסי עבודה של קונטיינרים.

  • ‫APP_NAME: השם של האפליקציה שרוצים להפעיל בפריסה.

  • ‫NUMBER_OF_REPLICAS: מספר האובייקטים המשוכפלים Pod שהפריסה מנהלת.

  • ‫CONTAINER_NAME: השם של הקונטיינר.

  • ‫CONTAINER_IMAGE: השם של קובץ האימג' בקונטיינר. צריך לכלול את הנתיב של מאגר הקונטיינרים ואת גרסת התמונה, כמו REGISTRY_PATH/hello-app:1.0.

לדוגמה:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
        egress.networking.gke.io/enabled: true
    spec:
      containers:
      - name: hello-app
        image: REGISTRY_PATH/hello-app:1.0

ניהול תנועה יוצאת מעומסי עבודה במכונה וירטואלית

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

מעבר ל-Cloud NAT

עם ההשקה של Cloud NAT בגרסה 1.15, הגדרת ברירת המחדל של NAT ליציאה מפרויקט מוצא (egress) בכל פרויקט יוצאת משימוש. מומלץ למשתמשים לבצע מיגרציה של הגדרות התעבורה היוצאת (egress) שלהם מהגדרת ברירת המחדל של NAT ליציאה של הפרויקט אל Cloud NAT.

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

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

  • השבתה של NAT ברירת מחדל לתעבורת נתונים יוצאת בכל הפרויקט: כדי להשבית את NAT ברירת המחדל לתעבורת נתונים יוצאת בכל נקודות הקצה בפרויקט, צריך להקצות את התווית networking.gdc.goog/allocate-egress-ip: "false" לפרויקט.
  • השבתה של NAT ליציאה כברירת מחדל בפרויקט לכל נקודת קצה: כדי להשבית NAT ליציאה כברירת מחדל בפרויקט עבור נקודת קצה ספציפית של pod או מכונה וירטואלית, מסירים את התווית egress.networking.gke.io/enabled:"true" מה-pod או מהמכונה הווירטואלית.

כדי להמשיך במיגרציה, כשכל נקודת קצה מוסרת מ-NAT ברירת המחדל לתעבורת נתונים יוצאת (egress), אפשר להוסיף אותה לשער Cloud NAT על ידי הוספת תוויות לנקודת הקצה שתואמות לבוררי התוויות של השער שנבחר.

הוראות להגדרת Cloud NAT מופיעות במאמר Cloud NAT ובדפים הבאים.

מעקב אחרי כתובות IP של יציאת חירום

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