שימוש בסטרימינג של תמונות כדי לשלוף תמונות של קונטיינרים

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

אשכולות Autopilot משתמשים באופן אוטומטי בסטרימינג של אימג'ים כדי לשלוף אימג'ים שעומדים בדרישות. ההוראות בדף הזה לגבי הפעלה והשבתה של סטרימינג של קובצי אימג' רלוונטיות לאשכולות Standard.

סקירה כללית

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

  • התאמה מהירה יותר לעומס (autoscaling)
  • זמן אחזור קצר יותר כששולפים תמונות גדולות
  • הפעלה מהירה יותר של Pod

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

בזמן הסטרימינג של נתוני קובץ האימג', GKE מוריד את כל קובץ האימג' של הקונטיינר לדיסק המקומי ברקע ושומר אותו במטמון. לאחר מכן, GKE משרת בקשות עתידיות לקריאת נתונים מהתמונה שנשמרה במטמון.

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

דרישות

כדי להשתמש בסטרימינג של תמונות באשכולות GKE Autopilot ו-Standard, צריך לעמוד בדרישות הבאות:

  • צריך להפעיל את Container File System API.

    הפעלת Container File System API

  • צריך להשתמש בתמונת צומת עם containerd. האפשרויות הנתמכות כוללות:

  • קובצי האימג' של הקונטיינרים צריכים להיות מאוחסנים במאגרים רגילים או מרוחקים ב-Artifact Registry, או במאגרים ציבוריים ב-Docker Hub.

  • אם מפעילים צמתים פרטיים באשכול, צריך להפעיל גישה פרטית ל-Google ברשת המשנה כדי שהצמתים יוכלו לגשת לשירות הסטרימינג של קובצי האימג'.

  • אם אתם משתמשים ב-VPC Service Controls כדי להגן על קובצי האימג' של הקונטיינרים, ובנוסף אתם משתמשים בסטרימינג של קובצי אימג', אתם צריכים לכלול גם את Image streaming API‏ (containerfilesystem.googleapis.com) בגבולות הגזרה לשירות.

  • אם צומתי GKE באשכול לא משתמשים בחשבון השירות שמוגדר כברירת מחדל, צריך לוודא שלחשבון השירות בהתאמה אישית יש את התפקיד Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) ב-IAM בפרויקט שמארח את קובץ האימג' של הקונטיינר.

מגבלות

  • אי אפשר להשתמש בקובצי אימג' של קונטיינרים שמשתמשים ב-V2 Image Manifest, schema version 1.
  • אין תמיכה בקובצי אימג' של קונטיינרים עם שכבות כפולות. ‫GKE מוריד את קובצי האימג' האלה בלי להעביר את הנתונים בסטרימינג. בודקים אם יש בקובץ האימג' של הקונטיינר שכבות ריקות או שכבות כפולות.
  • אם עומסי העבודה שלכם קוראים קבצים רבים בתמונה במהלך האתחול, יכול להיות שתבחינו בזמני אתחול ארוכים יותר בגלל זמן האחזור שנוסף על ידי קריאת הקבצים מרחוק.
  • אם עומסי העבודה שלכם דורשים שחלק גדול מהתמונה יהיה זמין לפני שהקוד יוכל לפעול, יכול להיות שיהיה עיכוב בין הזמן שבו kubelet מפעיל את הקונטיינר לבין הזמן שבו הקונטיינר מתחיל לשלוח יומנים בפועל.
  • יכול להיות שלא תבחינו ביתרונות של סטרימינג של תמונות במהלך השליפה הראשונה של תמונה שעומדת בדרישות. עם זאת, אחרי שהתמונה נשמרת במטמון של Image streaming, כל שליפה עתידית של התמונה בכל אשכול תיהנה מ-Image streaming.
  • באשכולות GKE Standard, ההגדרה ברמת האשכול קובעת אם להפעיל את Image streaming במאגרי צמתים חדשים שנוצרו באמצעות יצירה אוטומטית של מאגרי צמתים. עם זאת, אי אפשר להשתמש בהפרדת עומסי עבודה כדי ליצור מאגרי צמתים שבהם הסטרימינג של קובצי אימג' מופעל, אם הסטרימינג של קובצי אימג' מושבת ברמת האשכול.
  • מרחבי שמות של משתמשי Kubernetes: יכול להיות שפודים שמוגדרים עם מרחבי שמות של משתמשים (spec.hostUsers: false) לא יתחילו לפעול ב-GKE אם הפעלתם סטרימינג של קובצי אימג' גדולים של קונטיינרים. הכשל הזה קורה כי כלי ברירת המחדל ליצירת קובצי snapshot לא תומך בנקודות טעינה עם מיפוי מזהים למיפוי מחדש של מזהה משתמש (UID) ומזהה קבוצה (GID). כתוצאה מכך, הזמן הקצוב ליצירת קונטיינר פג במהלך שינויים רקורסיביים בבעלות על קבצים. כדי לעקוף את הבעיה, יוצרים מאגר צמתים חדש באמצעות הדגל --node-labels="cloud.google.com/gke-gcfs-v2-forbid=true". הדגל הזה משבית את כלי ברירת המחדל ליצירת קובצי snapshot ומשתמש בהתנהגות הקודמת של הכלי ליצירת קובצי snapshot.

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

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

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

