הפעלת תמונת מצב של Pod

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

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

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

• מפעילים את Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.

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

יצירת מדיניות של תמונות מצב

כדי להפעיל קובצי snapshot של Pod, יוצרים משאב בהתאמה אישית מסוג PodSnapshotPolicy עם בורר שתואם לתוויות של ה-Pod:

1. שומרים את המניפסט הבא בתור example-pod-snapshot-policy.yaml. בדוגמה הזו נוצרת מדיניות שחלה על Pods עם התווית app: my-app. המדיניות משתמשת במשאב המותאם אישית example-pod-snapshot-storage-config PodSnapshotStorageConfig, שיצרתם בקטע הכנה לתמונות מצב של Pod, כדי להגדיר את מיקום האחסון של תמונת המצב:

   apiVersion: podsnapshot.gke.io/v1
   kind: PodSnapshotPolicy
   metadata:
     name: example-pod-snapshot-policy
     namespace: NAMESPACE
   spec:
     storageConfigName: example-pod-snapshot-storage-config
     selector:
       matchLabels:
         app: my-app
     triggerConfig:
       type: TRIGGER_TYPE
       postCheckpoint: resume
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫NAMESPACE: מרחב השמות של ה-Pods. משתמשים באותו מרחב שמות שנתתם לו גישה ל-Cloud Storage בקטע הכנה לתמונות מצב של Pod.
   • ‫TRIGGER_TYPE: סוג הטריגר. הערכים הנתמכים הם workload לטריגרים שמבוססים על עומס עבודה או manual לתמונות מצב על פי דרישה.

   בדוגמה הזו, ההגדרה postCheckpoint: resume משאירה את ה-Pod פועל אחרי ש-GKE יוצר את קובץ ה-snapshot.

   לרשימה המלאה של השדות שאפשר להגדיר, ראו המפרט של PodSnapshotPolicy.

2. מחילים את המניפסט:

   kubectl apply -f example-pod-snapshot-policy.yaml
   

הגדרת הגדרות מדיניות נוספות של תמונת מצב של Pod

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

• היקף קובץ ה-snapshot: כדי לציין אילו חלקים של מצב ה-Pod יתועדו בקובץ ה-snapshot, מגדירים את השדה spec.snapshotScope. הערכים הנתמכים הם whole-pod (ברירת מחדל) ו-rootfs-only. ההיקף whole-pod כולל את כל ה-Pod, כולל מצב האפליקציה, הזיכרון ומערכות הקבצים. ההיקף rootfs-only כולל רק את מערכת הקבצים ברמה הבסיסית (root) של הקונטיינר. כדי להשתמש בהיקף ההרשאות rootfs-only, צריך להתקין את GKE בגרסה 1.35.3-gke.1031000 ואילך.

• ניקוי אוטומטי: כדי לנקות באופן אוטומטי משאבים ישנים בהתאמה אישית של PodSnapshot, מגדירים מדיניות שמירת נתונים באמצעות השדה spec.retentionConfig. אפשר לציין משך זמן באמצעות השדה lastAccessTimeout, לדוגמה 7d. אחרי שפרק הזמן הזה חולף, GKE מוחק את קובץ ה-snapshot.

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

אפשר להגדיר בנפרד את ההגדרות של היקף, שמירה וקיבוץ של קובצי snapshot. בדוגמה הבאה מוצגות כל שלוש ההגדרות במשאב בהתאמה אישית של PodSnapshotPolicy:

# Multiple lines are omitted here
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

לרשימה המלאה של השדות שאפשר להגדיר, ראו המפרט של PodSnapshotPolicy.

אופטימיזציה של גודל תמונת המצב

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

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

• מצב האפליקציה, כמו זיכרון ורגיסטרים
• שינויים במערכת הקבצים הבסיסית ובנקודות הטעינה של tmpfs (כולל אמצעי אחסון של emptyDir)
• מצב הליבה, כמו תיאורי קבצים פתוחים, שרשורים ושקעים

אופטימיזציה של גודל קובץ ה-snapshot חשובה במיוחד לעומסי עבודה כמו מודלים גדולים של שפה (LLM). שרתי LLM בדרך כלל מורידים את משקלי המודל לאחסון מקומי (rootfs או tmpfs) לפני שהם טוענים אותם ל-GPU. כשיוצרים קובץ Snapshot, ‏GKE Sandbox שומר גם את מצב ה-GPU וגם את קובצי משקל המודל. בתרחיש הזה, אם המודל הוא בנפח 100GB, תמונת המצב שנוצרת היא בנפח של כ-200GB (קבצי מודל בנפח 100GB, ו-100GB שמייצגים את מצב ה-GPU). אחרי שהאפליקציה טוענת את משקלי המודל ל-GPU, בדרך כלל היא לא צריכה את הקבצים במערכת הקבצים כדי לפעול. אם תמחקו את קובצי המודל האלה לפני שתפעילו את קובץ ה-snapshot, תוכלו להקטין את גודל קובץ ה-snapshot בחצי ולשחזר את האפליקציה עם זמן אחזור קצר משמעותית.

הפעלת תמונת מצב

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

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

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

הפעלת קובץ snapshot מעומס עבודה

