התקנת Agent Sandbox ב-GKE

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

במאמר מידע על Agent Sandbox ב-GKE מוסבר איך Agent Sandbox ב-GKE מבודד קוד לא מהימן שנוצר על ידי AI.

בחירה בין ארכיטקטורות מבוססות-Pod לארכיטקטורות מבוססות-שחקן

לפני שמתקינים את Agent Sandbox ב-GKE, צריך לבדוק איזו ארכיטקטורה של GKE מתאימה לעומסי העבודה של סוכן ה-AI:

  • ‫Agent Substrate ב-GKE (מבוסס-שחקן): משתמשים בארכיטקטורה הזו לרוב עומסי העבודה של סוכני AI, במיוחד סוכנים עם שמירת מצב (stateful) שמושעים ומופעלים מחדש לעיתים קרובות. סוכנים פעילים חולקים מאגר של Pods חמים במקום להחזיק Pod ייעודי לכל סוכן, כך שאפשר להריץ יותר סוכנים על פחות צמתים. ‫Agent Substrate ב-GKE מספק השעיה וחידוש אוטומטיים של עומסי עבודה לא פעילים, ומשחזר סוכנים מהאחסון תוך פחות משנייה. לעומת זאת, ב-Agent Sandbox ב-GKE צריך לבצע תמונת מצב של Pod באופן ידני, וצריך ליצור קוד אפליקציה כדי לזהות חוסר פעילות ולשמור את ההתקדמות של הסוכן. כדי להשתמש ב-Agent Substrate ב-GKE, צריך אשכול GKE Standard. מידע נוסף זמין במאמר מידע על Agent Substrate ב-GKE. כדי להתקין את האפשרות הזו, קראו את המאמר התקנת Agent Substrate ב-GKE.
  • ‫Agent Sandbox ב-GKE (מבוסס-Pod): משתמשים בארכיטקטורה הזו, שמתקינים במסמך הזה, כשכל סוכן צריך Pod ייעודי של Kubernetes באשכול GKE Autopilot או Standard. בוחרים באפשרות הזו לסוכנים פעילים באופן רציף או לעומסי עבודה שדורשים:
    • ממשקי API דקלרטיביים של Kubernetes, כמו המשאבים המותאמים אישית Sandbox ו-SandboxClaim
    • סכימת PodSpec המלאה של Kubernetes, כולל קונטיינרים בהתאמה אישית של sidecar ו-init
    • גישה ישירה למאיצי חומרה, כמו מעבדי GPU או TPU
    • אשכולות GKE Autopilot

עלויות

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

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

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

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

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

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

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

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

  3. מפעילים את Google Kubernetes Engine API, אם הוא עדיין לא מופעל.

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

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

    להפעלת ה-API

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

    הפעלת Cloud Shell

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

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

export CLUSTER_NAME="agent-sandbox-cluster"
export LOCATION="us-central1"
export AGENT_SANDBOX_VERSION="v1.0.6"
export NODE_POOL_NAME="agent-sandbox-pool"
export MACHINE_TYPE="e2-standard-2"

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

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

יצירת אשכול GKE

Agent Sandbox ב-GKE מבודד את עומסי העבודה בארגז החול באמצעות gVisor או microVMs. אם לא תציינו סביבת זמן ריצה לארגז החול, ארגזי החול יפעלו ללא בידוד ליבה (kernel). אנחנו לא ממליצים על כך לקוד לא מהימן. במסמך הזה נעשה שימוש ב-gVisor. באשכולות Autopilot, ‏gVisor מופעל באופן אוטומטי. באשכולות Standard, יוצרים מאגר צמתים שבו gVisor מופעל. כדי להשתמש ב-microVM, קראו את המאמר הפעלת סוג ארגז החול microVM. מדיניות האבטחה המומלצת מאפשרת רק gVisor, ולכן היא דוחה ארגזי חול שמשתמשים ב-microVMs.

טייס אוטומטי

כדי ליצור אשכול Autopilot, מוודאים שמשתנה הסביבה LOCATION מוגדר לאזור, כמו us-central1, ואז מריצים את הפקודה הבאה:

gcloud container clusters create-auto ${CLUSTER_NAME} \
    --location=${LOCATION}

רגילה

