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

אתם יכולים לפרוס סביבת פיתוח כדי להשתמש בלקוח Python של ארגז החול לסוכנים באשכול של Google Kubernetes Engine ‏ (GKE). ההגדרה הזו עוזרת להריץ ולבדוק בצורה בטוחה קוד שנוצר על ידי AI, על ידי בידוד קוד לא מהימן בסביבת Python מבודדת. הבידוד הזה חיוני כדי להגן על המערכת מפני נקודות חולשה פוטנציאליות בקוד שנוצר על ידי AI, להגביר את קצב הפיתוח ולהבטיח פריסות מאובטחות. במאמר מידע על ארגז החול לסוכנים ב-GKE מוסבר איך ארגז החול לסוכנים ב-GKE מבודד קוד לא מהימן שנוצר על ידי AI.

עלויות

ארגז החול של הסוכן ב-GKE מוצע ללא תשלום נוסף. התמחור של GKE חל על המשאבים שאתם יוצרים.

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

  1. בדף לבחירת הפרויקט במסוף Cloud de Confiance , בוחרים פרויקט ב- Cloud de Confiance או יוצרים אותו.

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

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?

    כניסה לדף לבחירת הפרויקט

  2. מוודאים שהחיוב מופעל בפרויקט Cloud de Confiance .

  3. מפעילים את ממשקי ה-API של Artifact Registry ו-Kubernetes Engine, אם הם עדיין לא מופעלים.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    הפעלת ממשקי ה-API

  4. מפעילים את Cloud Shell במסוף Cloud de Confiance .

    הפעלת Cloud Shell

  5. מוודאים שיש את ההרשאות הנדרשות כדי להשלים את ההדרכה.
  6. צריך שיהיה לכם אשכול GKE עם ארגז חול לסוכנים ב-GKE מופעל. אם אין לכם אשכול, אתם יכולים ליצור אשכול חדש או לעדכן אשכול קיים לפי ההוראות במאמר הפעלת Agent Sandbox ב-GKE.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות ליצירה ולניהול של ארגזי חול, צריך לבקש מהאדמין להקצות לכם את התפקיד אדמין של Kubernetes Engine (roles/container.admin) ב-IAM בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

הגדרה של משתני סביבה

כדי לפשט את הפקודות שמריצים במסמך הזה, אפשר להגדיר משתני סביבה ב-Cloud Shell. ב-Cloud Shell, מריצים את הפקודות הבאות כדי להגדיר את משתני הסביבה השימושיים הבאים:

export PROJECT_ID=$(gcloud config get project)
export CLUSTER_NAME="agent-sandbox-cluster"
export LOCATION="us-central1"
export NODE_POOL_NAME="agent-sandbox-node-pool"
export MACHINE_TYPE="e2-standard-2"

הנה הסבר על משתני הסביבה האלה:

  • ‫PROJECT_ID: המזהה של הפרויקט הנוכחי ב- Cloud de Confiance by S3NS . הגדרת המשתנה הזה עוזרת לוודא שכל המשאבים, כמו אשכול GKE, נוצרים בפרויקט הנכון.
  • ‫CLUSTER_NAME: השם של אשכול GKE, לדוגמה agent-sandbox-cluster.
  • ‫LOCATION: האזור או התחום שבו נמצא אשכול GKE. Cloud de Confiance by S3NS אם משתמשים באשכול Autopilot, צריך להגדיר את האזור (לדוגמה, us-central1). אם משתמשים באשכול Standard, צריך להגדיר את האזור (לדוגמה, us-central1-a).
  • ‫NODE_POOL_NAME: השם של מאגר הצמתים שיריץ עומסי עבודה בארגז חול, לדוגמה agent-sandbox-node-pool.
  • ‫MACHINE_TYPE: סוג המכונה של הצמתים במאגר הצמתים, לדוגמה e2-standard-2. למידע נוסף על סדרות שונות של מכונות ועל בחירה בין אפשרויות שונות, קראו את המדריך להשוואה בין משפחות של מכונות ומשאבים.

פריסת סביבת ארגז חול (sandbox)

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

הדרך המומלצת ליצור את ארגז החול ולקיים איתו אינטראקציה היא באמצעות לקוח Python של Agentic Sandbox. הלקוח הזה מספק ממשק שמפשט את כל מחזור החיים של ארגז החול, מהיצירה ועד לניקוי. זו ספריית Python שמאפשרת ליצור, להשתמש ולמחוק ארגזי חול באופן פרוגרמטי.

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

