‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

Autopilot Standard

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

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

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

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

מפעילים את Google Kubernetes Engine API.

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.
הערה: אם ה-CLI של gcloud כבר מותקן, צריך להגדיר את המאפיין compute/region. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

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

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

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

שומרים את המניפסט הבא בתור 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.

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

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. כדי להפעיל תמונת מצב מעומס העבודה לדוגמה, פועלים לפי השלבים הבאים:

שומרים את המניפסט הבא בתור 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.

פורסים את האפליקציה:
```
kubectl apply -f my-app.yaml
```
אחרי שהאפליקציה מתחילה לפעול ומאותתת שהיא מוכנה, GKE Sandbox יוצר את קובץ ה-snapshot. כדי לוודא שה-snapshot נוצר בהצלחה, עיינו במאמר אימות קובצי snapshot.

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

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

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

שומרים את המניפסט הבא בתור 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 במרחב השמות של הפודים.

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

kubectl apply -f example-manual-trigger.yaml

כדי לוודא שה-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