כדי ליצור אשכול Standard, יוצרים את האשכול ומוסיפים מאגר צמתים שבו gVisor מופעל. כדי להפחית את העלויות, במאמר הזה יוצרים אשכול אזורי עם צומת אחד לכל מאגר.

  1. מגדירים את משתנה הסביבה LOCATION לאזור, למשל us-central1-a:

    export LOCATION="us-central1-a"

  2. יוצרים את האשכול:

    gcloud container clusters create ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --machine-type=${MACHINE_TYPE} \
    --num-nodes=1

  3. יוצרים מאגר צמתים נפרד שבו gVisor מופעל:

    gcloud container node-pools create ${NODE_POOL_NAME} \
    --cluster=${CLUSTER_NAME} \
    --machine-type=${MACHINE_TYPE} \
    --location=${LOCATION} \
    --num-nodes=1 \
    --image-type=cos_containerd \
    --sandbox=type=gvisor

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

כדי להשתמש באשכול Standard קיים, צריך לוודא שהאשכול כולל מאגר צמתים שמופעל בו gVisor. אם באשכול אין מאגר צמתים כזה, יוצרים אחד באמצעות הפקודה gcloud container node-pools create שלמעלה.

כדי לאפשר לכלי שורת הפקודה kubectl להתחבר לאשכול, צריך לקבל את פרטי הכניסה לאשכול:

gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --location=${LOCATION}

התקנת Agent Sandbox

כדי להתקין את Agent Sandbox, צריך להחיל מניפסט של גרסה ממאגר Agent Sandbox ב-GitHub. המניפסט sandbox-with-extensions.yaml מתקין את בקר Agent Sandbox ואת CustomResourceDefinitions למשאב Sandbox ולמשאבי התוספים SandboxTemplate,‏ SandboxClaim ו-SandboxWarmPool.

  1. מחילים את המניפסט של הגרסה:

    kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${AGENT_SANDBOX_VERSION}/sandbox-with-extensions.yaml

    המניפסט יוצר את מרחב השמות agent-sandbox-system ופורס את הבקר במרחב השמות הזה.

  2. מחכים עד שהבקר מוכן:

    kubectl rollout status deployment/agent-sandbox-controller \
    --namespace=agent-sandbox-system \
    --timeout=120s

אפשר להתקין את Agent Sandbox גם באמצעות Helm. הוראות מפורטות מופיעות בקובץ README של תרשים Helm של Agent Sandbox.

אימות ההתקנה

  1. מוודאים שה-CustomResourceDefinitions של Agent Sandbox מותקנים:

    kubectl get crd \
    sandboxes.agents.x-k8s.io \
    sandboxtemplates.extensions.agents.x-k8s.io \
    sandboxclaims.extensions.agents.x-k8s.io \
    sandboxwarmpools.extensions.agents.x-k8s.io

    בפלט מופיעה רשימה של ארבעת ה-CustomResourceDefinitions.

  2. מוודאים שהבקר פועל:

    kubectl get deployment agent-sandbox-controller \
    --namespace=agent-sandbox-system

    כשהבקר פועל, בעמודה READY מוצג הערך 1/1.

החלת מדיניות האבטחה המומלצת

כברירת מחדל, Agent Sandbox ב-GKE לא מגביל את ההגדרות של ה-Pods שמריצים את ארגזי החול. כדי לאכוף את הגדרות הבידוד של ארגזי החול, מומלץ להחיל את secure-sandbox-policy ValidatingAdmissionPolicy ממאגר Agent Sandbox ב-GitHub. המדיניות הזו דוחה כל משאב Sandbox שלא עומד בדרישות הפריסה של Agent Sandbox ב-GKE.

  1. מחילים את המדיניות:

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/${AGENT_SANDBOX_VERSION}/examples/policy/vap/secure-sandbox-policy.yaml

  2. מחילים את קישור המדיניות. הקישור אוכף את המדיניות בכל מרחבי השמות, חוץ ממרחבי השמות של המערכת, כמו kube-system:

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/${AGENT_SANDBOX_VERSION}/examples/policy/vap/secure-sandbox-binding.yaml

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

kubectl logs deployment/agent-sandbox-controller \
    --namespace=agent-sandbox-system

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

הדרישות לפריסת Agent Sandbox ב-GKE

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

הגדרה נדרשת

מניפסט הפריסה צריך לכלול את ההגדרות הבאות:

  • ‫runtimeClassName: gvisor: מוודא שה-Pod פועל בארגז חול של gVisor. המדיניות דוחה ארגזי חול שמשתמשים בכל סביבת זמן ריצה אחרת, כולל microVM.
  • ‫automountServiceAccountToken: false: מונע מה-Pod לטעון באופן אוטומטי את אסימון ברירת המחדל של חשבון השירות.
  • ‫securityContext.runAsNonRoot: true: מוודא שהקונטיינר לא פועל כמשתמש Root.
  • ‫securityContext.capabilities.drop: ["ALL"]: הסרת כל היכולות של Linux מהקונטיינר.
  • ‫resources.limits: צריך לציין מגבלות על המעבד (CPU) ועל הזיכרון כדי למנוע תרחישים פוטנציאליים של התקפת מניעת שירות (DoS).
  • ‫nodeSelector: צריך לטרגט את sandbox.gke.io/runtime: gvisor.
  • tolerations: חייב לכלול toleration ל-taint של sandbox.gke.io/runtime=gvisor:NoSchedule.

