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

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

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

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

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

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

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

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

איך פועלים קובצי Snapshot של Pod

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

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

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

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

קטגוריה כלול לא כלולים
מצב האפליקציה
  • זיכרון של תהליך
  • שרשורי הרצה
  • אוגרי מעבד (CPU)
  • תיאורי קבצים פתוחים
 כלום (כל מצב התהליך בזיכרון מתועד)
מערכות קבצים
  • מערכת קבצים בסיסית של קונטיינר (rootfs)
  • ‫emptyDir כרכים
  • ‫tmpfs תושבות
  • אובייקטים של PersistentVolumeClaim
  • כל סוג אחר של אמצעי אחסון או נפח אחסון שלא מופיע ברשימה
Networking
  • חיבורי לולאה חוזרת (loopback)
  • שקעים להאזנה
  • שקעי דומיין של Unix
  • חיבורים חיצוניים פעילים (נסגרים בשחזור)
  • מסלולים בהתאמה אישית
  • כללים שמוגדרים על ידי המשתמש (iptables, nftables)

משאבים בהתאמה אישית

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

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

למפרט של קובצי העזר, ראו ההסבר על PodSnapshot CustomResourceDefinition.

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

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

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

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

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

‫GKE משתמש בכללים הבאים כדי לקבוע תאימות:

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

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

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

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

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

    • metadata:
      • ‫annotations: רק הערות שרלוונטיות ל-GKE Sandbox (למשל הערות שמתחילות בקידומת 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

  • תאימות חומרה: ה-Pod המטורגט צריך לפעול בצומת עם אותה סדרת מכונות, אותו ספק מעבד ואותה קבוצת תכונות של מעבד (דגלי CPUID) כמו ה-Pod שנוצרה לו נקודת ביקורת. לדוגמה, שני הצמתים חייבים להשתמש באותה סדרה, N2 או G2, ובאותן תכונות של מעבד Intel או AMD. ‫GKE Sandbox מאמת את תכונות המעבד (CPU) לפני שחזור זיכרון התהליך ומצב המעבד, כך שלא ניתן לשחזר קובץ Snapshot עם ההיקף whole-pod בצומת עם תכונות מעבד שונות.

  • תאימות גרסאות: גרסת הליבה של GKE Sandbox וגרסת מנהל ההתקן של ה-GPU צריכות להתאים לגרסה שצולמה בתמונת המצב המקורית.

היקף הרשאות תואם אחד (rootfs-only)

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

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

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

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

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

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

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

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

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

מצב ה-GPU

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

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

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

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

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

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

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

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

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

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

דרישות

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

  • ה-Pods חייבים לפעול ב-GKE Sandbox כי קובצי ה-snapshot של ה-Pods תלויים בסביבה המבודדת ש-GKE Sandbox מספק.
  • ב-Snapshot Scope שמוגדר כברירת מחדל (whole-pod), הצומת שבו משחזרים את ה-Pod צריך להיות עם אותה סדרת מכונות, אותו ספק מעבד ואותן תכונות מעבד כמו הצומת שבו נוצר קובץ ה-Snapshot. בעומסי עבודה שכוללים רק מעבד (CPU), אפשר להשתמש בכל סדרת מכונות שאינה E2, שנתמכת על ידי GKE Sandbox ועומדת בדרישות התאימות לחומרה. מידע נוסף מופיע בקטע מגבלות.
  • כדי להשתמש במעבדים גרפיים עם קובצי Snapshot של Pod, צריך לעמוד גם בדרישות הבאות:
    • פודים עם GPU יחיד נתמכים גם בצמתים עם GPU יחיד וגם בצמתים עם כמה מעבדי GPU.
    • פודים עם כמה יחידות GPU נתמכים רק ביחידות GPU מסוג L4 (סוגי מכונות g2-standard-*).
    • בגרסאות GKE שקודמות ל-1.35.0-gke.1738000, פוד שפועל בצומת עם כמה מעבדי GPU חייב להשתמש בכל מעבדי ה-GPU שזמינים בצומת הזה. בגרסאות 1.35.0-gke.1738000 ואילך, פודים יכולים להשתמש בקבוצת משנה של יחידות ה-GPU בצומת.
    • לעומסי עבודה של GPU, צריך להשתמש באחד מסוגי המכונות הבאים של GPU:
      • 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)

מגבלות

אלה המגבלות של קובצי snapshot של Pod ב-GKE:

  • כשמשתמשים בהיקף ברירת המחדל של קובץ ה-snapshot, ‏whole-pod, אי אפשר לשחזר קובץ snapshot במכונה וירטואלית של Compute Engine עם מאפייני מעבד (דגלי CPUID) שונים מאלה של המכונה הווירטואלית שבה נוצר קובץ ה-snapshot:
    • תמונות מצב של Pod עם ההיקף whole-pod לא תומכות בסדרת המכונות E2, או בסדרות מכונות אחרות שמשלבות באופן דינמי מעבדי Intel ו-AMD או דורות של מעבדים. תמונות מצב של מערכת הקבצים (היקף rootfs-only) תומכות בסדרת המכונות E2.
    • גם באותה סדרת מכונות שאינן E2 ואצל אותו ספק מעבד, יכול להיות ש-Compute Engine יקצה מכונות וירטואליות עם פלטפורמות שונות של מעבדים או עם קבוצות שונות של תכונות מעבד לכל מכונה וירטואלית. אם Pod מתוזמן לצומת עם תכונות מעבד (CPU) לא תואמות, שחזור של קובץ snapshot עם ההיקף whole-pod ייכשל.
  • שיתוף GPU עם GPU עם כמה מופעים במקביל (MIG) אינו נתמך.
  • הקונטיינר המשני (sidecar) של מנהל התקן ה-CSI של Cloud Storage FUSE לא נתמך בתמונות מצב של Pod.
  • אי אפשר להשתמש בתמונות מצב של Pod ב-TPU.

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