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

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

טייס אוטומטי רגילה

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

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

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

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

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-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.

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

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

בדוגמה הבאה נוצרת מדיניות שחלה על Pods עם התווית app: my-app ומשתמשת בהגדרת האחסון example-pod-snapshot-storage-config. שומרים את קובץ המניפסט הבא בשם example-pod-snapshot-policy.yaml:
```
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
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TRIGGER_TYPE: סוג הטריגר. הערכים הנתמכים הם workload להפעלת גיבויים על סמך עומס העבודה או manual ליצירת תמונות מצב לפי דרישה.
- ‫NAMESPACE: מרחב השמות של ה-Pods.
רשימה מלאה של כל השדות שאפשר להגדיר מופיעה במסמכי התיעוד של PodSnapshotPolicy CustomResourceDefinition (CRD).

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

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

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

אפשר להגדיר מדיניות נוספת ב-PodSnapshotPolicy, למשל:

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

בדוגמה הבאה מוצגות ההגדרות של שמירת הנתונים ושל הקיבוץ ב-PodSnapshotPolicy. אפשר להגדיר את ההגדרות האלה בנפרד:

# ... other fields omitted
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

רשימה מלאה של כל השדות שאפשר להגדיר מופיעה במסמכי העזר בנושא PodSnapshotPolicy.

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

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

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

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

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

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

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

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

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

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

שומרים את קובץ המניפסט הבא בשם my-app.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
spec:
  serviceAccountName: KSA_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 the application being ready to snapshot at 20th count
            trigger_snapshot()
          i += 1
          time.sleep(1)
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "250m"
        memory: "256Mi"

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

‫NAMESPACE: מרחב השמות של ה-Pods.
‫KSA_NAME: השם של ה-KSA.

מפעילים את האפליקציה:
```
kubectl apply -f my-app.yaml
```

הפעלת צילום תמונת מצב באופן ידני

כדי להפעיל ידנית תמונת מצב לפי דרישה של Pod ספציפי, צריך ליצור משאב PodSnapshotManualTrigger.

בדוגמה הבאה מופעלת תמונת מצב עבור Pod בשם my-pod. שומרים את קובץ המניפסט הבא בשם example-manual-trigger.yaml:
```
apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotManualTrigger
metadata:
  name: example-manual-trigger
  namespace: NAMESPACE
spec:
  targetPod: my-pod
```
מחליפים את NAMESPACE במרחב השמות של ה-Pod.

הערה: מדיניות התמונות שבוחרת את ה-Pod הזה צריכה להגדיר את סוג הטריגר לערך manual.

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

kubectl apply -f example-manual-trigger.yaml

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

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

השדה status מציין אם הפעלת הצילום של התמונה המייצגת הצליחה או נכשלה.

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

כדי לוודא שנוצר 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