הגדרה אסורה

מניפסט הפריסה לא יכול לכלול אף אחד מהדברים הבאים:

  • ‫hostNetwork: true, hostPID: true או hostIPC: true.
  • privileged: true בהקשרים של אבטחת קונטיינרים.
  • procMount: Unmasked בהקשרים של אבטחת קונטיינרים.
  • ‫HostPath כרכים.
  • יכולות נוספות (capabilities.add).
  • ההגדרות של hostPort.
  • sysctls בהתאמה אישית.
  • נפחים צפויים של אסימונים או אישורים של חשבונות שירות.

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

‫Sandbox Router הוא שרת proxy ל-HTTP שמנתב בקשות מלקוחות, כמו לקוח Python של Agent Sandbox, לפודים שמריצים את ארגזי החול. אם אתם מתכננים להשתמש בלקוח Python, למשל כמו שמתואר במאמר בידוד הרצת קוד של AI באמצעות Agent Sandbox ב-GKE, פרסו את הנתב.

פורסים את הנתב במרחב השמות agent-sandbox-system. כברירת מחדל, מדיניות רשת ב-Kubernetes ש-Agent Sandbox ב-GKE יוצר לכל משאב SandboxTemplate מאפשרת תעבורת נתונים נכנסת לארגזי חול רק מה-Pods של הנתב במרחב השמות הזה.

  1. יוצרים את חשבון השירות של הנתב ואת הרשאות ה-RBAC שמאפשרות לנתב לחפש Pods של ארגז חול:

    kubectl apply \
    -f https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/${AGENT_SANDBOX_VERSION}/sandbox-router/deploy/serviceaccount.yaml \
    -f https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/${AGENT_SANDBOX_VERSION}/sandbox-router/deploy/rbac.yaml

  2. פורסים את הנתב. הפקודה הבאה מגדירה את קובץ האימג' של הנתב לאותה גרסה של הבקר:

    curl -sSL https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/${AGENT_SANDBOX_VERSION}/sandbox-router/deploy/deployment.yaml \
    | sed "s|sandbox-router-go:latest|sandbox-router-go:${AGENT_SANDBOX_VERSION}|" \
    | kubectl apply -f -

  3. יוצרים את השירות של הנתב:

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/${AGENT_SANDBOX_VERSION}/sandbox-router/deploy/service.yaml

  4. מחכים עד שהנתב יהיה מוכן:

    kubectl rollout status deployment/sandbox-router \
    --namespace=agent-sandbox-system \
    --timeout=120s

הגדרת הנתב הזו מיועדת לפיתוח ולבדיקה. להגדרות ייצור, כמו TLS, ספירת רפליקות ומדיניות רשת ב-Kubernetes לנתב, קראו את קובץ ה-README של פריסת נתב Sandbox.

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

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

‫SandboxTemplate,‏ SandboxWarmPool,‏ SandboxClaim ו-Sandbox הם משאבים בהתאמה אישית של Kubernetes.

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

כדי לפרוס סביבת ארגז חול, צריך ליצור את המשאבים SandboxTemplate ו-SandboxWarmPool:

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

    apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxTemplate
metadata:
  name: python-runtime-template
  namespace: default
spec:
  podTemplate:
    metadata:
      labels:
        sandbox-type: python-runtime
    spec:
      runtimeClassName: gvisor # Required
      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: runtime
        image: registry.k8s.io/agent-sandbox/python-runtime-sandbox:v0.1.0
        ports:
        - containerPort: 8888
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "500m"
            memory: "1Gi" # Required
        securityContext:
          capabilities:
            drop: ["ALL"] # Required
      restartPolicy: OnFailure

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

    kubectl apply -f sandbox-template.yaml

  3. יוצרים קובץ בשם sandbox-warmpool.yaml עם התוכן הבא:

    apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxWarmPool
metadata:
  name: python-runtime-warmpool
  namespace: default
  labels:
    app: python-runtime-warmpool
