מידע על תמונות מצב של Pod ב-GKE

טייס אוטומטי רגילה

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

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

1. הכנה לתמונות מצב של Pod
2. הפעלת תמונת מצב של Pod
3. שחזור עומס עבודה מקובץ snapshot של Pod

מתי כדאי להשתמש בתמונות מצב של Pod

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

איך פועלות תמונות המצב של ה-Pod

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

כדי להשתמש ב-snapshots של Pod, צריך ליצור Kubernetes Custom Resource Definitions ‏ (CRD) כדי להגדיר את התנהגות ה-snapshot באופן הצהרתי. סוכן שפועל בכל צומת GKE מנהל את מחזור החיים של ה-snapshot. בהתאם למדיניות שאתם מגדירים, הסוכן קובע מתי ליצור תמונות מצב חדשות ומתי להשתמש בתמונות מצב קיימות כדי לשחזר Pods חדשים. במישור הבקרה של GKE פועל בקר שמנקה תמונות מצב שיצאו משימוש ופותר בעיות. תמונות המצב של ה-Pod מאוחסנות ב-Cloud Storage.

תוכן תמונת המצב

בטבלה הבאה מתואר מה כלול ומה לא כלול בתמונת מצב של Pod:

קטגוריה	כלול בתמונה מהירה	לא נכלל בתמונת מצב
מצב האפליקציה	כל מצב האפליקציה: כל מתארי הקבצים הפתוחים, השרשורים, רגיסטרי המעבד והזיכרון.
מערכות קבצים	מערכת הקבצים של שורש הקונטיינר (rootfs), כרכים של EmptyDir והרכבות של tmpfs.	כל מה שלא נכלל בעמודה הקודמת. ההגבלה המשמעותית ביותר היא שכרכים מתמשכים לא נשמרים בנקודת ביקורת.
Networking	חיבורי Loopback, שקעי הקשבה ושקעי Unix-Domain.	חיבורים חיצוניים לא משוחזרים (הם מסתיימים במהלך השחזור). כללים שנוספו על ידי המשתמש, כמו iptables או nftables, ומסלולים לא משוחזרים.

CustomResourceDefinitions

תמונות מצב של Pod מוגדרות באופן הצהרתי באמצעות CRD הבאים:

• ‫PodSnapshotStorageConfig: מציין את מיקום האחסון של התמונות. יש תמיכה רק בקטגוריות של Cloud Storage.
• ‫PodSnapshotPolicy: הגדרה של קבוצות ה-Pod שייווצרו להן תמונות מצב על סמך בוררי התוויות של Kubernetes. המשאב הזה מכיל את רוב אפשרויות ההגדרה של התכונה, כולל איך מפעילים את הצילומים, היקף הצילומים ומדיניות השמירה.
• ‫PodSnapshotManualTrigger: (אופציונלי) אם לא משתמשים בטריגר של עומס עבודה, מגדירים טריגר ידני ליצירת snapshot של Pod ספציפי.

טריגרים של תמונות מצב

אפשר להפעיל צילום של תמונת מצב של ה-Pod בדרכים הבאות:

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

התאמה ותאימות של תמונות מצב

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

התאימות נקבעת לפי הכללים הבאים:

• סדר הבחירה: כברירת מחדל, GKE משחזר עומסי עבודה מהמשאב PodSnapshot העדכני ביותר שתואם למרחב השמות ולתצורה של ה-Pod.
• קריטריוני התאמה: בדיקת התאימות משתנה בהתאם להיקף של התמונה המיידית שהוגדר ב-PodSnapshotPolicy (whole-pod לעומת rootfs-only).

whole-pod התאמה להיקף (ברירת מחדל)

בכללי מדיניות עם היקף ברירת המחדל whole-pod, מערכת GKE בודקת את הדברים הבאים:

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

   השדות הבאים מאובייקט ה-Pod הם חלק מהמפרט המזוקק ומשפיעים על הגיבוב הייחודי:

   • metadata:
     • ‫annotations: רק הערות שרלוונטיות לסביבת זמן הריצה של gVisor (למשל הערות שמתחילות בקידומת dev.gvisor.*).
     • labels: batch.kubernetes.io/job-completion-index
   • spec:
     • volumes: name, volumeSource, hostPath, persistentVolumeClaim, configMap
     • containers:
       • name
       • image
       • command
       • args
       • workingDir
       • ports: name, containerPort, protocol
       • ‫volumeMounts: name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation, subPathExpr
       • volumeDevices: name
       • lifecycle: postStart, preStop
       • terminationMessagePath
       • terminationMessagePolicy
       • securityContext (וכל שדות המשנה)
       • stdin
       • stdinOnce
       • tty
     • ‫initContainers: אותם שדות משנה כמו containers.
     • dnsPolicy
     • automountServiceAccountToken
     • hostNetwork
     • hostPID
     • hostIPC
     • shareProcessNamespace
     • securityContext
     • dnsConfig
     • runtimeClassName
     • os
     • hostUsers