יצירת SandboxTemplate וSandboxWarmPool

עכשיו מגדירים את ארגז החול באמצעות יצירת משאב SandboxTemplate ומשאב SandboxWarmPool. ‫SandboxTemplate משמשת כתבנית שאפשר לעשות בה שימוש חוזר, והבקר של Agent Sandbox משתמש בה כדי ליצור סביבות ארגז חול עקביות ומוגדרות מראש. המשאב SandboxWarmPool עוזר לוודא שמספר מסוים של Pods שחוממו מראש תמיד פועלים ומוכנים לשימוש. ארגז חול שחומם מראש הוא Pod פועל שכבר אותחל. האתחול המוקדם הזה מאפשר ליצור ארגזי חול חדשים בפחות משנייה, ומונע את השהיית ההפעלה של ארגז חול רגיל:

  1. ב-Cloud Shell, יוצרים קובץ בשם sandbox-template-and-pool.yaml עם התוכן הבא:

    apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxTemplate
metadata:
  name: python-runtime-template
  namespace: default
spec:
  podTemplate:
    metadata:
      labels:
        sandbox: python-sandbox-example
    spec:
      runtimeClassName: gvisor
      automountServiceAccountToken: false # Required
      securityContext:
        runAsNonRoot: true # Required
      nodeSelector:
        sandbox.gke.io/runtime: gvisor # Required
      tolerations:
      - key: "sandbox.gke.io/runtime"
        value: "gvisor"
        effect: "NoSchedule" # Required
      containers:
      - name: python-runtime
        image: registry.k8s.io/agent-sandbox/python-runtime-sandbox:v0.1.0
        ports:
        - containerPort: 8888
        readinessProbe:
          httpGet:
            path: "/"
            port: 8888
          initialDelaySeconds: 0
          periodSeconds: 1
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "500m"
            memory: "1Gi" # Required
        securityContext:
          capabilities:
            drop: ["ALL"] # Required
      restartPolicy: "OnFailure"
---
apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxWarmPool
metadata:
  name: python-sandbox-warmpool
  namespace: default
spec:
  replicas: 2
  sandboxTemplateRef:
    name: python-runtime-template

  2. מחילים את המניפסט של SandboxTemplate ו-SandboxWarmPool:

    kubectl apply -f sandbox-template-and-pool.yaml

פריסת הנתב של ארגז החול

לקוח Python שבו תשתמשו כדי ליצור סביבות של ארגז חול ולתקשר איתן משתמש ברכיב שנקרא Sandbox Router כדי לתקשר עם ארגזי החול.

בדוגמה הזו, משתמשים במצב פיתוח של הלקוח לצורך בדיקה. המצב הזה מיועד לפיתוח מקומי, ומשתמש בפקודה kubectl port-forward כדי ליצור מנהרה ישירה מהמכונה המקומית לשירות Sandbox Router שפועל באשכול. גישת המנהור הזו חוסכת את הצורך בכתובת IP ציבורית או בהגדרה מורכבת של Ingress, ומפשטת את האינטראקציה עם ארגזי חול מהסביבה המקומית.

כדי לפרוס את הנתב של ארגז החול:

  1. ב-Cloud Shell, יוצרים קובץ בשם sandbox-router.yaml עם התוכן הבא:

    # A ClusterIP Service to provide a stable endpoint for the router pods.
apiVersion: v1
kind: Service
metadata:
  name: sandbox-router-svc
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: sandbox-router
  ports:
  - name: http
    protocol: TCP
    port: 8080 # The port the service will listen on
    targetPort: 8080 # The port the router container listens on (from the sandbox_router/Dockerfile)
---
# The Deployment to manage and run the router pods.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sandbox-router-deployment
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sandbox-router
  template:
    metadata:
      labels:
        app: sandbox-router
    spec:
      # Ensure pods are spread across different zones for HA
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: sandbox-router
      containers:
      - name: router
        image: us-central1-docker.pkg.dev/k8s-staging-images/agent-sandbox/sandbox-router:latest-main
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        resources:
          requests:
            cpu: "100m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000

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

    kubectl apply -f sandbox-router.yaml

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

    kubectl get deployment sandbox-router-deployment

    מחכים עד שבעמודה READY יופיע 2/2 או 1/1.