כדי להפעיל קובץ snapshot מתוך קוד האפליקציה, צריך להגדיר את האפליקציה כך שתשלח אות כשהיא מוכנה לקובץ snapshot. כדי לאותת על מוכנות, כותבים את הערך 1 בקובץ /proc/gvisor/checkpoint – לדוגמה, על ידי הפעלת הפקודה echo 1 > /proc/gvisor/checkpoint. פעולת הכתיבה מתחילה את תהליך יצירת קובץ ה-snapshot באופן אסינכרוני וחוזרת מיד. קריאה מאותו תיאור קובץ חוסמת את תהליך הקריאה עד להשלמת פעולת השחזור או יצירת קובץ ה-snapshot, ועד שעומס העבודה מוכן להמשך.

לפני שאתם מפעילים קובץ snapshot מעומס עבודה, ודאו שמדיניות ה-snapshot בוחרת את ה-Pod. הערך של השדה triggerConfig.type במדיניות הזו צריך להיות workload.

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

1. שומרים את המניפסט הבא בתור my-app.yaml. בדוגמה הזו, התווית app: my-app תואמת לבורר במדיניות לדוגמה של תמונת המצב, וההגדרה runtimeClassName: gvisor מריצה את ה-Pod ב-GKE Sandbox:

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
     namespace: NAMESPACE
     labels:
       app: my-app
   spec:
     serviceAccountName: SERVICEACCOUNT_NAME
     runtimeClassName: gvisor
     containers:
     - name: my-container
       image: python:3.10-slim
       command: ["python3", "-c"]
       args:
         - |
           import time
           def trigger_snapshot():
             try:
               with open("/proc/gvisor/checkpoint", "r+") as f:
                 f.write("1")
                 res = f.read().rstrip()
                 print(f"GKE Pod Snapshot: {res}")
             except FileNotFoundError:
               print("GKE Pod Snapshot file does not exist -- "
                     "Pod Snapshots is disabled")
               return
           i = 0
           while True:
             print(f"Count: {i}", flush=True)
             if (i == 20): # Simulate readiness at the 20th count
               trigger_snapshot()
             i += 1
             time.sleep(1)
       resources:
         limits:
           cpu: "500m"
           memory: "512Mi"
         requests:
           cpu: "250m"
           memory: "256Mi"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫NAMESPACE: מרחב השמות של ה-Pods.
   • ‫SERVICEACCOUNT_NAME: השם של אובייקט ServiceAccount שנתתם לו גישה ל-Cloud Storage בקטע הכנה לתמונות מצב של Pod.

2. פורסים את האפליקציה:

   kubectl apply -f my-app.yaml
   

   אחרי שהאפליקציה מתחילה לפעול ומאותתת שהיא מוכנה, GKE Sandbox יוצר את קובץ ה-snapshot. כדי לוודא שה-snapshot נוצר בהצלחה, עיינו במאמר אימות קובצי snapshot.

הפעלה ידנית של תמונת מצב

לפני שמפעילים ידנית קובץ snapshot, צריך לוודא שה-Pod המטורגט פועל ושהוא נבחר על ידי מדיניות ה-snapshot. הערך של השדה triggerConfig.type במדיניות הזו צריך להיות manual.

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

1. שומרים את המניפסט הבא בתור example-manual-trigger.yaml. בדוגמה הזו מופעלת תמונת מצב של Pod בשם my-pod:

   apiVersion: podsnapshot.gke.io/v1
   kind: PodSnapshotManualTrigger
   metadata:
     name: example-manual-trigger
     namespace: NAMESPACE
   spec:
     targetPod: my-pod
   

   מחליפים את NAMESPACE במרחב השמות של הפודים.

2. מחילים את המניפסט:

   kubectl apply -f example-manual-trigger.yaml
   

3. כדי לוודא שה-snapshot הופעל בהצלחה, בודקים את הקטע status במשאב המותאם אישית PodSnapshotManualTrigger:

   kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io \
       example-manual-trigger \
       --namespace NAMESPACE -o yaml
   

   מחליפים את NAMESPACE במרחב השמות של הפודים.

   אם הטריגר הצליח, בשדה status.conditions יופיע שהבדיקה הושלמה ובשדה status.snapshotCreated יופיע השם של המשאב המותאם אישית PodSnapshot שנוצר.

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

כדי לוודא ש-GKE יצר קובץ Snapshot, בודקים את היסטוריית האירועים של אירועי GKEPodSnapshotting:

kubectl get events \
    -o custom-columns=NAME:involvedObject.name,CREATIONTIME:.metadata.creationTimestamp,REASON:.reason,MESSAGE:.message \
    --namespace NAMESPACE \
    --field-selector involvedObject.name=POD_NAME,reason=GKEPodSnapshotting

מחליפים את מה שכתוב בשדות הבאים:

• ‫NAMESPACE: מרחב השמות של ה-Pods.
• ‫POD_NAME: שם ה-Pod.

הפלט אמור להיראות כך:

NAME                                    CREATIONTIME           REASON               MESSAGE
default/5b449f9c7c-bd7pc                2025-11-05T16:25:11Z   GKEPodSnapshotting   Successfully checkpointed the pod to PodSnapshot

בעמודה MESSAGE מופיע הערך Successfully checkpointed the pod to PodSnapshot, שמאשר ש-GKE שמר את מצב ה-Pod במשאב מותאם אישית מסוג PodSnapshot. כדי לראות ולנהל את המשאבים המותאמים אישית של PodSnapshot, קראו את המאמר ניהול קובצי snapshot.

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

• שחזור עומס עבודה מתמונת מצב של Pod
• פתרון בעיות בתמונות מצב של Pod