2. תאימות חומרה: ה-Pod של היעד צריך לפעול בצומת עם סדרת מכונות וארכיטקטורת CPU זהות לאלה של ה-Pod המקורי עם נקודת הבדיקה (לדוגמה, N2 ל-N2 או G2 ל-G2).

3. תאימות גרסאות: גרסת הליבה של gVisor וגרסת מנהל ההתקן של GPU צריכות להיות זהות לגרסה שצולמה בתמונת המצב המקורית.

rootfs-only התאמה של היקפי הרשאות

כשמגדירים את המדיניות עם היקף rootfs-only (זמין בגרסה ‎1.35.3-gke.1031000 ואילך של GKE), הדרישות התואמות פחות מחמירות:

• ‫GKE לא מחשב או משווה את הגיבוב של מפרט ה-Pod המזוקק. ההתאמה הגמישה הזו מאפשרת לשחזר תמונת מצב ל-Pod יעד שיש בו משאבים, סביבות או שדות הגדרה שונים מאלה של ה-Pod המקורי עם נקודת הבדיקה, בתנאי שתמונת הקונטיינר הבסיסית וגרסאות הצומת תואמות.
• מכיוון שזיכרון התהליך לא משוחזר, אפשר לשחזר תמונות מצב שצולמו במשפחת מכונות אחת למשפחת מכונות אחרת (כולל סוגי מכונות E2).

התאמה של כללי קיבוץ

אם המדיניות משתמשת בשדה snapshotGroupingRules כדי לקבץ תמונות מצב לפי ערכי תוויות ספציפיים (לדוגמה, לפי דייר או סביבה), ל-Pod המשוחזר צריכים להיות בדיוק אותם מפתחות וערכים של תוויות. הכלי Pod snapshot controller בוחר רק קובץ snapshot מהקבוצה התואמת. מידע נוסף על הגדרת תוויות לקיבוץ מופיע במאמר הגדרת מדיניות נוספת של תמונת מצב של Pod.

שחזור המוכנות והטעינה ברקע

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

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

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

ההתנהגות הזו של טעינה ברקע רלוונטית גם למצב של ה-GPU. לדוגמה, יכול להיות ש-Pod של מודל שפה גדול (LLM) יופיע במצב Running ויגיב לבדיקות רשת, גם אם זיכרון ה-GPU שלו עדיין מתמלא. המודל לא יגיב באופן מלא להסקת מסקנות עד שמצב ה-GPU ישוחזר באופן מלא. בגלל העיכוב הזה, כשמודדים את מהירות השחזור, חשוב לוודא שמתעדים את הרגע שבו שרת המודל מתחיל לפעול. אפשר לבדוק מתי שרת המודל מתחיל לפעול באמצעות מדדים כמו Time-to-First-Token (TTFT) או Pod readiness probes.

מצב ה-GPU

תמונות מצב של Pod תומכות בצילום המצב של מעבדי GPU. כשמפעילים צילום תמונת מצב של Pod שמשתמש ב-GPU, הכלי cuda-checkpoint של NVIDIA שומר את מצב ה-GPU בזיכרון התהליך. המשמעות היא שכל הנתונים שמאוחסנים ב-GPU, למשל משקלי המודל, נכללים בתמונת המצב. ה-Pod מושהה ומצולם. במהלך השחזור, התהליך מתהפך.

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

שיקולים לגבי Pods משוחזרים

מנקודת המבט של Kubernetes API, נוצר Pod חדש. כשה-Pod מתחיל, אם יש תמונת מצב תואמת ל-Pod, ה-Pod משוחזר מתמונת המצב הזו, כולל הזיכרון המקורי ומצב התהליך. עם זאת, כדי שה-Pod יפעל כמו מופע חדש וייחודי, צריך לשנות כמה היבטים במצב שלו.

אחרי שחזור, יכולים להיות שינויים במצבים הבאים:

• ממשקי רשת: ה-Pod המשוחזר מקבל כתובת IP חדשה. כל הממשקים והנתיבים מוגדרים מחדש. חיבורים פעילים לרשת שהיו קיימים בזמן יצירת התמונה יסגרו במהלך השחזור. שקעי האזנה, חיבורי לולאה חוזרת וחיבורי שקע של דומיין Unix ממשיכים לפעול.
• שם מארח: ה-Pod המשוחזר מקבל זהות חדשה ושם מארח חדש.
• שעת הקיר: שעת הקיר קופצת קדימה לשעה הנוכחית.
• מצב האפליקציה: מצב האפליקציה צריך להיות ייחודי לכל Pod, כמו מזהי ניסויים או ערכי התחלה של מספרים אקראיים, והוא צריך להיות מאותחל מחדש אחרי שחזור.
• סודות: מפתחות הצפנה ואישורים שנוצרו לפני צילום התמונה צריכים להיווצר מחדש.
• משתני סביבה: אפשר לשנות משתני סביבה בין תמונת מצב לבין שחזור. עם זאת, בגלל שמשתני הסביבה מאוחסנים בזיכרון של האפליקציה, GKE Sandbox לא יכול למצוא ולהחליף אותם בצורה מהימנה. אם עומס העבודה מסתמך על משתני סביבה חדשים אחרי שחזור, צריך לרענן אותם באופן ידני ב-Pod. משתני הסביבה החדשים זמינים בקובץ /proc/gvisor/spec_environ. פורמט הקובץ זהה לפורמט של /proc/<pid>/environ.

ריבוי דיירים וזהות

תמונות מצב של Pod דורשות קשרי IAM ידניים לכל חשבון שירות (KSA) של Kubernetes של Pod כדי לגשת ל-Cloud Storage. יכול להיות שיעבור זמן עד שהרשאות IAM שמוגדרות באופן ידני יתעדכנו, וזה עלול להיות בעייתי אם אתם צריכים ליצור תמונות מצב מיד אחרי שיוצרים Pod.

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

• ‫podKSA (ברירת מחדל): קישור ידני של KSA של ה-Pod לקטגוריה של Cloud Storage.
• ‫federatedP4SA: שימוש באסימון ספציפי לנתיב שנוצר על ידי חשבון השירות של הצומת.

מגבלות ודרישות

יש מגבלות על תמונות מצב של Pod ב-GKE:

• ה-Pods צריכים לפעול ב-GKE Sandbox כי תמונות המצב של ה-Pods תלויות בזמן הריצה של קונטיינר gVisor ש-GKE Sandbox מספק.
• תמונות מצב של Pod לא תומכות בסוגי מכונות E2 כשמשתמשים בהיקף ברירת המחדל של תמונת המצב whole-pod. תמונות מצב של מערכת קבצים (rootfs-only) תומכות בסוגי מכונות E2.
• הדרישות והמגבלות הבאות חלות על תמיכה ב-GPU לצילומי מצב של Pod:
  • יש תמיכה ב-Pods עם GPU יחיד גם בצמתים עם GPU יחיד וגם בצמתים עם כמה GPU.
  • תמיכה ב-Pods עם כמה מעבדי GPU קיימת רק במעבדי L4 GPU (סוגי מכונות g2-standard-*).
  • שיתוף GPU עם Multi-Instance GPU ‏ (MIG) לא אפשרי.
  • בגרסאות GKE‏ 1.35.0-gke.1738000 ומגרסאות קודמות, פוד שפועל בצומת עם כמה יחידות GPU חייב להשתמש בכל יחידות ה-GPU שזמינות בצומת הזה. בגרסאות 1.35.0-gke.1738000 ואילך, אפשר להשתמש ב-Pods רק בחלק מה-GPU בצומת.
  • תמונות מצב של Pod תומכות בסוגי המכונות הבאים:
    • g2-standard-4 (1 x L4)
    • g2-standard-8 (1 x L4)
    • g2-standard-12 (1 x L4)
    • g2-standard-16 (1 x L4)
    • g2-standard-32 (1 x L4)
    • ‫g2-standard-48 (4 x L4)
    • ‫g2-standard-96 (8 x L4)
    • ‫a2-highgpu-1g (1 x A100-40GB)
    • ‫a2-ultragpu-1g (1 x A100-80GB)
    • ‫a3-highgpu-1g (1 x H100-80GB)
• אין תמיכה בקונטיינר ה-sidecar של מנהל התקן ה-CSI של Cloud Storage FUSE בצילומי מצב של Pod.
• תמונות מצב של Pod לא תומכות בסוגי מכונות TPU.

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

• איך מתכוננים לתמונות מצב של פודים