‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פריסת קונטיינרים (GKE, ‏ Distributed Cloud)

בדף הזה מוסבר איך לפרוס קובץ אימג' של קונטיינר באשכול GKE (ב-Google Cloud או ב-Google Distributed Cloud) שבו מופעלת התכונה Binary Authorization. הפקודות של kubectl שמשמשות לפריסת האימג' זהות לפקודות שמשמשות לפריסת אימג'ים באשכולות שלא משתמשים ב-Binary Authorization.

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

מוודאים ש-Binary Authorization API מופעל בפרויקט, ושאשכול GKE מופעל באמצעות Binary Authorization. הגדרה ב-Google Kubernetes Engine או הגדרה ב-Distributed Cloud.

מתקינים את kubectl כדי לבצע אינטראקציה עם GKE.

הגדרה של `kubectl`

צריך לעדכן את הקובץ המקומי kubeconfig בהתקנה של kubectl. כך מקבלים את פרטי הכניסה ואת המידע על נקודת הקצה שנדרשים כדי לגשת לאשכול ב-GKE או ב-Distributed Cloud.

כדי להגדיר את kubectl, מריצים את הפקודה הבאה של gcloud:

GKE

gcloud container clusters get-credentials \
    --zone ZONE \
    CLUSTER_NAME

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

‫ZONE: השם של אזור GKE שבו פועל האשכול, למשל us-central1-a
‫CLUSTER_NAME: שם האשכול

Distributed Cloud

gcloud container fleet memberships get-credentials \
    --location LOCATION \
    MEMBERSHIP_NAME

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

‫LOCATION: המיקום של החברות ב-fleet של אשכול GKE, לדוגמה, global
‫MEMBERSHIP_NAME: השם של החברות ב-Fleet של אשכול GKE

פריסת קובץ האימג' של הקונטיינר

פורסים את קובץ האימג' של הקונטיינר באופן הבא:

מגדירים את משתני הסביבה:
```
POD_NAME=POD_NAME
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=IMAGE_DIGEST
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POD_NAME: השם שרוצים לתת לעומס העבודה ב-GKE
- ‫IMAGE_PATH: הנתיב של קובץ האימג' ב-Artifact Registry או במאגר אחר.
- ‫IMAGE_DIGEST: תקציר מניפסט התמונה. לדוגמה:
  - ‫Artifact Registry:
    - נתיב: us-docker.pkg.dev/google-samples/containers/gke/hello-app
    - תקציר: sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
  במאמר ניהול תמונות מוסבר איך מקבלים את התקציר של תמונה ב-Artifact Registry.
פורסים את קובץ האימג' באמצעות הפקודה kubectl run.

צריך לפרוס את קובץ האימג' באמצעות ה-digest ולא באמצעות תג כמו 1.0 או latest, כי ב-Binary Authorization משתמשים ב-digest כדי לחפש אישורים.

כדי לפרוס את קובץ האימג', מריצים את הפקודה הבאה של kubectl:
```
kubectl run ${POD_NAME} \
    --image ${IMAGE_PATH}@${IMAGE_DIGEST}
```
עכשיו בודקים שהפריסה נחסמה על ידי Binary Authorization:
```
kubectl get pods
```
ה-Pod שלכם מופיע ברשימה.

מגבלות

בזמן הפריסה, Binary Authorization סורק רק תמונות בשדות containers ו-ephemeralContainers של PodSpec. המערכת לא סורקת שדות אחרים. מאגרי Init ונפחי תמונות לא נסרקים בזמן הפריסה.

המשך פעילות במקרה שגיאה

אם מסיבה כלשהי ל-GKE אין גישה לשרת של Binary Authorization, או אם השרת מחזיר שגיאה, GKE לא יכול לקבוע אם Binary Authorization יאשר או ידחה את קובץ האימג'. במקרה כזה, GKE ממשיך לפעול במקרה שגיאה: כברירת מחדל, הוא מאפשר לפרוס את קובץ האימג', אבל יוצר רשומה ביומני הביקורת של Cloud כדי לתעד את הסיבה לכך.

האכיפה של GKE נכשלת במצב פתוח בגלל פשרה בין אמינות לאבטחה. בכל פעם שנוצר או מתעדכן Pod, ‏GKE שולח בקשה ל-Binary Authorization. זה כולל תרחישים שבהם Pods נוצרים או מתעדכנים באופן אוטומטי על ידי בקרי עומסי עבודה של Kubernetes ברמה גבוהה יותר, כמו ReplicaSets ו-StatefulSets. אם GKE היה נסגר במקרה של שגיאה במקום להיפתח, כל הפסקה בפעילות של Binary Authorization הייתה גורמת להפסקת הפעילות של ה-Pods האלה. בנוסף, כשפודים נדחים, יתירות כשל יכולה להוביל לכשלים מדורגים, כי התנועה שמופנית מחדש מעמיסה על הפודים שעדיין פועלים. כל הפסקה בפעילות של Binary Authorization עלולה לגרום להפסקה מוחלטת בפעילות של האשכול, גם בלי לפרוס קובצי אימג' חדשים.

פריסת תמונות שמפירות את המדיניות

ב-Binary Authorization יש תכונה שנקראת breakglass, שמאפשרת לפרוס קובץ אימג' גם אם הוא מפר את המדיניות.

מידע נוסף זמין במאמר שימוש ב-breakglass.

הסרת המשאבים

כדי לנקות, מוחקים את ה-Pod באמצעות הפקודה הבאה:

  kubectl delete pod ${POD_NAME}

פריסת קונטיינרים (GKE, ‏ Distributed Cloud) קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.