חיזוק הבידוד של עומסי עבודה באמצעות GKE Sandbox

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

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

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

הפעלת GKE Sandbox

‫GKE Sandbox מוכן לשימוש באשכולות Autopilot שמריצים את GKE בגרסה 1.27.4-gke.800 ואילך. כדי להתחיל לפרוס עומסי עבודה של Autopilot בסביבת Sandbox, אפשר לדלג אל עבודה עם GKE Sandbox.

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

למידע נוסף על גרסאות של GPU, אפשר לעיין בתמיכה בדגמי GPU.

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

הפעלת GKE Sandbox באשכול Standard חדש

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

המסוף

כדי לראות את האשכולות, נכנסים לתפריט Google Kubernetes Engine בGoogle Cloud מסוף.

  1. נכנסים לדף Create a Kubernetes cluster במסוף Google Cloud .

    מעבר אל יצירת אשכול Kubernetes

  2. אופציונלי, אבל מומלץ: בתפריט הניווט, בקטע Cluster, לוחצים על Features ומסמנים את תיבות הסימון הבאות כדי שהודעות gVisor יתועדו:

    • Cloud Logging
    • Cloud Monitoring
    • השירות המנוהל ל-Prometheus

  3. לוחצים על הוספת מאגר צמתים.

  4. בתפריט הניווט, בקטע Node Pools (מאגרי צמתים), מרחיבים את מאגר הצמתים החדש ולוחצים על Nodes (צמתים).

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

    1. ברשימה הנפתחת סוג התמונה בוחרים באפשרות מערכת הפעלה שעברה אופטימיזציה לשימוש בקונטיינרים עם Containerd‏ (cos_containerd). זהו סוג התמונה היחיד שנתמך ב-GKE Sandbox.
    2. בקטע Machine Configuration (הגדרת מכונה), בוחרים סדרה וסוג מכונה.

    3. אם אתם מריצים גרסה נתמכת של GKE ‎, אתם יכולים לבחור סוג GPU או TPU. הערך הזה חייב להיות אחד מסוגי ה-GPU הבאים:

      • ‫nvidia-gb200: NVIDIA GB200 NVL72 (תצוגה מקדימה)
      • ‫nvidia-b200: NVIDIA B200 (180GB) (תצוגה מקדימה)
      • ‫nvidia-h200-141gb: NVIDIA H200 ‏ (141GB) (תצוגה מקדימה)
      • ‫nvidia-h100-mega-80gb: NVIDIA H100 Mega (80GB)
      • ‫nvidia-h100-80gb: NVIDIA H100 (80GB)
      • ‫nvidia-a100-80gb: NVIDIA A100 (80GB)
      • ‫nvidia-tesla-a100: NVIDIA A100 (40GB)
      • ‫nvidia-rtx-pro-6000: NVIDIA RTX PRO 6000 (תצוגה מקדימה)
      • ‫nvidia-l4: NVIDIA L4
      • ‫nvidia-tesla-t4: NVIDIA T4
      מידע נוסף זמין במאמר בנושא תמיכה בדגמי GPU.

      או סוגי ה-TPU הבאים:

  6. בתפריט הניווט, מתחת לשם של מאגר הצמתים שאתם מגדירים, לוחצים על Security (אבטחה) ומסמנים את התיבה Enable sandbox with gVisor (הפעלת ארגז חול עם gVisor).

  7. ממשיכים להגדיר את האשכולות ואת מאגרי הצמתים לפי הצורך.

  8. לוחצים על יצירה.

gcloud

אי אפשר להפעיל את GKE Sandbox במאגר הצמתים שמוגדר כברירת מחדל, ואי אפשר ליצור מאגרי צמתים נוספים בזמן שיוצרים אשכול חדש באמצעות הפקודה gcloud. במקום זאת, יוצרים את האשכול כרגיל. מומלץ להפעיל את האפשרות Logging and Monitoring כדי שההודעות של gVisor יתועדו ביומן, למרות שזה לא חובה.

לאחר מכן משתמשים בפקודה gcloud container node-pools create ומגדירים את הדגל -- sandbox לערך type=gvisor. סוג תמונת הצומת צריך להיות cos_containerdב-GKE Sandbox.

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