הפעלת סטרימינג של תמונות באשכולות

כדי להפעיל את הסטרימינג של קובצי אימג' באשכולות רגילים חדשים או קיימים, אפשר להשתמש בדגל --enable-image-streaming של ה-CLI של gcloud או במסוףGoogle Cloud . כשיוצרים אשכול עם הדגל --enable-image-streaming, הסטרימינג של קובצי אימג' מופעל במאגר הצמתים שמוגדר כברירת מחדל. התכונה "סטרימינג של קובצי אימג'" תופעל גם במאגרי צמתים חדשים שתיצרו, אלא אם תשביתו אותה בזמן יצירת מאגרי הצמתים.

כל האשכולות של Autopilot משתמשים בהעברת קובצי אימג' בסטרימינג כדי לשלוף קובצי אימג' מתאימים. הוראות מפורטות זמינות במאמר הגדרת הגרסה וערוץ ההפצה של אשכול Autopilot חדש. ההוראות הבאות רלוונטיות רק לאשכולות GKE Standard.

אפשר להפעיל את הסטרימינג של קובצי אימג' באשכולות קיימים שעומדים בדרישות באמצעות ה-CLI של gcloud או מסוף Google Cloud .

gcloud

כדי לעדכן אשכול קיים כך שישתמש בסטרימינג של קובצי אימג', מריצים את הפקודה הבאה באמצעות ה-CLI של gcloud:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-image-streaming

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.

המסוף

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

    כניסה ל-Google Kubernetes Engine

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

  3. בדף Clusters, בקטע Features, לוחצים על ליד Image streaming.

  4. בתיבת הדו-שיח Edit Image streaming, מסמנים את התיבה Enable Image streaming.

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

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

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

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

איך מוודאים שהעברת ה-Image בסטרימינג מופעלת באשכול

אתם יכולים לבדוק אם הסטרימינג של קובצי אימג' מופעל ברמת האשכול באמצעות ה-CLI של gcloud או מסוף Google Cloud .

gcloud

מריצים את הפקודה הבאה:

gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --flatten "nodePoolDefaults.nodeConfigDefaults"

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.

ההגדרה מופעלת אם הפלט דומה לזה:

gcfsConfig:
  enabled: true
...

ההגדרה מושבתת אם הפלט דומה לפלט הבא:

gcfsConfig: {}
...

המסוף

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

    כניסה ל-Google Kubernetes Engine

  2. לוחצים על שם האשכול שרוצים לבדוק.

  3. בדף Clusters, בקטע Features, ליד Image streaming, מוצג אם ההגדרה מופעלת.

