בידוד של ביצוע קוד מבוסס-AI באמצעות ארגז חול של סוכן

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

עלויות

‫Agent Sandbox מוצע ללא תשלום ב-GKE. התמחור של GKE חל על המשאבים שאתם יוצרים.

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

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

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

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

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

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

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

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

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של שימוש בשירות' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

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

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

    הפעלת Cloud Shell

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

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

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

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

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

כדי לפשט את הפקודות שמריצים במסמך הזה, אפשר להגדיר משתני סביבה ב-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: המזהה של הפרויקט הנוכחי ב- Google Cloud . הגדרת המשתנה הזה עוזרת לוודא שכל המשאבים, כמו אשכול GKE, נוצרים בפרויקט הנכון.
  • ‫CLUSTER_NAME: השם של אשכול GKE, לדוגמה agent-sandbox-cluster.
  • ‫LOCATION: האזור שבו נמצא אשכול GKE. Google Cloud אם משתמשים באשכול Autopilot, צריך להגדיר את האזור (לדוגמה, us-central1). אם משתמשים באשכול Standard, צריך להגדיר את האזור (לדוגמה, us-central1-a).
  • ‫NODE_POOL_NAME: השם של מאגר הצמתים שיריץ עומסי עבודה בסביבת ארגז חול. לדוגמה, agent-sandbox-node-pool.
  • ‫MACHINE_TYPE: סוג המכונה של הצמתים במאגר הצמתים, לדוגמה e2-standard-2. פרטים על סדרות שונות של מכונות ואפשרויות שונות זמינים במאמר השוואה בין משפחות של מכונות ומשאבים.

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

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

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

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

יצירת SandboxTemplate וSandboxWarmPool

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

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

    apiVersion: extensions.agents.x-k8s.io/v1alpha1
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/v1alpha1
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 ציבורית או בהגדרה מורכבת של תעבורת נכנסת, ומפשטת את האינטראקציה עם ארגזי חול מהסביבה המקומית.

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

  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

    מחכים עד שיוצג הערך 2/2 או 1/1 בעמודה READY.

התקנת לקוח Python

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

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

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

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

    pip install k8s-agent-sandbox

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

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

  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(), אפשר להריץ כל פקודה של מעטפת, וארגז החול של הסוכן מריץ את הפקודה בתוך מחסום מאובטח שמגן על הצמתים של האשכול ועומסי עבודה אחרים מפני קוד לא מהימן. כך אפשר לספק דרך בטוחה ומהימנה לסוכן מבוסס-AI או לכל תהליך עבודה אוטומטי לבצע משימות.

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

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

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

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

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

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

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

    • אם אפליקציית הבקרה פועלת כ-Pod באותו אשכול, משתמשים ב-Kubernetes RBAC או ב-Workload Identity Federation for GKE עם מדיניות IAM כדי להעניק ל-Kubernetes ServiceAccount של ה-Pod את ההרשאות הנדרשות לצפייה בארגז חול או לגילוי נקודות קצה ברשת.
    • אם אפליקציית הבקרה פועלת מחוץ לאשכול, צריך להשתמש בשירות המשולב לזיהוי עומסי עבודה או בחשבונות שירות של IAM כדי לתת לאפליקציה זהות שאפשר להפנות אליה במדיניות הרשאות.

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

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

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

  • גישה לארגז חול ל Google Cloud משאבים: אם הקוד של ארגז החול צריך לשלוח בקשות ל- Google Cloud APIs, כמו Cloud Storage, צריך להשתמש במדיניות IAM עם Workload Identity Federation for GKE כדי להעניק לחשבון שירות Kubernetes שמשמש את ה-Pod של ארגז החול את ההרשאות שנדרשות לגישה הזו. מדיניות הרשת שמוגדרת כברירת מחדל חוסמת את הגישה לשרת המטא-נתונים Google Cloud (169.254.169.254), ולכן צריך להתאים אישית את מדיניות הרשת כדי לאפשר את התנועה הזו.

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

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

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

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

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

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

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

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

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

מדיניות האבטחה המחמירה מספקת שיטות מומלצות נוספות לאבטחה ואפשרויות ניהול. היא אוכפת מגבלות כמו הסרת כל היכולות, מניעת הוספה של יכולות חדשות ודרישה להפעלת קונטיינרים כמשתמשים לא-ראשיים עם מגבלות משאבים. ‫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, ומוסבר איך לפתור אותן או לעקוף אותן.

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

אם מנסים לפרוס ארגז חול שמשולב עם sidecar של Service mesh (לדוגמה, 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.
  • הסיבה: קבצי sidecar של service mesh משתמשים לעיתים קרובות ב-init container, כמו istio-init או proxy-init. למאגרי האתחול האלה נדרשות יכולות כמו NET_ADMIN או NET_RAW כדי להגדיר כללי iptables לניתוב יציאה שקוף. כברירת מחדל, ‏GKE sandbox-hardening-policy חוסם את כל התוספות של יכולות בכל סוגי הקונטיינרים.
  • פתרון עקיף: מכיוון שמדיניות האבטחה של GKE נפרסת במצב EnsureExists, אפשר לשנות את ValidatingAdmissionPolicy כדי לאפשר לקונטיינרים ספציפיים של init מהימנים לבקש הרשאות NET_ADMIN ו-NET_RAW. הוראות לשינוי או להסרה של אילוצי אבטחה מפורטות במאמר שינוי או הסרה של אילוצי אבטחה. לדוגמה, אפשר לעדכן את ביטויי האימות או את המשתנים של המדיניות כדי להחריג שמות של מאגרי תגים מהימנים מכלל היכולות.

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

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

  • הסיבה: אם באשכול GKE מופעלת תמיכה כפולה ב-IPv6, תרגום ה-DNS ל-Google APIs מחזיר כתובות IPv4 (A) ו-IPv6 (AAAA). אלגוריתמים מסוימים במנועי זמן ריצה, כמו Node.js, מנסים להתחבר קודם דרך IPv6. אם לרשת ה-VPC של GKE אין נתיב יציאה תקף של IPv6, כמו Cloud NAT או שער אינטרנט ל-IPv6, חיבור ה-TCP מפסיק להגיב (למידע נוסף, ראו https://developers.google.com/style/word-list#hang) עד שתוקף הזמן הקצוב לתפוגה של 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"

מחיקת משאבים

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

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

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