מחליפים את המשתנים הבאים:

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫NODE_VERSION: הגרסה שבה ייעשה שימוש במאגר הצמתים.
  • ‫MACHINE_TYPE: סוג המכונה שבה רוצים להשתמש לצמתים.

כדי ליצור מאגר צמתים של GPU עם GKE Sandbox, מריצים את הפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=DRIVER_VERSION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

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

  • ‫GPU_TYPE: סוג GPU נתמך. פרטים נוספים זמינים במאמר בנושא GKE Sandbox.

  • ‫MACHINE_TYPE: מכונה שתואמת לסוג ה-GPU המבוקש. פרטים נוספים זמינים במאמר בנושא דרישות GPU ב-Google Kubernetes Engine.

  • ‫DRIVER_VERSION: גרסת הדרייבר של NVIDIA להתקנה. יכול להיות אחת מהאפשרויות הבאות:

    • ‫default: התקנת גרסת ברירת המחדל של הדרייבר לגרסת GKE.
    • ‫latest: התקנת הגרסה האחרונה של מנהל ההתקן שזמינה לגרסת GKE שלכם. האפשרות הזו זמינה רק לצמתים שמשתמשים במערכת הפעלה שמותאמת לקונטיינרים.

כדי ליצור מאגר צמתים של TPU עם GKE Sandbox, מריצים את הפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --num-nodes=NUM_NODES \
  --tpu-topology=TPU_TOPOLOGY \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor
  • ‫MACHINE_TYPE: סוג TPU נתמך. פרטים נוספים זמינים במאמר בנושא GKE Sandbox.

הפעלת GKE Sandbox באשכול Standard קיים

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

המסוף

כדי ליצור מאגר צמתים חדש עם GKE Sandbox מופעל:

  1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. לוחצים על השם של האשכול שרוצים לשנות.

  3. לוחצים על הוספת מאגר צמתים.

  4. מגדירים את הדף פרטי מאגר הצמתים לפי הצורך.

  5. בתפריט הניווט, לוחצים על Nodes ומגדירים את ההגדרות הבאות:

    1. ברשימה הנפתחת סוג התמונה בוחרים באפשרות מערכת הפעלה שעברה אופטימיזציה לשימוש בקונטיינרים עם Containerd‏ (cos_containerd). זהו סוג התמונה היחיד שנתמך ב-GKE Sandbox.
    2. בקטע Machine Configuration (הגדרת מכונה), בוחרים סדרה וסוג מכונה.

    3. אם אתם מריצים גרסה נתמכת של GKE ‎, אתם יכולים לבחור סוג GPU או TPU. הערך הזה חייב להיות אחד מסוגי ה-GPU הבאים

      • ‫nvidia-gb200: NVIDIA GB200 NVL72 (תצוגה מקדימה)
      • ‫nvidia-b200: NVIDIA B200 (180GB) (תצוגה מקדימה)
      • ‫nvidia-h200-141gb: NVIDIA H200 ‏ (141GB) (תצוגה מקדימה)
      • ‫nvidia-h100-mega-80gb: NVIDIA H100 Mega (80GB)
      • ‫nvidia-h100-80gb: NVIDIA H100 (80GB)
      • ‫nvidia-a100-80gb: NVIDIA A100 (80GB)
      • ‫nvidia-tesla-a100: NVIDIA A100 (40GB)
      • ‫nvidia-rtx-pro-6000: NVIDIA RTX PRO 6000 (תצוגה מקדימה)
      • ‫nvidia-l4: NVIDIA L4
      • ‫nvidia-tesla-t4: NVIDIA T4
      מידע נוסף זמין במאמר בנושא תמיכה בדגמי GPU.

      או סוגי ה-TPU הבאים:

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

  7. לוחצים על יצירה.

gcloud

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

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

סוג תמונת הצומת צריך להיות cos_containerd בשביל GKE Sandbox.