הפעלת סטרימינג של תמונות במאגרי צמתים

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

במאגר צמתים חדש

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

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --image-type=IMAGE_TYPE \
    --enable-image-streaming

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

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
  • ‫CLUSTER_NAME: שם האשכול של מאגר הצמתים.
  • ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. לאשכולות אזוריים צריך לציין אזור, ולאשכולות של תחומים צריך לציין תחום.
  • ‫IMAGE_TYPE: סוג קובץ האימג', COS_CONTAINERD (מערכת הפעלה שמותאמת לקונטיינרים) או UBUNTU_CONTAINERD (Ubuntu).

במאגר צמתים קיים

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

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

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-image-streaming

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

  • ‫POOL_NAME: השם של מאגר הצמתים.
  • ‫CLUSTER_NAME: שם האשכול של מאגר הצמתים.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.

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

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

אימות שהאפשרות "סטרימינג של תמונות" מופעלת במאגר צמתים

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

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

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

  • ‫POOL_NAME: השם של מאגר הצמתים.
  • ‫CLUSTER_NAME: שם האשכול של מאגר הצמתים.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.

ההגדרה מופעלת אם הפלט דומה לזה:

gcfsConfig:
  enabled: true
...

ההגדרה מושבתת אם הפלט דומה לפלט הבא:

gcfsConfig: {}
...

תזמון עומס עבודה באמצעות סטרימינג של קובצי אימג'

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

‫GKE מוסיף את התווית cloud.google.com/gke-image-streaming: "true" לצמתים במאגרי צמתים שבהם הופעל סטרימינג של קובצי אימג'. ב-GKE Standard, אם אתם מפעילים או משביתים את הסטרימינג של קובצי אימג' במאגרי צמתים ספציפיים, כך שהאשכול שלכם כולל שילוב של צמתים שמשתמשים בסטרימינג של קובצי אימג' וצמתים שלא משתמשים בו, אתם יכולים להשתמש בבוררי צמתים בפריסות שלכם כדי לקבוע אם GKE יתזמן את עומסי העבודה שלכם בצמתים שמשתמשים בסטרימינג של קובצי אימג'.

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

  1. יוצרים אשכול חדש עם סטרימינג של תמונות:

    gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-image-streaming \
    --image-type=IMAGE_TYPE

  2. מקבלים את פרטי הכניסה לאשכול:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

  3. שומרים את המניפסט הבא בתור frontend-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: guestbook
      tier: frontend
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5
        env:
        - name: GET_HOSTS_FROM
          value: "dns"
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 80

    הגודל של קובץ האימג' של הקונטיינר gb-frontend הוא 327MB.

  4. מחילים את המניפסט על האשכול:

    kubectl apply -f frontend-deployment.yaml

  5. מוודאים ש-GKE יצר את הפריסה:

    kubectl get pods -l app=guestbook

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

    NAMESPACE    NAME                          READY    STATUS       RESTARTS    AGE
default      frontend-64bcc69c4b-pgzgm     1/1      Completed    0           3s

  6. כדי לראות אירועים של משיכת קובצי אימג', פותחים את יומן האירועים של Kubernetes:

    kubectl get events --all-namespaces

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

    NAMESPACE  LAST SEEN  TYPE    REASON          OBJECT                                                 MESSAGE
