בדף הזה מוסבר איך להשתמש בהזרמת תמונות ב-Google Kubernetes Engine (GKE) כדי לשלוף תמונות של קונטיינרים על ידי הזרמת נתוני התמונות לפי הצורך של האפליקציות.
במצב אוטומטי, אשכולות משתמשים אוטומטית בהזרמת תמונות כדי לשלוף תמונות שעומדות בדרישות. ההוראות בדף הזה לגבי הפעלה והשבתה של סטרימינג של תמונות רלוונטיות לאשכולות רגילים.
סקירה כללית
הזרמת תמונות היא שיטה לשליפת תמונות של מאגרי תמונות שבה 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 בפרויקט שמארח את קובץ אימג' של קונטיינר.
מגבלות
- תמונות של קונטיינרים שמשתמשות במניפסט תמונות 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 לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
מפעילים את Container File System API.
מוודאים שיש לכם אשכול קיים מסוג 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: המיקום של מישור הבקרה של האשכול.
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .
לוחצים על השם של האשכול שרוצים לשנות.
בדף Clusters, בקטע Features, לוחצים על edit לצד Image streaming.
בתיבת הדו-שיח עריכת סטרימינג של תמונות, מסמנים את התיבה הפעלת סטרימינג של תמונות.
לוחצים על שמירת השינויים.
אחרי שמשנים את האשכול, 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: {}
...
המסוף
נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .
לוחצים על שם האשכול שרוצים לבדוק.
בדף אשכולות, בקטע תכונות, ליד הזרמת תמונות, יופיע מצב ההגדרה.
הפעלת סטרימינג של תמונות במאגרי צמתים
כברירת מחדל, מאגרי הצמתים מקבלים בירושה את הגדרת הסטרימינג של התמונות ברמת האשכול. אפשר להפעיל או להשבית את הזרמת התמונות במאגרי צמתים ספציפיים באמצעות ה-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.
יוצרים אשכול חדש עם הפעלת הזרמת תמונות:
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 קיימים באמצעות ה-CLI של gcloud או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, המערכת משתמשת בהגדרה ברמת האשכול כדי לקבוע אם להפעיל סטרימינג של תמונות במאגרי צמתים חדשים שנוצרו באמצעות יצירה אוטומטית של מאגרי צמתים.
בגרסה 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):
נכנסים לדף 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
השגיאה הזו מציינת שהפרויקט חרג מהמכסה הנדרשת לקריאת קבצים משירות מערכת הקבצים של מאגר מרוחק. כדי לפתור את הבעיה, צריך לבקש שינוי במכסה כדי להגדיל את ערכי המכסות הבאים:
- בקשות לתוכן לכל פרויקט לכל אזור לדקה לכל אזור
- בקשות לתוכן לכל פרויקט לכל אזור
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. אם אין לכם אפשרות לשנות את הקוד, אתם צריכים להשבית את הזרמת התמונות במאגר הצמתים כדי לפתור את הבעיה.
המאמרים הבאים
- איך משתמשים בדיסקים משניים של אתחול כדי לטעון מראש נתונים או תמונות של מאגרי תגים
- פתרון בעיות ב-GKE
- מידע נוסף על התאמה אוטומטית לעומס (auto-scaling) באשכול GKE