כדי ליצור מאגר צמתים של GPU עם GKE Sandbox, מריצים את הפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=DRIVER_VERSION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

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

  • ‫GPU_TYPE: סוג GPU נתמך. פרטים נוספים זמינים במאמר בנושא GKE Sandbox.

  • ‫MACHINE_TYPE: מכונה שתואמת לסוג ה-GPU המבוקש. פרטים נוספים זמינים במאמר בנושא דרישות GPU ב-Google Kubernetes Engine.

  • ‫DRIVER_VERSION: גרסת הדרייבר של NVIDIA להתקנה. יכול להיות אחת מהאפשרויות הבאות:

    • ‫default: התקנת גרסת ברירת המחדל של הדרייבר לגרסת GKE.
    • ‫latest: התקנת הגרסה האחרונה של מנהל ההתקן שזמינה לגרסת GKE שלכם. האפשרות הזו זמינה רק לצמתים שמשתמשים במערכת הפעלה שמותאמת לקונטיינרים.

כדי ליצור מאגר צמתים של TPU עם GKE Sandbox, מריצים את הפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --num-nodes=NUM_NODES \
  --tpu-topology=TPU_TOPOLOGY \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor
  • ‫MACHINE_TYPE: סוג TPU נתמך. פרטים נוספים זמינים במאמר בנושא GKE Sandbox.

אופציונלי: הפעלת מעקב ורישום ביומן

מומלץ להפעיל את Cloud Logging ואת Cloud Monitoring באשכול, כדי שההודעות של gVisor יתועדו ביומן. השירותים האלה מופעלים כברירת מחדל באשכולות חדשים.

אתם יכולים להשתמש במסוף Google Cloud כדי להפעיל את התכונות האלה באוסף קיים.

  1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. לוחצים על השם של האשכול שרוצים לשנות.

  3. בקטע Features (מאפיינים), בשדה Cloud Logging (רישום ביומן ב-Cloud), לוחצים על Edit Cloud Logging (עריכת רישום ביומן ב-Cloud).

  4. מסמנים את תיבת הסימון הפעלת Cloud Logging.

  5. לוחצים על שמירת השינויים.

  6. חוזרים על אותם השלבים בשדות Cloud Monitoring ו-שירות מנוהל ל-Prometheus כדי להפעיל את התכונות האלה.

שימוש ב-GKE Sandbox במצבי Autopilot ו-Standard

באשכולות Autopilot ובאשכולות Standard שבהם מופעל GKE Sandbox, כדי לבקש סביבת ארגז חול עבור Pod, צריך לציין את gvisor RuntimeClass במפרט של ה-Pod.

במקרים של אשכולות Autopilot, צריך לוודא שפועלת גרסת GKE‏ 1.27.4-gke.800 ואילך.

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

כדי להפעיל פריסה בצומת עם GKE Sandbox, צריך להגדיר את הערך spec.template.spec.runtimeClassName ל-gvisor, כמו בדוגמה הבאה:

# httpd.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      runtimeClassName: gvisor
      containers:
      - name: httpd
        image: httpd

יוצרים את הפריסה:

kubectl apply -f httpd.yaml

ה-Pod נפרס בצומת עם GKE Sandbox מופעל. כדי לאמת את הפריסה, מאתרים את הצומת שבו ה-Pod נפרס:

kubectl get pods

הפלט אמור להיראות כך:

NAME                    READY   STATUS    RESTARTS   AGE
httpd-db5899bc9-dk7lk   1/1     Running   0          24s

בפלט, מחפשים את שם ה-Pod בפלט ואז בודקים את הערך של RuntimeClass:

kubectl get pods POD_NAME -o jsonpath='{.spec.runtimeClassName}'

הפלט הוא gvisor.

לחלופין, אפשר להציג את RuntimeClass של כל Pod ולחפש את ה-Pods שבהם הוא מוגדר כ-gvisor:

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

הפלט שיתקבל:

POD_NAME: gvisor

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

הרצת Pod עם מאיצים ב-GKE Sandbox

כדי להריץ עומס עבודה של GPU או TPU ב-GKE Sandbox, מוסיפים את השדה runtimeClassName: gvisor למניפסט כמו בדוגמאות הבאות:

  • קובץ מניפסט לדוגמה של GPU Pods במצב רגיל:

    apiVersion: v1
kind: Pod
metadata:
  name: my-gpu-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: my-gpu-container
    image: nvidia/samples:vectoradd-cuda10.2
    resources:
      limits:
        nvidia.com/gpu: 1

  • דוגמה למניפסט של Pods של GPU במצב Autopilot:

    apiVersion: v1
kind: Pod
metadata:
  name: my-gpu-pod