default    11m        Normal  Pulling         pod/frontend-64bcc69c4b-pgzgm                          Pulling image "us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5"
default    11m        Normal  Pulled          pod/frontend-64bcc69c4b-pgzgm                          Successfully pulled image "us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5" in 1.536908032s
default    11m        Normal  ImageStreaming  node/gke-riptide-cluster-default-pool-f1552ec4-0pjv    Image us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5 is backed by image streaming.
...

    בפלט הזה:

    • האירוע Pulled מציג את משך הזמן שלוקח ל-Image streaming לשלוף את קובץ האימג'.

    • האירוע ImageStreaming מראה שהצומת משתמש בסטרימינג של קובצי אימג' כדי להציג את קובץ האימג' של הקונטיינר.

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

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

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

    gcloud container clusters create CLUSTER2_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --image-type=IMAGE_TYPE

  2. מקבלים את פרטי הכניסה לאשכול:

    gcloud container clusters get-credentials CLUSTER2_NAME \
    --location=CONTROL_PLANE_LOCATION

  3. פורסים את הפריסה frontend מהדוגמה הקודמת:

    kubectl apply -f frontend-deployment.yaml

  4. מורידים את יומן האירועים של Kubernetes:

    kubectl get events --all-namespaces

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

     NAMESPACE  LAST SEEN  TYPE    REASON     OBJECT                             MESSAGE
 default    87s        Normal  Pulled     pod/frontend-64bcc69c4b-qwmfp      Successfully pulled image "us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5" in 23.929723476s

    שימו לב לזמן שלקח ל-GKE לשלוף את קובץ האימג' כולו. בדוגמה הזו, ל-GKE נדרשו כמעט 24 שניות. כשהתכונה "העברת תמונות בסטרימינג" מופעלת, ל-GKE נדרשו רק 1.5 שניות כדי לשלוף את נתוני קובץ האימג' שעומס העבודה נדרש כדי להתחיל.

הסרת המשאבים

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

gcloud container clusters delete CLUSTER_NAME CLUSTER2_NAME \
    --location=CONTROL_PLANE_LOCATION

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

  • ‫CLUSTER_NAME: השם של האשכול הראשון.
  • ‫CLUSTER2_NAME: השם של האשכול השני.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכולות.

השבתת סטרימינג של תמונות

אם אתם משתמשים ב-GKE Autopilot, אתם לא יכולים להשבית את הסטרימינג של קובצי אימג' באשכולות ספציפיים. עם זאת, אתם יכולים להשבית את Container File System API לכל הפרויקט, וכך להשבית את הסטרימינג של קובצי אימג' ולחזור למשיכות רגילות של קובצי אימג'.

אם אתם משתמשים באשכולות GKE Standard, אתם יכולים להשבית את הסטרימינג של קובצי אימג' באשכולות ספציפיים או במאגרי צמתים ספציפיים, כמו שמתואר בקטעים הבאים.

השבתת סטרימינג של תמונות באשכול GKE Standard

אתם יכולים להשבית את הסטרימינג של אימג'ים באשכולות GKE Standard קיימים באמצעות ה-CLI של gcloud או מסוףGoogle Cloud .

gcloud

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

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-image-streaming

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.

המסוף

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

    כניסה ל-Google Kubernetes Engine

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

  3. בדף Clusters, בקטע Features, לוחצים על ליד Image streaming.

  4. בתיבת הדו-שיח Edit Image streaming, מבטלים את הסימון של התיבה Enable Image streaming.

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

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

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

במאגר צמתים חדש

כדי להשבית את הסטרימינג של קובצי אימג' כשיוצרים מאגר חדש של צומתי Kubernetes, מציינים את הדגל --no-enable-image-streaming, כמו בפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-image-streaming

במאגרי צמתים שנוצרו באופן אוטומטי

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

בגרסה 1.34.1-gke.1279000 ואילך של GKE, אפשר גם לשלוט בנפרד בסטרימינג של קובצי אימג' במאגרי צמתים שנוצרו על ידי ComputeClass, על ידי ציון המאפיין spec.nodePoolConfig.imageStreaming:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: image-streaming-class
spec:
  nodePoolConfig:
    imageStreaming
      enabled: true
  priorities:
  - machineFamily: n4
  nodePoolAutoCreation:
    enabled: true

במאגר צמתים קיים

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

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-image-streaming

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

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים.
  • ‫CLUSTER_NAME: שם האשכול של מאגר הצמתים.
  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.

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

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

