הפעלת ארגז חול של סוכנים ב-GKE

טייס אוטומטי רגילה

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

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

עלויות

‫Agent Sandbox מוצע ב-GKE ללא עלות נוספת. התמחור של 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 ו-Google Kubernetes Engine, אם הם עדיין לא מופעלים.

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

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

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

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

   הפעלת Cloud Shell

5. מוודאים שהאשכול מריץ את גרסת GKE‏ 1.36.3-gke.1767000 ואילך (תומך ב-API‏ v1beta1).

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

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

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

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

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

הפעלת ארגז חול של סוכן

אפשר להפעיל את התכונה Agent Sandbox כשיוצרים אשכול חדש או כשמעדכנים אשכול קיים.

הפעלת ארגז חול של סוכנים כשיוצרים אשכול GKE חדש

מומלץ להשתמש באשכול Autopilot כדי ליהנות מחוויית Kubernetes מנוהלת באופן מלא. כדי לבחור את מצב הפעולה של GKE שהכי מתאים לעומסי העבודה שלכם, אפשר לעיין במאמר בחירת מצב פעולה של GKE.

טייס אוטומטי

כדי ליצור אשכול GKE Autopilot חדש עם Agent Sandbox מופעל, צריך לכלול את הדגל --enable-agent-sandbox:

gcloud beta container clusters create-auto ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-agent-sandbox

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

רגילה

כדי ליצור אשכול GKE Standard חדש עם Agent Sandbox מופעל, צריך ליצור את האשכול, להוסיף מאגר צמתים עם gVisor מופעל ואז להפעיל את התכונה Agent Sandbox. כדי לחסוך בעלויות, מומלץ ליצור אשכול אזורי עם צומת יחיד לכל מאגר:

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

   gcloud beta container clusters create ${CLUSTER_NAME} \
       --location=${LOCATION} \
       --num-nodes=1 \
       --cluster-version=${CLUSTER_VERSION}
   

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

2. יוצרים מאגר צמתים נפרד עם 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
   

   האזור LOCATION צריך להיות זהה לאזור שבו השתמשתם כשיצרתם את האשכול.

3. מעדכנים את האשכול כדי להפעיל את התכונה Agent Sandbox:

   gcloud beta container clusters update ${CLUSTER_NAME} \
       --location=${LOCATION} \
       --enable-agent-sandbox
   

הפעלת ארגז חול של סוכנים כשמעדכנים אשכול GKE קיים

כדי להפעיל את Agent Sandbox באשכול קיים, האשכול צריך להריץ גרסה 1.36.3-gke.1767000 ואילך, שתומכת ב-API‏ v1beta1.

מוודאים שמשתנה הסביבה LOCATION מוגדר לאזור או לאזור הזמין שבו נמצא האשכול הקיים.

1. אם אתם משתמשים באשכול GKE Standard, ‏ Agent Sandbox מסתמך על gVisor. אם באשכול Standard שלכם אין מאגר צמתים עם gVisor, אתם צריכים ליצור כזה קודם:

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

2. מעדכנים את האשכול כדי להפעיל את התכונה Agent Sandbox:

   gcloud beta container clusters update ${CLUSTER_NAME} \
       --location=${LOCATION} \
       --enable-agent-sandbox
   

אימות ההגדרה

כדי לבדוק אם התכונה Agent Sandbox מופעלת, צריך לבדוק את תיאור האשכול.

gcloud beta container clusters describe ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --format="value(addonsConfig.agentSandboxConfig.enabled)"

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

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

דרישות לפריסת ארגז חול של סוכן

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

הגדרה נדרשת

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

• ‫runtimeClassName: gvisor: מוודא שה-Pod יפעל בארגז חול של gVisor.
• ‫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 בהקשרים של אבטחת קונטיינרים.
• ‫HostPath כרכים.
• נוספו יכולות (capabilities.add).
• ההגדרות של hostPort.
• ‫sysctl בהתאמה אישית.
• הנפחים הצפויים של אסימונים או אישורים של חשבונות שירות.

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

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

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

מומלץ: יצירת SandboxTemplate ו-SandboxWarmPool

ה-SandboxTemplate משמש כתוכנית פעולה לשימוש חוזר. ה-SandboxWarmPool עוזר לוודא שמספר מסוים של תרמילים (Pods) שהופעלו מראש תמיד פועלים ומוכנים להקצאה. השימוש במשאב המותאם אישית הזה מצמצם את זמן האחזור של ההפעלה.

כדי לפרוס סביבת ארגז חול על ידי יצירת 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
   

יצירת SandboxClaim

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

כדי לבקש סביבת ארגז חול מהמאגר הפעיל על ידי יצירת 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
   