התקנת לקוח Python

אחרי שפורסים את הרכיבים בתוך האשכול, כמו Sandbox Router, השלב האחרון בהכנה הוא להתקין את Agentic Sandbox Python client במכונה המקומית. חשוב לזכור שהלקוח הזה הוא ספריית Python שמאפשרת ליצור, להשתמש ולמחוק ארגזי חול באופן פרוגרמטי. תשתמשו בו בקטע הבא כדי לבדוק את הסביבה:

  1. יוצרים ומפעילים סביבה וירטואלית של Python:

    python3 -m venv .venv
source .venv/bin/activate

  2. מתקינים את חבילת הלקוח:

    pip install k8s-agent-sandbox

בדיקת ארגז החול (Sandbox)

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

  1. בספרייה agent-sandbox, יוצרים סקריפט Python בשם test_sandbox.py עם התוכן הבא:

    from k8s_agent_sandbox import SandboxClient
from k8s_agent_sandbox.models import SandboxLocalTunnelConnectionConfig

# Automatically tunnels to svc/sandbox-router-svc
client = SandboxClient(
    connection_config=SandboxLocalTunnelConnectionConfig()
)

sandbox = client.create_sandbox(template="python-runtime-template", namespace="default")
try:
    print(sandbox.commands.run("echo 'Hello from the sandboxed environment!'").stdout)
except Exception as e:
    print(f"An error occurred: {e}")

  2. מהטרמינל (כשהסביבה הווירטואלית עדיין פעילה), מריצים את סקריפט הבדיקה:

    python3 test_sandbox.py

צריכה להופיע ההודעה "Hello from the sandboxed environment!‎" שמוצגת כפלט מהארגז.

כל הכבוד! הפעלתם בהצלחה פקודת מעטפת בתוך ארגז חול מאובטח. באמצעות השיטה sandbox.run(), אפשר להריץ כל פקודת shell, וארגז החול של הסוכן ב-GKE מריץ את הפקודה בתוך מחסום מאובטח שמגן על הצמתים של האשכול ועומסי עבודה אחרים מפני קוד לא מהימן. כך סוכן AI או כל תהליך עבודה אוטומטי יכולים לבצע משימות בצורה בטוחה ואמינה.

כשמריצים את הסקריפט, SandboxClient מטפל בכל השלבים בשבילכם. הוא יוצר את המשאב SandboxClaim כדי להפעיל את ארגז החול, ממתין שארגז החול יהיה מוכן ואז משתמש ב-method‏ sandbox.run() כדי להריץ פקודות bash shell בתוך הקונטיינר המאובטח. הלקוח לוכד ומדפיס את stdout מהפקודה הזו. ארגז החול נמחק באופן אוטומטי אחרי שהתוכנית פועלת.

כשיוצרים משאב SandboxClaim, המערכת מקצה Pod זמין ממאגר ה-Pods הפעילים לאובייקט של ארגז החול, ומסמנת את התביעה כ'מוכנה'. לאחר מכן, SandboxWarmPool ממלא את עצמו באופן אוטומטי כדי לשמור על מספר העותקים שהוגדר.

כדי לבדוק אם ארגז חול ספציפי נתבע או זמין, בודקים את ownerReferences במטא-נתונים של pod של ארגז החול – אם הערך של השדה kind הוא Sandbox, ה-pod נמצא בשימוש. אם הערך של השדה kind הוא SandboxWarmPool, ה-Pod לא פעיל וממתין לתביעת בעלות.

הפעלת ארגזי חול בסביבת הייצור

