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

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

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

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

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

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

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

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

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

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

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

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

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: {}
...

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

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

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

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

    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. לוחצים על שמירת השינויים.

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

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

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

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

ב-GKE גרסה ‎1.34.1-gke.1279000 ואילך, אפשר גם לשלוט בנפרד בהזרמת תמונות במאגרי צמתים שנוצרו על ידי 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 clusters, ההזמנה הזו משנה את משאבי הזיכרון שזמינים לכם לבקשה ב-Pods. ב-GKE Autopilot, מערכת GKE מנהלת את הקצאות המערכת, כך שאין השפעה על התזמון של עומסי העבודה.

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

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

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

פתרון בעיות

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

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

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

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

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

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

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

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

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

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

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

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