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

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

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

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

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

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

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

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

הגדרות מותאמות אישית של משאבים

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

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

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

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

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

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

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

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

השדות הבאים מאובייקט ה-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

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

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

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

מצב שמשתנה אחרי השחזור

לא כל המידע נשמר כשמשחזרים את המכשיר. החלקים הבאים במצב ה-Pod משתנים כדי שה-Pod יוכל לקבל זהות חדשה:

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

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

יש מגבלות מסוימות על תמונות מצב של פודים ב-GKE:

  • ה-Pods צריכים לפעול ב-GKE Sandbox כי תמונות המצב של ה-Pods תלויות בזמן הריצה של קונטיינר gVisor ש-GKE Sandbox מספק.
  • תמונות מצב של Pod לא תומכות בסוגי מכונות E2.
  • אפשר להשתמש בתמונות מצב של Pod עם Pods של 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)
  • שימוש חלקי ב-GPU אינו אפשרי. אם לצומת יש כמה יחידות GPU, ה-Pod חייב להשתמש בכולן. לדוגמה, אי אפשר להשתמש בתמונות מצב של Pod עם ארבעה Pods שכל אחד מהם משתמש ב-GPU אחד במכונה עם ארבעה GPU.
  • אין תמיכה בשימוש בקונטיינר המשני (sidecar) של מנהל התקן ה-CSI של Cloud Storage FUSE עם תמונות מצב של Pod.

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