spec:
  runtimeClassName: gvisor
  nodeSelector:
    cloud.google.com/gke-gpu-driver-version: "latest"
    cloud.google.com/gke-accelerator: nvidia-tesla-t4
  containers:
  - name: my-gpu-container
    image: nvidia/samples:vectoradd-cuda10.2
    resources:
      limits:
        nvidia.com/gpu: 1

  • דוגמה לקובץ מניפסט עבור TPU Pods במצב Standard או במצב Autopilot:

    apiVersion: v1
kind: Pod
metadata:
  name: my-tpu-pod
spec:
  runtimeClassName: gvisor
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
    cloud.google.com/gke-tpu-topology: 1x1
  containers:
  - name: my-tpu-container
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    command:
      - bash
      - -c
      - |
        python -c 'import jax; print("TPU cores:", jax.device_count())'
    resources:
      limits:
        google.com/tpu: 1
      requests:
        google.com/tpu: 1

אפשר להריץ ב-GKE Sandbox כל Pod של מאיץ במצב Autopilot או Standard שעומד בדרישות לגבי הגרסה וסוג המאיץ, על ידי הוספת השדה runtimeClassName: gvisor למניפסט. כדי להפעיל GPU Pods ב-GKE, אפשר לעיין במאמרים הבאים:

כדי להפעיל TPU Pods ב-GKE, אפשר לעיין במאמרים הבאים:

אלה סוגי ה-GPU שנתמכים ב-Autopilot:

  • ‫nvidia-gb200: NVIDIA GB200 NVL72 (תצוגה מקדימה)
  • ‫nvidia-b200: NVIDIA B200 (180GB) (תצוגה מקדימה)
  • ‫nvidia-h200-141gb: NVIDIA H200 ‏ (141GB) (תצוגה מקדימה)
  • ‫nvidia-h100-mega-80gb: NVIDIA H100 Mega (80GB)
  • ‫nvidia-h100-80gb: NVIDIA H100 (80GB)
  • ‫nvidia-a100-80gb: NVIDIA A100 (80GB)
  • ‫nvidia-tesla-a100: NVIDIA A100 (40GB)
  • ‫nvidia-rtx-pro-6000: NVIDIA RTX PRO 6000 (תצוגה מקדימה)
  • ‫nvidia-l4: NVIDIA L4
  • ‫nvidia-tesla-t4: NVIDIA T4
מידע נוסף זמין במאמר בנושא תמיכה במודלים של GPU.

הפעלת Pod רגיל לצד Pods בארגז חול

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

אחרי שמפעילים את GKE Sandbox במאגר צמתים, אפשר להריץ צמתים מהימנים בלי להשתמש ב-Sandbox, באמצעות taints ו-tolerations של צמתים. ה-Pods האלה נקראים 'Pods רגילים' כדי להבדיל ביניהם לבין Pods בסביבת ארגז חול.

ל-Pods רגילים, כמו ל-Pods בסביבת ארגז חול, אין גישה לGoogle Cloud שירותים אחרים או למטא-נתונים של האשכול. המניעה הזו היא חלק מההגדרה של הצומת. אם קבוצות ה-Pod הרגילות או קבוצות ה-Pod בסביבת ארגז חול צריכות גישה לשירותים שלGoogle Cloud , צריך להשתמש ב-איחוד זהויות של עומסי עבודה ל-GKE.

‫GKE Sandbox מוסיף את התווית והכתם הבאים לצמתים שיכולים להריץ Pods ב-Sandbox:

labels:
  sandbox.gke.io/runtime: gvisor

taints:
- effect: NoSchedule
  key: sandbox.gke.io/runtime
  value: gvisor

בנוסף להגדרות של node affinity ו-טולרנטיות במניפסט של ה-Pod,‏ GKE Sandbox מחיל את ההגדרות הבאות של node affinity ו-טולרנטיות על כל ה-Pods עם RuntimeClass שמוגדר ל-gvisor:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: sandbox.gke.io/runtime
          operator: In
          values:
          - gvisor

tolerations:
  - effect: NoSchedule
    key: sandbox.gke.io/runtime
    operator: Equal
    value: gvisor

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

  • אם ה-Pod שלכם יכול לפעול בצמתים עם GKE Sandbox מופעל, מוסיפים את ה-toleration.
  • אם ה-Pod שלכם חייב לפעול בצמתים עם GKE Sandbox מופעל, צריך להוסיף גם את ההגדרה node affinity וגם את ההגדרה toleration.