במאמר הזה, אתם יוצרים אינטראקציה עם ארגזי חול מחוץ לאשכול באמצעות Cloud Shell. לקוח Python משתמש בפרטי הכניסה שלכם כדי לבצע אימות לאשכול ולנהל משאבי ארגז חול, ומשתמש בפקודה kubectl port-forward כדי ליצור חיבור לארגזי חול. השלבים האלה מתאימים לתרחישי פיתוח.

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

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

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

    • אם אפליקציית הבקר פועלת באותו אשכול, משתמשים בפונקציה SandboxDirectConnectionConfig כדי לטרגט את כתובת ה-URL והיציאה שבהן משתמש שירות Sandbox Router.
    • אם אפליקציית בקר פועלת מחוץ לאשכול, צריך להשתמש ב-GKE Gateway API כדי ליצור מאזן עומסים פנימי או חיצוני. בקוד הלקוח, משתמשים בפונקציה SandboxGatewayConnectionConfig כדי להפנות אל השער.

    מידע נוסף על שיטות הניתוב האלה זמין בדוגמאות לשימוש ב-GitHub ובשלבי הפריסה של Gateway לנתב.

  • גישה של ארגז החול למשאבי Cloud de Confiance : אם הקוד של ארגז החול צריך לשלוח בקשות לממשקי API של Cloud de Confiance , כמו Cloud Storage, צריך להשתמש במדיניות IAM עם איחוד זהויות של עומסי עבודה ל-GKE כדי לתת ל-Kubernetes ServiceAccount שבו משתמש ה-Pod של ארגז החול את ההרשאות שנדרשות לגישה הזו. מדיניות הרשת שמוגדרת כברירת מחדל חוסמת את הגישה ל Cloud de Confiance by S3NS שרת המטא-נתונים (169.254.169.254), ולכן צריך להתאים אישית את מדיניות הרשת כדי לאפשר את התנועה הזו.

  • הגבלות של מדיניות רשת ב-Kubernetes: כברירת מחדל, ארגז החול לסוכנים ב-GKE אוכף מצב רשת מחמיר של Secure-by-Default (networkPolicyManagement: Managed). ההגבלות הבאות חלות במצב הזה:

    • Ingress חסום מכל המקורות, חוץ מהנתב הייעודי של Sandbox.
    • מותרת תעבורת נתונים יוצאת לאינטרנט הציבורי, אבל תעבורת נתונים יוצאת לטווחי LAN פרטיים (RFC 1918), ל-DNS פנימי של אשכול (CoreDNS) ולשרת המטא-נתונים של ספק שירותי הענן (169.254.0.0/16) חסומה באופן מפורש.

    כדי להשתמש באיחוד זהויות של עומסי עבודה ל-GKE או לגשת למשאבים פרטיים אחרים, צריך להגדיר מדיניות רשת ב-Kubernetes בהתאמה אישית ב-SandboxTemplate. פרטים נוספים על הגדרות ותבניות שאפשר להתאים אישית (כמו ארגז חול עם בידוד פיזי או איחוד שירותי אימות הזהות של עומסי עבודה לשילוב עם GKE) זמינים במאמר ניהול מדיניות רשת של ארגז חול של סוכן.

כללי מדיניות האבטחה של ארגז החול (sandbox)

כדי להבטיח סביבה שמתעדפת אבטחה כברירת מחדל, ארגז החול של הסוכן בתוסף GKE משתמש במדיניות אימות קבלה (VAP) של Kubernetes כדי לאכוף אילוצי אבטחה על משאבי Sandbox ו-SandboxTemplate. המדיניות הזו מופעלת באופן אוטומטי.

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

מדיניות אבטחה בסיסית (sandbox-core-policy)

מדיניות האבטחה המרכזית אוכפת דרישות בידוד שעוזרות להגן על השלמות של ארגז החול. המדיניות הזו כוללת כללים שמחייבים שימוש ב-gVisor, בידוד רשת כמו השבתת hostNetwork ובידוד מערכת קבצים כמו חסימת hostPath. מכיוון ש-GKE מנהל את המדיניות הזו באמצעות ההגדרה addonmanager.kubernetes.io/mode: Reconcile, אי אפשר לשנות או לבטל את כללי הליבה האלה.

הקשחת מדיניות האבטחה (sandbox-hardening-policy)

מדיניות האבטחה המחמירה מספקת שיטות מומלצות נוספות לאבטחה ואפשרויות ניהול. היא אוכפת אילוצים כמו ביטול כל היכולות, מניעת הוספה של יכולות חדשות ודרישה להפעיל קונטיינרים כמשתמשים שאינם משתמשי root עם מגבלות משאבים. ‫GKE פורס את המדיניות הזו במצב EnsureExists באמצעות ההגדרה addonmanager.kubernetes.io/mode: EnsureExists. ההגדרה הזו אומרת ש-GKE יוצר את המדיניות אם היא חסרה, אבל אתם יכולים לשנות או למחוק את המדיניות או את הקישור שלה לפי הצורך.

