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

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

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

סקירה כללית

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

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

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

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

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

דרישות

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

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

    הפעלת Container File System API

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

    • מערכת הפעלה שמותאמת לקונטיינרים עם containerd‏ (COS_CONTAINERD): נתמכת ב-GKE מגרסה ‎1.30.1-gke.1329000 ואילך. זוהי הגדרת ברירת המחדל לצמתי Autopilot. מידע נוסף על COS
    • ‫Ubuntu עם containerd‏ (UBUNTU_CONTAINERD): נתמך ב-GKE בגרסה ‎1.35.0-gke.1403000 ואילך. מידע נוסף על תמונות של צומתי Ubuntu
  • תמונות הקונטיינר צריכות להיות מאוחסנות במאגרים רגילים או במאגרים מרוחקים ב-Artifact Registry או במאגרים ציבוריים ב-Docker Hub.

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

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

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

מגבלות

  • תמונות של קונטיינרים שמשתמשות במניפסט תמונות V2, סכימה גרסה 1 לא עומדות בדרישות.
  • אין תמיכה בתמונות של מאגרי תגים עם שכבות כפולות. ‫GKE מוריד את התמונות האלה בלי להזרים את הנתונים. בודקים אם יש ב-container image שכבות ריקות או שכבות כפולות.
  • אם עומסי העבודה קוראים הרבה קבצים בתמונה במהלך האתחול, יכול להיות שתבחינו בזמני אתחול ארוכים יותר בגלל ההשהיה שנוספת כתוצאה מקריאת הקבצים מרחוק.
  • אם עומסי העבודה שלכם דורשים שחלק גדול מהתמונה יהיה זמין לפני שהקוד יוכל לפעול, יכול להיות שתהיה השהיה בין הזמן שבו kubelet מתחיל את הקונטיינר לבין הזמן שבו הקונטיינר מתחיל בפועל לשלוח יומנים.
  • יכול להיות שלא תבחינו ביתרונות של סטרימינג של תמונות במהלך השליפה הראשונה של תמונה שעומדת בדרישות. עם זאת, אחרי שהתמונה נשמרת במטמון של Image streaming, כל משיכה עתידית של תמונה בכל אשכול נהנית מ-Image streaming.
  • באשכולות GKE Standard, המערכת משתמשת בהגדרה ברמת האשכול כדי לקבוע אם להפעיל את Image streaming במאגרי צמתים חדשים שנוצרו באמצעות יצירה אוטומטית של מאגרי צמתים. עם זאת, אי אפשר להשתמש בהפרדה של עומסי עבודה כדי ליצור מאגרי צמתים עם הפעלת סטרימינג של תמונות, אם סטרימינג של תמונות מושבת ברמת האשכול.

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
  • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-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. בתיבת הדו-שיח עריכת סטרימינג של תמונות, מסמנים את התיבה הפעלת סטרימינג של תמונות.

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

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

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

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

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

אפשר לבדוק אם הזרמת תמונות מופעלת ברמת האשכול באמצעות ה-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. בדף אשכולות, בקטע תכונות, ליד הזרמת תמונות, יופיע מצב ההגדרה.

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

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

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

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

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

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

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, אם מפעילים או משביתים Image streaming במאגרי צמתים ספציפיים כדי שבאשכול יהיה שילוב של צמתים שמשתמשים ב-Image streaming וצמתים שלא משתמשים בו, אפשר להשתמש בבוררי צמתים בפריסות כדי לשלוט בשאלה אם GKE מתזמן את עומסי העבודה בצמתים שמשתמשים ב-Image streaming.

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

  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 מציג את הזמן שלקח להזרמת התמונה לשלוף את התמונה.
    • האירוע ImageStreaming מציין שהצומת משתמש בהזרמת תמונות כדי להציג את קובץ אימג' של קונטיינר.

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

בדוגמה האופציונלית הזו, יוצרים אשכול חדש עם השבתה של Image streaming (הזרמת תמונות) ומבצעים פריסה של frontend Deployment כדי להשוות את הביצועים עם Image streaming.

  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 שניות. כשהפעלנו את Image streaming, ‏ 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 FileSystem 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. בתיבת הדו-שיח עריכת סטרימינג של תמונות, מבטלים את הסימון בתיבת הסימון הפעלת סטרימינג של תמונות.

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

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

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

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

כדי להשבית את הזרמת התמונות כשיוצרים מאגר צמתים חדש, מציינים את הדגל --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: המיקום של מישור הבקרה של האשכול.

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

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

שמירת זיכרון לסטרימינג של תמונות

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

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

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

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

פתרון בעיות

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

‫GKE לא משתמש במערכת הקבצים של Image streaming

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

אם האירוע Image streaming לא מופיע במהלך משיכת התמונה הראשונה בצומת, צריך לוודא שאתם עומדים בדרישות של Image streaming. אם אתם עומדים בדרישות, תוכלו לאבחן את הבעיה על ידי בדיקת היומנים של שירות הסטרימינג של התמונות (שנקרא 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, התמונה לא יובאה למערכת הקבצים המרוחקת של Image streaming.

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

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

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

InvalidArgument

אם מופיעה הודעת שגיאה עם code=InvalidArgument, קובץ האימג' של הקונטיינר שבו נעשה שימוש בעומס העבודה לא עומד בדרישות לסטרימינג של תמונות. חשוב לוודא שהתמונה עומדת בדרישות. אם התמונה לא נמצאת ב-Artifact Registry, כדאי לנסות להעביר אותה ל-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

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

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

‫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 ואילך, כשהפעלתם את התכונה 'הזרמת תמונות', יכול להיות שהפקודה mv והקריאה למערכת renameat2 ייכשלו בקבצים של קישורים סמליים בקובצי אימג' של קונטיינרים, ותוצג הודעת השגיאה 'אין מכשיר או כתובת כאלה'. הבעיה נגרמת בגלל רגרסיה בליבות Linux מהזמן האחרון.

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

התיקון זמין בגרסאות הפאצ' הבאות של 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. אם אין לכם אפשרות לשנות את הקוד, אתם צריכים להשבית את הזרמת התמונות במאגר הצמתים כדי לפתור את הבעיה.

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