לדוגמה, המניפסט הבא משנה את המניפסט שבו נעשה שימוש במאמר הרצת אפליקציה בארגז חול כך שהאפליקציה תפעל כ-Pod רגיל בצומת עם Pods בארגז חול. השינוי מתבצע על ידי הסרת runtimeClass והוספה של דחייה (taint) וטולרנטיות כפי שמתואר בהמשך.

# httpd-no-sandbox.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-no-sandbox
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor

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

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

הפלט אמור להיראות כך:

httpd-db5899bc9-dk7lk: gvisor
httpd-no-sandbox-5bf87996c6-cfmmd:

הפריסה httpd שנוצרה קודם פועלת בסביבת ארגז חול, כי runtimeClass שלה הוא gvisor. לפריסת httpd-no-sandbox אין ערך ל-runtimeClass, ולכן היא לא פועלת בסביבת ארגז חול.

לאחר מכן, מריצים את הפקודה הבאה כדי לוודא שפריסת ה-Deployment שלא מוגבלת לארגז חול פועלת בצומת עם GKE Sandbox:

kubectl get pod -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.nodeName}\n{end}'

שם מאגר הצמתים מוטמע בערך של nodeName. מוודאים ש-Pod פועל בצומת במאגר צמתים עם GKE Sandbox מופעל.

אימות של הגנה על מטא-נתונים

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

  1. יוצרים פריסה בסביבת ארגז חול מהמניפסט הבא באמצעות kubectl apply -f. הוא משתמש בתמונה fedora, שכוללת את הפקודה curl. ה-Pod מריץ את הפקודה /bin/sleep כדי לוודא שהפריסה תפעל למשך 10,000 שניות.

    # sandbox-metadata-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fedora
  labels:
    app: fedora
spec:
  replicas: 1
  selector:
    matchLabels:
      app: fedora
  template:
    metadata:
      labels:
        app: fedora
    spec:
      runtimeClassName: gvisor
      containers:
      - name: fedora
        image: fedora
        command: ["/bin/sleep","10000"]

  2. כדי לקבל את שם ה-Pod, משתמשים בפקודה kubectl get pods, ואז משתמשים בפקודה kubectl exec כדי להתחבר ל-Pod באופן אינטראקטיבי.

    kubectl exec -it POD_NAME /bin/sh

    אתם מחוברים למאגר שפועל ב-Pod, בסשן /bin/sh.

  3. בסשן האינטראקטיבי, מנסים לגשת לכתובת URL שמחזירה מטא-נתונים של אשכול:

    curl -s "http://169.254.169.254/computeMetadata/v1/instance/attributes/kube-env" -H "Metadata-Flavor: Google"

    הפקודה נתקעת ובסופו של דבר מגיעה לזמן קצוב לתפוגה, כי המנות מושמטות בשקט.

  4. מקישים על Ctrl+C כדי להפסיק את הפקודה curl, ומקלידים exit כדי להתנתק מה-Pod.

  5. מסירים את השורה RuntimeClass ממניפסט ה-YAML ומבצעים פריסה מחדש של ה-Pod באמצעות kubectl apply -f FILENAME. ה-Pod ב-Sandbox מופסק ונוצר מחדש בצומת ללא GKE Sandbox.

  6. מקבלים את השם החדש של ה-Pod, מתחברים אליו באמצעות kubectl exec ומריצים שוב את הפקודה curl. הפעם, התוצאות מוחזרות. הפלט של הדוגמה הזו קוצר.

    ALLOCATE_NODE_CIDRS: "true"
API_SERVER_TEST_LOG_LEVEL: --v=3
AUTOSCALER_ENV_VARS: kube_reserved=cpu=60m,memory=960Mi,ephemeral-storage=41Gi;...
...

    מקלידים exit כדי להתנתק מה-Pod.

  7. מסירים את הפריסה:

    kubectl delete deployment fedora

השבתת GKE Sandbox

אי אפשר להשבית את GKE Sandbox באשכולות GKE Autopilot או במאגרי צמתים של GKE Standard. אם רוצים להפסיק להשתמש ב-GKE Sandbox, צריך למחוק את מאגר הצמתים.

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