שינוי או הסרה של אילוצים להגברת האבטחה

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

כדי לשנות את מדיניות ההקשחה ולהסיר אילוץ ספציפי (לדוגמה, כדי לאפשר למארזים לפעול כמשתמשי root או להשמיט מגבלות על משאבים), עורכים את המשאב ValidatingAdmissionPolicy:

kubectl edit validatingadmissionpolicy sandbox-hardening-policy

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

לחלופין, אם רוצים להשבית לגמרי את מדיניות האבטחה של האשכול, צריך למחוק את קשירת המדיניות:

kubectl delete validatingadmissionpolicybinding sandbox-hardening-binding

בעיות מוכרות

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

מדיניות האבטחה חוסמת יכולות כשמשתמשים ב-Service mesh

אם תנסו לפרוס ארגז חול שמשולב עם Service mesh sidecar (לדוגמה, Envoy או Istio), יכול להיות שמדיניות האבטחה המוקשחת תחסום את יצירת ארגז החול ותופיע שגיאה כמו זו:

sandbox create error: sandboxes.agents.x-k8s.io "claude-cli-claim-managed" is forbidden:
ValidatingAdmissionPolicy 'sandbox-hardening-policy' with binding 'sandbox-hardening-binding'
denied request: Security Violation: Capabilities.add must be empty. You cannot add capabilities.
  • הסיבה: ב-sidecars של Service mesh משתמשים לעיתים קרובות בקונטיינר init, כמו istio-init או proxy-init. הקונטיינרים האלה של init דורשים יכולות כמו NET_ADMIN או NET_RAW כדי להגדיר כללי iptables לניתוב שקוף של תעבורת נתונים יוצאת. כברירת מחדל, sandbox-hardening-policy של GKE חוסם את כל תוספות היכולות בכל סוגי הקונטיינרים.
  • פתרון עקיף: מכיוון שמדיניות האבטחה של GKE נפרסת במצב EnsureExists, אפשר לשנות את ValidatingAdmissionPolicy כדי לאפשר למאגרי init ספציפיים מהימנים לבקש הרשאות NET_ADMIN ו-NET_RAW. הוראות לשינוי או להסרה של אילוצי אבטחה מפורטות במאמר שינוי או הסרה של אילוצי אבטחה. לדוגמה, אפשר לעדכן את ביטויי האימות או המשתנים של המדיניות כדי להחריג שמות של קונטיינרים מהימנים מכלל היכולות.

זמן אחזור או זמן קצוב לתפוגה של תעבורת נתונים יוצאת כשמתחברים ל-Google APIs דרך IPv6

יכול להיות שבעומסי עבודה בתוך ארגז החול יהיו זמני קצובים לתפוגה של חיבורים או זמן אחזור גבוה, עד שתי דקות, כשמנסים להתחבר למשאבים חיצוניים או לממשקי Google API (כמו Vertex AI או Cloud Storage).

  • הסיבה: אם באשכול GKE מופעל IPv6 עם מחסנית כפולה, פענוח ה-DNS של Google APIs מחזיר גם כתובות IPv4 (A) וגם כתובות IPv6 (AAAA). חלק מהאלגוריתמים במנועי זמן ריצה, כמו Node.js, מנסים קודם להתחבר דרך IPv6. אם ל-VPC של GKE אין נתיב תקין לתעבורת נתונים יוצאת ב-IPv6, כמו Cloud NAT או שער אינטרנט ל-IPv6, חיבור ה-TCP מפסיק להגיב עד שנגמר הזמן הקצוב לתפוגה של TCP SYN. לאחר מכן, חיבור ה-TCP חוזר ל-IPv4.

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

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

    • העדפת IPv4 בעומס העבודה: כדי להעדיף פענוח DNS של IPv4, צריך להגדיר את זמן הריצה של עומס העבודה. לדוגמה, באפליקציית Node.js, אפשר להגדיר את משתני הסביבה הבאים בהגדרה של SandboxTemplate:

      env:
- name: NODE_OPTIONS
  value: "--dns-result-order=ipv4first --no-network-family-autoselection"

מחיקת משאבים

כדי להימנע מחיובים בחשבון Cloud de Confiance by S3NS , צריך למחוק את אשכול GKE שיצרתם:

gcloud container clusters delete $CLUSTER_NAME --location=$LOCATION --quiet

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