הקצאת זיכרון לסטרימינג של תמונות

ב-GKE, משאבי הזיכרון שמורים לסטרימינג של קובצי אימג', בנוסף לזיכרון ששמור להרצת רכיבי המערכת של הצומת. ‫GKE לא שומר משאבי מעבד (CPU) נוספים לסטרימינג של תמונות. באשכולות GKE Standard, ההקצאה הזו משנה את משאבי הזיכרון שזמינים לבקשה ב-Pods. ב-GKE Autopilot, ‏ GKE מנהל את הקצאות המערכת, כך שאין השפעה על תזמון עומסי העבודה.

לפרטים על הקצאות הזיכרון ש-GKE מבצע לרכיבי צומת, ראו ארכיטקטורת אשכול רגילה.

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

  • אין זיכרון נוסף למכונות עם פחות מ-1GiB זיכרון
  • ‫1% מ-4GiB הראשונים של הזיכרון
  • ‫0.8% מ-4GiB הבאים של הזיכרון (עד 8GiB)
  • ‫0.4% מ-8GiB הבאים של הזיכרון (עד 16GiB)
  • ‫0.24% מ-112GiB הבאים של הזיכרון (עד 128GiB)
  • ‫0.08% מכל זיכרון מעל 128GiB

פתרון בעיות

בקטעים הבאים מפורטות עצות לפתרון בעיות בסטרימינג של תמונות. לייעוץ בנושא פתרון בעיות בשליפת תמונות רגילות, ראו פתרון בעיות בשליפת תמונות.

‫GKE לא משתמש במערכת הקבצים של סטרימינג של קובצי אימג'

אם יומן האירועים של GKE לא מציג את אירועי הסטרימינג של קובצי האימג', קובץ האימג' לא מגובה על ידי מערכת הקבצים המרוחקת. אם GKE כבר שלף את קובץ האימג' בצומת, זו התנהגות צפויה כי GKE משתמש במטמון המקומי של קובץ האימג' לשליפות הבאות במקום להשתמש בסטרימינג של קובצי אימג'. כדי לוודא שהאירוע נשלח, מחפשים את הערך Container image IMAGE_NAME already present on machine בשדה Message של האירוע Pulled ב-Pod.

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

  1. נכנסים לדף Logs Explorer במסוף Google Cloud :

    כניסה לדף Logs Explorer

  2. בשדה Query, מציינים את השאילתה הבאה:

    logName="projects/PROJECT_ID/logs/gcfsd"
resource.labels.cluster_name="CLUSTER_NAME"

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

    • ‫PROJECT_ID: שם הפרויקט.
    • ‫CLUSTER_NAME: שם האשכול.

  3. לוחצים על Run query.

אפשר גם לבדוק את היומנים של gcfsd באמצעות Logs Explorer:

  1. נכנסים לדף Logs Explorer במסוף Google Cloud :

    כניסה לדף Logs Explorer

  2. בשדה Query, מציינים את השאילתה הבאה:

    logName="projects/PROJECT_ID/logs/gcfsd"

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

PermissionDenied

אם ביומני gcfsd מופיעה הודעת שגיאה שדומה להודעה הבאה, לצומת אין את היקף ה-API הנכון. ‫GKE שולף קובצי אימג' של קונטיינרים לעומסי עבודה בלי להשתמש בסטרימינג של קובצי אימג'.

level=fatal msg="Failed to create a Container File System client: rpc error:
code = PermissionDenied desc = failed to probe endpoint: rpc error: code = PermissionDenied
desc = Request had insufficient authentication scopes."

כדי לתקן את השגיאה, צריך להקצות לצומת את ההיקף הנכון כדי לאפשר לו להשתמש בסטרימינג של קובצי אימג'. מוסיפים את ההיקף devstorage.read_only לאשכול או למאגר הצמתים, בדומה לפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --image-type=IMAGE_TYPE \
    --enable-image-streaming \
    --scopes="https://www.googleapis.com/auth/devstorage.read_only"

