בדף הזה מוסבר איך להשתמש בהזרמת תמונות ב-Google Kubernetes Engine (GKE) כדי לשלוף תמונות של קונטיינרים על ידי הזרמת נתוני התמונות לפי הצורך של האפליקציות.
באשכולות של Autopilot, המערכת משתמשת אוטומטית בהזרמת תמונות כדי לשלוף תמונות שעומדות בדרישות. ההוראות בדף הזה לגבי הפעלה והשבתה של סטרימינג של תמונות רלוונטיות לאשכולות רגילים.
סקירה כללית
סטרימינג של תמונות הוא שיטה לשליפת תמונות של מאגרי תמונות שבה GKE משדר נתונים מתמונות שעומדות בדרישות לפי בקשת האפליקציות שלכם. אתם יכולים להשתמש בסטרימינג של תמונות כדי לאפשר לעומסי העבודה שלכם להתחיל לפעול בלי לחכות להורדה של התמונה כולה, וכך לקצר משמעותית את זמני האתחול. קיצור זמן השליפה מספק לכם יתרונות, כולל:
- התאמה מהירה יותר לעומס (autoscaling)
- זמן האחזור קצר יותר כששולפים תמונות גדולות
- הפעלה מהירה יותר של Pod
באמצעות סטרימינג של תמונות, GKE משתמש במערכת קבצים מרוחקת כמערכת הקבצים הבסיסית לכל הקונטיינרים שמשתמשים בתמונות קונטיינרים שעומדות בדרישות. GKE מעביר בסטרימינג נתוני תמונה ממערכת הקבצים המרוחקת לפי הצורך של עומסי העבודה. בלי Image streaming, GKE מוריד את כל קובץ האימג' של הקונטיינר לכל צומת ומשתמש בו כמערכת קבצים בסיסית לעומסי העבודה.
במהלך הסטרימינג של נתוני התמונה, GKE מוריד את תמונת הקונטיינר כולה לדיסק המקומי ברקע ושומר אותה במטמון. לאחר מכן, GKE מגיש בקשות עתידיות לקריאת נתונים מהתמונה שנשמרה במטמון.
כשפורסים עומסי עבודה שצריכים לקרוא קבצים ספציפיים בתמונת המאגר, קצה העורפי של סטרימינג התמונות משרת רק את הקבצים המבוקשים.
דרישות
כדי להשתמש בסטרימינג של תמונות באשכולות GKE Autopilot ו-Standard, צריך לעמוד בדרישות הבאות:
צריך להפעיל את 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
- מערכת הפעלה שמותאמת לקונטיינרים עם containerd (
תמונות הקונטיינר צריכות להיות מאוחסנות במאגרים רגילים או במאגרים מרוחקים ב-Artifact Registry או במאגרים ציבוריים ב-Docker Hub.
אם מפעילים צמתים פרטיים באשכול, צריך להפעיל גישה פרטית ל-Google ברשת המשנה כדי שהצמתים יוכלו לגשת לשירות הזרמת התמונות.
אם תמונות הקונטיינרים שלכם מוגנות על ידי VPC Service Controls ואתם משתמשים בהזרמת תמונות, אתם צריכים לכלול בהיקף השירות גם את Image streaming API (
containerfilesystem.googleapis.com).אם הצמתים של GKE באשכול לא משתמשים בחשבון השירות שמוגדר כברירת מחדל, צריך לוודא שלחשבון השירות המותאם אישית יש את התפקיד Service Usage Consumer (
roles/serviceusage.serviceUsageConsumer) ב-IAM בפרויקט שמארח את תמונת ה-Container.
מגבלות
- תמונות של קונטיינרים שמשתמשות במניפסט תמונות 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 למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה
gcloud components updateכדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
מפעילים את Container File System API.
מוודאים שיש לכם אשכול קיים מסוג Standard. אם אתם צריכים כזה, צרו אשכול רגיל.
הפעלת סטרימינג של תמונות באשכולות
אפשר להפעיל את הזרמת התמונות באשכולות חדשים או קיימים מסוג Standard באמצעות הדגל --enable-image-streaming ב-CLI של gcloud או באמצעות מסוףGoogle Cloud . כשיוצרים אשכול עם הדגל --enable-image-streaming, הסטרימינג של התמונות מופעל במאגר הצמתים שמוגדר כברירת מחדל. גם במאגרי צמתים חדשים שתצרו, הסטרימינג של התמונות יופעל, אלא אם תשביתו אותו כשתיצרו את מאגרי הצמתים.
כל אשכולות Autopilot משתמשים בהזרמת תמונות כדי לאחזר תמונות שעומדות בדרישות. הוראות מפורטות זמינות במאמר בנושא הגדרת הגרסה וערוץ ההפצה של אשכול חדש של Autopilot. ההוראות הבאות רלוונטיות רק לאשכולות GKE Standard.
אפשר להפעיל את הזרמת התמונות באשכולות קיימים שעומדים בדרישות באמצעות gcloud CLI או מסוף Google Cloud .
gcloud
כדי לעדכן אשכול קיים לשימוש בהזרמת תמונות, מריצים את הפקודה הבאה באמצעות ה-CLI של gcloud:
gcloud container clusters update CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION \
--enable-image-streaming
מחליפים את מה שכתוב בשדות הבאים:
-
CLUSTER_NAME: השם של האשכול. -
CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .
לוחצים על השם של האשכול שרוצים לשנות.
בדף Clusters (אשכולות), בקטע Features (תכונות), לוחצים על הסמל edit לצד Image streaming (הזרמת תמונות).
בתיבת הדו-שיח עריכת סטרימינג של תמונות, מסמנים את התיבה הפעלת סטרימינג של תמונות.
לוחצים על שמירת השינויים.
אחרי שמשנים את האשכול, GKE מפעיל את התכונה 'הזרמת תמונות' באופן אוטומטי במאגרי הצמתים הקיימים כברירת מחדל. אם הפעלתם או השבתתם במפורש את הזרמת התמונות במאגרי צמתים ספציפיים, מאגרי הצמתים האלה לא יקבלו בירושה את השינויים בהגדרה ברמת האשכול.
שינוי ההגדרה של Image streaming מתבצע בהתאם לזמינות התחזוקה כשמעדכנים אותה ברמת האשכול, אבל לא ברמת מאגר הצמתים.
השינוי הזה מחייב ליצור מחדש את הצמתים, מה שעלול לשבש את עומסי העבודה הפעילים. פרטים על השינוי הספציפי הזה מופיעים בשורה המתאימה בטבלה שינויים ידניים שיוצרים מחדש את הצמתים באמצעות אסטרטגיית שדרוג צמתים בהתאם למדיניות התחזוקה. מידע נוסף על עדכוני צמתים זמין במאמר תכנון שיבושים בעדכוני צמתים.
איך מוודאים שהזרמת תמונות מופעלת באשכול
אפשר לבדוק אם הזרמת תמונות מופעלת ברמת האשכול באמצעות gcloud CLI או מסוף 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: {}
...
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .
לוחצים על שם האשכול שרוצים לבדוק.
בדף 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: המיקום של מישור הבקרה של האשכול.
שינוי ההגדרה של 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 וצמתים שלא משתמשים בו, אפשר להשתמש בnode selectors בפריסות כדי לשלוט בשאלה אם GKE מתזמן את עומסי העבודה בצמתים שמשתמשים ב-Image streaming.
בדוגמה הבאה, מתזמנים פריסה שמשתמשת בקובץ אימג' גדול של קונטיינר באשכול שמופעל בו סטרימינג של קובצי אימג'. אחר כך תוכלו להשוות את הביצועים לשליפת תמונה בלי הפעלת Image streaming.
יוצרים אשכול חדש עם הפעלת הזרמת תמונות:
gcloud container clusters create CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --enable-image-streaming \ --image-type=IMAGE_TYPEקבלת פרטי הכניסה לאשכול:
gcloud container clusters get-credentials CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATIONשומרים את קובץ המניפסט הבא בשם
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.מחילים את המניפסט על האשכול:
kubectl apply -f frontend-deployment.yamlמוודאים ש-GKE יצר את הפריסה:
kubectl get pods -l app=guestbookהפלט אמור להיראות כך:
NAMESPACE NAME READY STATUS RESTARTS AGE default frontend-64bcc69c4b-pgzgm 1/1 Completed 0 3sכדי לראות אירועים של משיכת תמונות, מקבלים את יומן האירועים של 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.
יוצרים אשכול חדש עם השבתה של סטרימינג התמונות:
gcloud container clusters create CLUSTER2_NAME \ --location=CONTROL_PLANE_LOCATION \ --image-type=IMAGE_TYPEקבלת פרטי הכניסה לאשכול:
gcloud container clusters get-credentials CLUSTER2_NAME \ --location=CONTROL_PLANE_LOCATIONפורסים את פריסת
frontendמהדוגמה הקודמת:kubectl apply -f frontend-deployment.yamlקבלת יומן האירועים של 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 קיימים באמצעות gcloud CLI אוGoogle Cloud המסוף.
gcloud
כדי להשבית את הזרמת התמונות באשכול קיים, מריצים את הפקודה הבאה:
gcloud container clusters update CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION \
--no-enable-image-streaming
מחליפים את מה שכתוב בשדות הבאים:
-
CLUSTER_NAME: השם של האשכול. -
CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .
לוחצים על השם של האשכול שרוצים לשנות.
בדף Clusters, בקטע Features, לוחצים על edit לצד Image streaming.
בתיבת הדו-שיח עריכת סטרימינג של תמונות, מבטלים את הסימון בתיבת הסימון הפעלת סטרימינג של תמונות.
לוחצים על שמירת השינויים.
שינוי ההגדרה של 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, המערכת משתמשת בהגדרות ברמת האשכול כדי לקבוע אם להפעיל 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: המיקום של מישור הבקרה של האשכול.
שינוי ההגדרה של Image streaming מתבצע בהתאם לזמינות התחזוקה כשמעדכנים אותה ברמת האשכול, אבל לא ברמת מאגר הצמתים.
השינוי הזה מחייב ליצור מחדש את הצמתים, מה שעלול לשבש את עומסי העבודה הפעילים. פרטים על השינוי הספציפי הזה מופיעים בשורה המתאימה בטבלה שינויים ידניים שיוצרים מחדש את הצמתים באמצעות אסטרטגיית שדרוג צמתים בלי להתחשב במדיניות התחזוקה. מידע נוסף על עדכוני צמתים זמין במאמר תכנון שיבושים בעדכוני צמתים.
שמירת זיכרון לסטרימינג של תמונות
GKE שומר משאבי זיכרון להזרמת תמונות בנוסף לזיכרון ששמור להרצת רכיבי מערכת של הצומת. GKE לא שומר משאבי CPU נוספים לסטרימינג של תמונות. באשכולות GKE Standard, ההזמנה הזו משנה את משאבי הזיכרון שזמינים לכם לבקשה ב-Pods. ב-GKE Autopilot, מערכת GKE מנהלת את הקצאות המערכת, כך שאין השפעה על תזמון עומסי העבודה.
פרטים על הזמנות הזיכרון ש-GKE מבצע עבור רכיבי הצומת מפורטים במאמר ארכיטקטורת אשכול רגילה.
בצמתים שמשתמשים בסטרימינג של תמונות, GKE מבצע את ההזמנות הנוספות הבאות של זיכרון להזמנות חדשות:
- לא מוקצה זיכרון נוסף למכונות עם פחות מ-1GiB של זיכרון
- 1% מ-4 ה-GiB הראשונים של הזיכרון
- 0.8% מ-4 הגיגה-בייט הבאים של הזיכרון (עד 8 גיגה-בייט)
- 0.4% מ-8 ה-GiB הבאים של הזיכרון (עד 16GiB)
- 0.24% מ-112 ה-GiB הבאים של הזיכרון (עד 128GiB)
- 0.08% מכל זיכרון מעל 128GiB
פתרון בעיות
בקטעים הבאים מפורטות עצות לפתרון בעיות בסטרימינג של תמונות. לקבלת עצות לפתרון בעיות בשליפות תמונות רגילות, אפשר לעיין במאמר בנושא פתרון בעיות בשליפות תמונות.
GKE לא משתמש במערכת הקבצים של Image streaming
אם ביומן האירועים של GKE לא מופיעים אירועים של Image streaming, התמונה לא מגובה על ידי מערכת הקבצים המרוחקת. אם GKE משך בעבר את התמונה בצומת, זהו התנהגות צפויה כי GKE משתמש במטמון המקומי של התמונה למשיכות הבאות במקום להשתמש בהזרמת תמונות.
כדי לבדוק את זה, מחפשים את Container image IMAGE_NAME already present on machine
בשדה Message של אירוע ה-Pod Pulled.
אם אירוע הסטרימינג של התמונה לא מופיע במהלך משיכת התמונה הראשונה בצומת, צריך לוודא שאתם עומדים בדרישות לסטרימינג של תמונות. אם אתם עומדים בדרישות, תוכלו לאבחן את הבעיה על ידי בדיקת היומנים של שירות הסטרימינג של התמונות (שנקרא gcfsd):
נכנסים לדף Logs Explorer במסוף Google Cloud :
בשדה Query, מציינים את השאילתה הבאה:
logName="projects/PROJECT_ID/logs/gcfsd" resource.labels.cluster_name="CLUSTER_NAME"מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: שם הפרויקט. -
CLUSTER_NAME: השם של האשכול.
-
לוחצים על Run query.
אפשר גם לבדוק את היומנים של gcfsd באמצעות Logs Explorer:
נכנסים אל Logs Explorer במסוף Google Cloud :
בשדה 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
השגיאה הזו מציינת שהפרויקט חרג מהמיכסה שנדרשת לקריאת קבצים משירות מערכת הקבצים של מאגר מרוחק. כדי לפתור את הבעיה, צריך לבקש שינוי במכסה כדי להגדיל את ערכי המכסות הבאים:
- בקשות לתוכן לכל פרויקט לכל אזור לדקה לכל אזור
- בקשות לתוכן לכל פרויקט לכל אזור
ידיות קבצים לא עדכניות אחרי הפעלה מחדש של שירות
אם שירות הזרמת התמונות (gcfsd) מופעל מחדש בצומת, יכול להיות שקונטיינרים שפועלים ומשתמשים בהזרמת תמונות ייתקלו בשגיאות קלט/פלט בדיסק, כמו stale file handle, כשהם ינסו לגשת לקבצים בתמונת הקונטיינר.
כדי לפתור את הבעיה, צריך להפעיל מחדש את ה-Pods או את הקונטיינרים המושפעים. כשמפעילים מחדש את הקונטיינרים, GKE יוצר מחדש את החיבור לשירות הזרמת התמונות. רכיבי Pod חדשים שמתוזמנים לצומת אחרי הפעלה מחדש של השירות לא מושפעים.
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. אם אין לכם אפשרות לשנות את הקוד, אתם צריכים להשבית את הזרמת התמונות במאגר הצמתים כדי לפתור את הבעיה.
המאמרים הבאים
- איך משתמשים בדיסקים משניים של אתחול כדי לטעון מראש נתונים או תמונות של מאגרי תגים
- פתרון בעיות ב-GKE
- מידע נוסף על התאמה אוטומטית לעומס (auto-scaling) באשכול GKE