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

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

במסמך הזה מפורטת סקירה כללית של תמונות מצב של GKE Pod. במאמר שחזור מתמונת מצב של 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, ומסלולים לא משוחזרים.

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

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

  • ‫PodSnapshotStorageConfig: מציין את מיקום האחסון של התמונות. יש תמיכה רק בקטגוריות של Cloud Storage.
  • ‫PodSnapshotPolicy: הגדרה של קבוצות ה-Pod שייכללו בצילום התמונה, על סמך בוררי תוויות של 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 חדשה. כל הממשקים והמסלולים מוגדרים מחדש. חיבורים פעילים לרשת שהיו קיימים בזמן הצילום נסגרים בזמן השחזור. שקעי האזנה, חיבורי לולאה חוזרת וחיבורי שקע של דומיין 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: שימוש באסימון ספציפי לנתיב שנוצר על ידי חשבון השירות של הצומת.

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

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

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

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