FailedPrecondition

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

יכול להיות שתראו את השגיאה הזו אם ניסיתם להשתמש בסטרימינג של תמונות עם מאגר צמתים קיים. אם לאחד מהצמתים במאגר הצמתים כבר יש את קובץ האימג' של הקונטיינר בדיסק, GKE משתמש בקובץ האימג' המקומי במקום להשתמש בסטרימינג של קובצי אימג' כדי לקבל את קובץ האימג'.

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

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

InvalidArgument

אם מופיעה הודעת שגיאה עם code=InvalidArgument, קובץ האימג' של הקונטיינר שבו משתמש עומס העבודה לא כשיר להעברת קובצי אימג' בסטרימינג. מוודאים שהתמונה עומדת בדרישות. אם התמונה לא נמצאת ב-Artifact Registry, נסו להעביר אותה לשם.

backend.FileContent failed

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

level=error msg="backend.FileContent failed" error="rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Content requests per project per region' and limit 'Content requests per project per region per minute per region' of service 'containerfilesystem.googleapis.com' for consumer 'project_number:PROJECT_NUMBER'." layer_id="sha256:1234567890" module=gcfs_backend offset=0 path=etc/passwd size=4096

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

  • בקשות תוכן לכל פרויקט, לכל אזור, לדקה, לכל אזור
  • בקשות תוכן לכל פרויקט בכל אזור

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

אם שירות הסטרימינג של קובצי האימג' (gcfsd) מופעל מחדש בצומת, קונטיינרים שפועלים ומשתמשים בסטרימינג של קובצי אימג' עלולים להיתקל בשגיאות קלט/פלט בדיסק, כמו stale file handle, כשהם מנסים לגשת לקבצים בקובץ האימג' של הקונטיינר.

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

‫GKE מוריד את קובץ האימג' בלי להעביר את הנתונים בסטרימינג

אפשר להשתמש בסטרימינג של קובצי אימג' של קונטיינרים עם מפתחות הצפנה בניהול הלקוח (CMEK) רק ב-GKE מגרסה 1.25.3-gke.1000 ואילך. אי אפשר להשתמש בסטרימינג של קובצי אימג' בקובצי אימג' של קונטיינרים עם שכבות כפולות. מידע נוסף מופיע בקטע מגבלות.

בדיקה אם יש שכבות ריקות או שכבות כפולות

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

docker inspect IMAGE_NAME

מחליפים את IMAGE_NAME בשם של קובץ האימג' של הקונטיינר.

בפלט של הפקודה, בודקים את הרשומות בקטע "Layers".

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

"Layers": [
  ...
  "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
  ...
]

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

"Layers": [
  "sha256:28699c71935fe3ffa56533db44ad93e5a30322639f7be70d5d614e06a1ae6d9b",
  ...
  "sha256:28699c71935fe3ffa56533db44ad93e5a30322639f7be70d5d614e06a1ae6d9b",
  ...
]

הפקודה mv וקריאות המערכת renameat2 נכשלות בקובצי קישור סימבולי

בצמתים של GKE שפועלים בגרסה 1.25 ואילך, כשהאפשרות Image streaming מופעלת, יכול להיות שהפקודה mv והקריאה למערכת renameat2 ייכשלו בקובצי קישור סימבולי בקובצי אימג' של קונטיינרים, ותופיע הודעת השגיאה "No such device or address". הבעיה נגרמת בגלל רגרסיה בליבות Linux עדכניות.

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

התיקון זמין בגרסאות התיקון הבאות של GKE:

  • ‫1.25: ‏ 1.25.14-gke.1351000 ואילך
  • ‫1.26: ‏1.26.9-gke.1345000 ואילך
  • ‫1.27: ‏1.27.6-gke.100 ואילך
  • ‫1.28: ‏ 1.28.1-gke.1157000 ואילך

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

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