spec:
  replicas: 2
  sandboxTemplateRef:
    # This must match the name of the SandboxTemplate.
    name: python-runtime-template

  4. מחילים את המניפסט SandboxWarmPool:

    kubectl apply -f sandbox-warmpool.yaml

  5. מחכים עד שארגזי החול של המאגר החם יהיו מוכנים:

    kubectl wait sandboxwarmpool python-runtime-warmpool \
    --for=jsonpath='{.status.readyReplicas}'=2 \
    --timeout=600s

    אם יוצרים משאב SandboxClaim לפני שארגזי החול של המאגר מוכנים, יכול להיות שהבקר ייצור ארגז חול חדש לבקשה במקום להקצות אחד מהמאגר. באשכול Autopilot, יכול להיות שיעברו כמה דקות עד שארגזי החול יהיו מוכנים, כי יכול להיות ש-GKE יצטרך ליצור בשבילם צמתים.

יצירת משאב SandboxClaim

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

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

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

    apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxClaim
metadata:
  name: sandbox-claim
  namespace: default
spec:
  warmPoolRef:
    # This must match the name of the SandboxWarmPool.
    name: python-runtime-warmpool

  2. מחילים את המניפסט SandboxClaim:

    kubectl apply -f sandbox-claim.yaml

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

    kubectl get sandboxwarmpool,sandboxclaim,sandbox,pod

חלופה: יצירת משאב Sandbox ישירות

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

כדי לפרוס סביבת ארגז חול באמצעות יצירת משאב Sandbox באופן ישיר:

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

    apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
  name: sandbox-example-2
spec:
  podTemplate:
    metadata:
      labels:
        sandbox: sandbox-example
    spec:
      runtimeClassName: gvisor
      restartPolicy: OnFailure
      automountServiceAccountToken: false # Required
      securityContext:
        runAsNonRoot: true # Required
        runAsUser: 1000 # Required if image defaults to root (for example, busybox)
      nodeSelector:
        sandbox.gke.io/runtime: gvisor
      tolerations:
      - key: "sandbox.gke.io/runtime"
        value: "gvisor"
        effect: "NoSchedule" # Required
      containers:
      - name: my-container
        image: busybox
        command: ["/bin/sh", "-c"]
        args: ["sleep 3600000; echo 'Container finished successfully'; exit 0"]
        securityContext:
          capabilities:
            drop: ["ALL"] # Required
          allowPrivilegeEscalation: false
        resources:
          limits:
            cpu: "100m"
            memory: "128Mi" # Required

  2. מחילים את המניפסט Sandbox:

    kubectl apply -f sandbox.yaml

  3. מוודאים שארגז החול פועל:

    kubectl get sandbox

שדרוג Agent Sandbox

כדי לשדרג את Agent Sandbox, צריך להחיל את מניפסט הגרסה של הגרסה החדשה:

export AGENT_SANDBOX_VERSION="NEW_VERSION"
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${AGENT_SANDBOX_VERSION}/sandbox-with-extensions.yaml

מחליפים את NEW_VERSION בגרסה שרוצים להתקין, כמו גרסה שמופיעה בדף הגרסאות של Agent Sandbox.

לפני השדרוג, כדאי לעיין בהערות המוצר של הגרסה החדשה. אם באשכול פועלת גרסה של Agent Sandbox שקודמת ל-1.0.0, צריך להעביר את המשאבים ל-API של v1beta1 לפני השדרוג, כי בגרסה 1.0.0 הוסר ה-API של v1alpha1. הוראות מפורטות זמינות במדריך להעברת נתונים (מיגרציה) של ה-API.

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

הסרת Agent Sandbox

  1. בודקים אם יש משאבים של Agent Sandbox שעדיין בשימוש:

    kubectl get sandboxes,sandboxclaims,sandboxwarmpools,sandboxtemplates \
    --all-namespaces

  2. אם החלתם את מדיניות האבטחה המומלצת, מחקו את קישור המדיניות ואת המדיניות:

    kubectl delete validatingadmissionpolicybinding secure-sandbox-binding
kubectl delete validatingadmissionpolicy secure-sandbox-policy

  3. אם פרסתם את Sandbox Router, מחקו את משאבי ה-RBAC שלו ברמת האשכול:

    kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/${AGENT_SANDBOX_VERSION}/sandbox-router/deploy/rbac.yaml

    שאר המשאבים של הנתב נמצאים במרחב השמות agent-sandbox-system, שיימחק בשלב הבא.

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

    kubectl delete -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${AGENT_SANDBOX_VERSION}/sandbox-with-extensions.yaml

מחיקת משאבים

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

gcloud container clusters delete ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --quiet

אם יצרתם אשכול במצב Autopilot, המיקום הוא האזור (לדוגמה, us-central1). אם יצרתם אשכול במצב Standard, המיקום הוא התחום (לדוגמה, us-central1-a).

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