חלופה: יצירת ארגז חול ישירות

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

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

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

   apiVersion: agents.x-k8s.io/v1beta1
   kind: Sandbox
   metadata:
     name: sandbox-example-2
   spec:
     replicas: 1
     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 (e.g. 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
   

העברת ארגז חול של סוכן מ-v1alpha1 אל v1beta1

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

הערה: הליך ההעברה הזה רלוונטי לאשכולות שמשתמשים בתכונה המנוהלת של ארגז החול לסוכנים ב-GKE‏ (--enable-agent-sandbox). אם פרסתם את ארגז החול לסוכנים באמצעות מניפסטים בקוד פתוח, כדאי לעיין במדריך ההעברה של upstream.

ההבדלים העיקריים בין ממשקי ה-API של v1alpha1 ושל v1beta1

קונספט	התנהגות v1alpha1	התנהגות v1beta1	השפעת ההעברה
SandboxClaim targets	אפשר להפנות ישירות אל SandboxTemplate בלי מאגר חם (הפעלה במצב התחלתי).	נדרש להוסיף הפניה אל SandboxWarmPool (spec.warmPoolRef.name).	צריך למפות תביעות של הפעלה במצב התחלתי (cold start) למאגר חם וירטואלי (replicas: 0).
מצב הפעלה של ארגז חול	הערך נקבע על סמך רפליקות או שדות מצב.	ערך מפורש בשדה spec.operatingMode (למשל Running או Suspended).	ה-webhook של ההמרה ממפה ומגדיר את השדה הזה באופן אוטומטי.
גרסת האחסון של CustomResourceDefinition	‫v1alpha1 מאוחסן ב-etcd‏ (storage: true).	‫v1beta1 מאוחסן ב-etcd‏ (storage: true).	ה-Webhook מבצע המרה דינמית; שלב אחרי השדרוג הוא שמירה מחדש של אובייקטים של etcd.
Conversion webhook	אין.	פעיל בתאריך /convert (יציאה 9447).	תרגום דו-כיווני בין v1alpha1 ל-v1beta1.

העברה באמצעות כלי ההעברה

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

מורידים ומכינים את הסקריפט:

curl -LO https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/v0.5.6/helm/files/migrate.sh
chmod +x migrate.sh

מדריך מפורט להעברה

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

שלב 1: שלב האתחול לפני השדרוג

חשוב: את שלב האתחול חובה לבצע בזמן שהאשכול פועל v1alpha1. אי אפשר להפעיל את שלב האתחול אחרי השדרוג כי סכימת ה-API‏ v1beta1 לא תחשוף יותר את spec.sandboxTemplateRef הקודם בטענות.

1. גיבוי של משאבים קיימים: שומרים גיבוי ב-YAML של משאבי ארגז החול של הסוכן ההצהרתי (sandboxtemplates, sandboxwarmpools ו-sandboxclaims):

   kubectl get sandboxtemplates,sandboxwarmpools,sandboxclaims \
       --all-namespaces -o yaml > agent-sandbox-v1alpha1-backup.yaml
   

   הערה: הפקודה הזו מחריגה אובייקטים של Sandbox שמנוהלים על ידי SandboxClaim או SandboxWarmPool כי הבקר יוצר אותם מחדש באופן דינמי כשמשחזרים טענות ומאגרי משאבים חמים. אם יצרתם משאבים עצמאיים Sandbox ישירות בלי תלונה או מאגר חם, צריך לכלול את sandboxes בגיבוי (או לגבות אותם בנפרד) כדי שלא יאבדו במהלך השחזור.

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

3. צופים בתצוגה מקדימה של מאגרי הצללים שייווצרו:

   ./migrate.sh --phase=bootstrap --dry-run
   

4. מריצים את שלב האתחול:

   ./migrate.sh --phase=bootstrap
   

5. בודקים את מאגרי הצללים שנוצרו:

   kubectl get sandboxwarmpools --all-namespaces \
       -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,SHADOW:.metadata.annotations.agents\.x-k8s\.io/migration-shadow"
   

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

שלב 2: שדרוג מישור הבקרה של GKE

משדרגים את מישור הבקרה של GKE לגרסה ‎1.36.3-gke.1767000 ואילך:

gcloud container clusters upgrade ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --master \
    --cluster-version=1.36.3-gke.1767000

במהלך ההשקה של מישור הבקרה, חשוב לשים לב לנקודות הבאות:

• השימוש ב-Pods לא דורש הפעלה מחדש או השבתה.
• הבקר החדש ונקודת הקצה של ה-webhook‏ /convert נפרסים במישור הבקרה.

אזהרה: שלב 3 הוא נקודת האל-חזור בהעברה ללא השבתה. הפעלת ./migrate.sh --phase=migrate כותבת מחדש את כל האובייקטים ב-etcd לסכימה v1beta1. אחרי השלב הזה, גרסאות ישנות יותר של מישור הבקרה לא יכולות לבצע דה-סריאליזציה של אובייקטים מסוג v1beta1. מוודאים ששלבים 1 ו-2 הושלמו בצורה תקינה לפני שממשיכים.

שלב 3: העברת האחסון אחרי השדרוג

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

./migrate.sh --phase=migrate

רשימת משימות לאימות אחרי ההעברה

סימון פריט	פקודה	התוצאה הצפויה
גרסאות אחסון של CustomResourceDefinition	kubectl get crd sandboxes.agents.x-k8s.io sandboxclaims.extensions.agents.x-k8s.io sandboxtemplates.extensions.agents.x-k8s.io sandboxwarmpools.extensions.agents.x-k8s.io -o jsonpath='{range .items[*]}{.metadata.name}{": storedVersions="}{.status.storedVersions}{"\n"}{end}'	כל 4 ההגדרות של CustomResourceDefinition מוצגות: storedVersions=["v1beta1"]
המשכיות של ה-Pod	kubectl get pods -n default -o wide	‫Status: 1/1 Running Restarts: 0 (רלוונטי לאשכולות עם ארגזי חול פעילים)
הצהרה על זכויות יוצרים	kubectl get sandboxclaims -n default -o yaml	‫spec.warmPoolRef.name: shadow-pool-... status.conditions: Ready=True (נדרשת התאמה של התבנית לדרישות הקבלה)
תאימות לגרסה v1alpha1	kubectl get sandboxes.v1alpha1.agents.x-k8s.io	הצגת אזהרה על הוצאה משימוש והחזרת משאב
v1beta1 native CRUD	kubectl apply -f sandbox-claim.yaml	ההגדרה חלה ללא אזהרות

אם CustomResourceDefinition ממשיך להציג את ["v1alpha1", "v1beta1"] ב-.status.storedVersions אחרי השלמת שלב ההעברה, זו התנהגות צפויה של Kubernetes. סקריפט ההעברה כותב מחדש את כל הרשומות הקיימות ל-v1beta1 ב-etcd, אבל מערכת Kubernetes לא מסירה באופן אוטומטי גרסאות שיצאו משימוש מהרשימה status.storedVersions.

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

for crd in \
    sandboxes.agents.x-k8s.io \
    sandboxclaims.extensions.agents.x-k8s.io \
    sandboxtemplates.extensions.agents.x-k8s.io \
    sandboxwarmpools.extensions.agents.x-k8s.io; do
  kubectl patch crd "${crd}" --subresource=status --type=merge \
    -p '{"status":{"storedVersions":["v1beta1"]}}'
done

פתרון בעיות בהעברה

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

• הצהרה על זכויות יוצרים תקועה במצב WarmPoolNotFound:

  • אם בוצעה שדרוג של תלונה מסוג v1alpha1 cold-start בלי להריץ את ./migrate.sh --phase=bootstrap, צריך ליצור ידנית את מאגר ה-warm pool החסר:

    apiVersion: extensions.agents.x-k8s.io/v1beta1
    kind: SandboxWarmPool
    metadata:
      name: shadow-pool-TEMPLATE_NAME
      namespace: NAMESPACE
      annotations:
        agents.x-k8s.io/migration-shadow: "true"
    spec:
      replicas: 0
      sandboxTemplateRef:
        name: TEMPLATE_NAME
    

  • אם בהצהרת הבעלות צוין מאגר חם ספציפי שכבר לא קיים, צריך ליצור את משאב SandboxWarmPool החסר עם השם הזה, או לעדכן את spec.warmPoolRef.name בהצהרת הבעלות כך שיפנה למאגר חם קיים.

• תנאי התלונה על הפרת זכויות יוצרים Ready=False: מריצים את kubectl describe sandboxclaim כדי לבדוק את האירועים שקשורים לתלונה. מוודאים שההפניה אל SandboxTemplate עומדת בכל דרישות הפריסה של ארגז חול של סוכן, ומחילים מחדש את התבנית אם צריך.

• שגיאות בהמרה או בבקר: כדי לוודא שהחכירה של בחירת המוביל במישור הבקרה פעילה, מריצים את הפקודה kubectl get leases -n gke-managed-agentsandbox. אם הבעיות נמשכות, אפשר לפנות אל Cloud Customer Care.

השבתת ארגז החול של הסוכן

כדי להשבית את התכונה Agent Sandbox, משתמשים בפקודה gcloud beta container clusters update עם הדגל --no-enable-agent-sandbox.

gcloud beta container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --no-enable-agent-sandbox

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

פינוי משאבים

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

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

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

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

• איך שומרים ומשחזרים סביבות ארגז חול של סוכנים באמצעות תמונות מצב של Pod
• מידע נוסף על הטכנולוגיה הבסיסית שמשמשת את Agent Sandbox
• מידע נוסף על אבטחה ב-GKE
• אפשר לעיין בפרויקט הקוד הפתוח Agent Sandbox ב-GitHub.
• כך משתמשים ב-Kata Containers עם Agent Sandbox. ‫Kata Containers הוא לא מוצר של Google Cloud . אם תתקינו את התוכנה הזו ותשתמשו בה, תהיו אחראים לניהול ולפתרון בעיות. התמיכה של Google והסכמי רמת השירות שלה לא חלים על Kata Containers.