Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

שחזור מתמונת מצב של Pod

רגילה

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

במאמר הזה מוסבר איך להפעיל ולהגדיר תמונות מצב של GKE Pod לעומסי העבודה.

מידע נוסף על אופן הפעולה של תמונות מצב של Pod זמין במאמר מידע על תמונות מצב של Pod.

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

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

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

הפעלת 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' מופעלת. לאחר מכן, יוצרים או מעדכנים מאגר צמתים כדי להפעיל אותו ב-GKE Sandbox.

כדי להפעיל את התכונה באשכול, מבצעים את אחד מהשלבים הבאים:
- כדי להפעיל צילומי מצב של Pod באשכול חדש, מריצים את הפקודה הבאה:
```
gcloud beta container clusters create CLUSTER_NAME \
    --enable-pod-snapshots \
    --cluster-version=CLUSTER_VERSION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --workload-metadata=GKE_METADATA \
    --location=CONTROL_PLANE_LOCATION
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫CLUSTER_NAME: השם של האשכול.
  - ‫CLUSTER_VERSION: הגרסה של האשכול החדש, שצריכה להיות 1.34.1-gke.3084001 ואילך.
  - PROJECT_ID: מזהה הפרויקט.
  - ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.
- כדי להפעיל צילומי מצב של Pod באשכול קיים, מבצעים את השלבים הבאים:
  1. מעדכנים את האשכול לגרסה 1.34.1-gke.3084001 ואילך:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODEPOOL_NAME \
    --cluster-version=CLUSTER_VERSION \
    --location=CONTROL_PLANE_LOCATION
```
    מחליפים את מה שכתוב בשדות הבאים:
    - ‫CLUSTER_NAME: השם של האשכול.
    - ‫NODEPOOL_VERSION: השם של מאגר הצמתים.
    - ‫CLUSTER_VERSION: הגרסה שאליה רוצים לעדכן את האשכול החדש, שצריכה להיות 1.34.1-gke.3084001 ואילך.
    - ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.
  2. מפעילים תמונות מצב של Pod באשכול:
```
gcloud beta container clusters update CLUSTER_NAME \
   --workload-pool=PROJECT_ID .svc.id.goog \
   --enable-pod-snapshots \
   --location=CONTROL_PLANE_LOCATION
```
    מחליפים את מה שכתוב בשדות הבאים:
    - ‫PROJECT_ID במזהה הפרויקט.
    - ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.
הפעלת GKE Sandbox באשכול Standard:
```
gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --location=CONTROL_PLANE_LOCATION \
  --image-type=cos_containerd \
  --sandbox type=gvisor
```
מחליפים את המשתנים הבאים:
- ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
- ‫NODE_VERSION: הגרסה שבה ייעשה שימוש במאגר הצמתים.
- ‫MACHINE_TYPE: סוג המכונה שבה ישתמשו לצמתים.
- ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.
מידע נוסף על השימוש ב-gVisor זמין במאמר בידוד עומסי עבודה באמצעות GKE Sandbox.

תמונות מצב של חנויות

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

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

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

יצירת קטגוריה של Cloud Storage

כדי ליצור את הקטגוריה ואת ההרשאות הנדרשות, צריך לבצע את השלבים הבאים:

יצירת קטגוריה של Cloud Storage. הפקודה הבאה יוצרת קטגוריה עם ההגדרות הנדרשות:
```
gcloud storage buckets create "gs://BUCKET_NAME" \
   --uniform-bucket-level-access \
   --enable-hierarchical-namespace \
   --soft-delete-duration=0d \
   --location="LOCATION"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET_NAME: השם של הקטגוריה.
- ‫LOCATION: המיקום של הקטגוריה.
רשימת האפשרויות המלאה ליצירת קטגוריות מופיעה במאמר אפשרויות של buckets create.

מתן הרשאה לעומסי עבודה לגשת לקטגוריה של Cloud Storage

כברירת מחדל, ל-GKE אין הרשאות גישה ל-Cloud Storage. כדי לקרוא ולכתוב קבצים של תמונות מצב, צריך להעניק הרשאות IAM לחשבון השירות של Kubernetes ‏ (KSA) שמשמש את פודי העומס שלכם.

כדי לתקשר עם האשכול באמצעות פקודות kubectl, צריך לקבל אישורים:
```
gcloud container clusters get-credentials "CLUSTER_NAME"
```

לכל Pod, מבצעים את השלבים הבאים:

יוצרים KSA לכל פוד:
```
kubectl create serviceaccount "KSA_NAME" \
    --namespace "NAMESPACE"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫KSA_NAME: השם של ה-KSA.
- ‫NAMESPACE: מרחב השמות של ה-Pods.

נותנים ל-KSA הרשאה לגשת לקטגוריה:

gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
    --role="roles/storage.bucketViewer"

gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
    --role="roles/storage.objectUser"

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

‫PROJECT_NUMBER: מספר הפרויקט.
PROJECT_ID: מזהה הפרויקט.

הענקת הרשאת בקרה לגישה לקטגוריה של Cloud Storage

כדי לאפשר ל-Pod Snapshot Controller למחוק תמונות מצב בתוך קטגוריה של Cloud Storage, צריך להעניק לסוכן השירות של GKE הרשאה של משתמש באובייקט אחסון.

הקצאת התפקיד roles/storage.objectUser:

gcloud projects add-iam-policy-binding "PROJECT_ID" \
  --member="serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
  --role="roles/storage.objectUser" \
  --condition="expression=resource.name == \"projects/_/buckets/BUCKET_NAME"\",title=restrict_to_bucket,description=Restricts access to one bucket only"

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

‫PROJECT_NUMBER: מספר הפרויקט.
PROJECT_ID: מזהה הפרויקט.
‫BUCKET_NAME: השם של הקטגוריה.

(אופציונלי) יצירת תיקיות מנוהלות לקטגוריה של Cloud Storage

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

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

gcloud iam roles create podSnapshotGcsReadWriter \
    --project="PROJECT_ID" \
    --permissions="storage.objects.get,storage.objects.create,storage.objects.delete,storage.folders.create"

נותנים את התפקיד roles/storage.bucketViewer לכל ה-KSA במרחב השמות של היעד. התפקיד הזה מאפשר ל-KSA לקרוא את המטא-נתונים של הקטגוריה, אבל לא נותן הרשאות קריאה או כתיבה לאובייקטים בקטגוריה.
```
gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE" \
    --role="roles/storage.bucketViewer"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_NUMBER: מספר הפרויקט.
- PROJECT_ID: מזהה הפרויקט.
לכל KSA שצריך לאחסן תמונות מצב של Pod, מבצעים את השלבים הבאים:
1. יוצרים תיקייה מנוהלת עבור ערב הסעודית:
```
gcloud storage managed-folders create "gs://BUCKET_NAME/FOLDER_PATH/"
```
  מחליפים את FOLDER_PATH בנתיב של התיקייה המנוהלת, לדוגמה my-app-snapshots.
2. נותנים לחשבון השירות את התפקיד המותאם אישית podSnapshotGcsReadWriter בתיקייה המנוהלת:
```
gcloud storage managed-folders add-iam-policy-binding "gs://BUCKET_NAME/FOLDER_PATH/" \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
    --role="projects/PROJECT_ID/roles/podSnapshotGcsReadWriter"
```
  מחליפים את KSA_NAME בשם של KSA.
הערה: יכולות לעבור כמה דקות עד שכללי מדיניות ה-IAM יתעדכנו ב-GKE.

הגדרת אחסון לתמונות מצב

כדי לציין איפה לשמור את קובצי הצילום מהמצלמה, צריך ליצור PodSnapshotStorageConfig resource.

בדוגמה הבאה מוגדר GKE לאחסון תמונות מצב של Pod בנתיב FOLDER_PATH/ בתוך קטגוריה של Cloud Storage‏ BUCKET_NAME. שומרים את קובץ המניפסט הבא בשם example-pod-snapshot-storage-config:
```
apiVersion: podsnapshot.gke.io/v1alpha1
kind: PodSnapshotStorageConfig
metadata:
  name: example-pod-snapshot-storage-config
spec:
  snapshotStorageConfig:
    gcs:
      bucket: "BUCKET_NAME"
      path: "FOLDER_PATH"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET_NAME: שם הקטגוריה של Cloud Storage.
- ‫FOLDER_PATH: הנתיב לתיקייה המנוהלת ב-Cloud Storage.

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

kubectl apply -f example-pod-snapshot-storage-config.yaml

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

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

בדוגמה הבאה נוצרת מדיניות שחלה על Pods עם התווית app: my-app ומשתמשת בהגדרת האחסון example-pod-snapshot-storage-config. שומרים את קובץ המניפסט הבא בשם example-pod-snapshot-policy.yaml:
```
apiVersion: podsnapshot.gke.io/v1alpha1
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 ליצירת תמונות מצב לפי דרישה.

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

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

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

החל מגרסה 1.35.0-gke.2398002 של GKE, אפשר להגדיר מדיניות שמירת נתונים כדי לנקות באופן אוטומטי משאבים ישנים של תמונות מצב של Pod. במקרה הזה נעשה שימוש בשדה האופציונלי spec.retentionConfig.

החל מגרסה GKE 1.35.0-gke.3047000, אפשר לקבץ תמונות מצב של Pod באופן לוגי כדי להבדיל בין תמונות מצב שצולמו בסביבות דומות, אבל בהקשרים שונים. לדוגמה, בתרחיש של ריבוי דיירים שבו יכול להיות שכל המשתמשים משתמשים באותו Pod בסיסי, אפשר להשתמש בתכונה הזו כדי לבודד את התמונות לפי משתמש או קבוצה. כדי לבודד תמונות מצב, מציינים תוויות קיבוץ במדיניות באמצעות השדה snapshotGroupingRules.

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

כשמופעלת תמונת מצב של 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
          except OSError as e:
            return e
        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"

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

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

כדי להפעיל ידנית צילום מצב לפי דרישה של Pod ספציפי, יוצרים משאב PodSnapshotManualTrigger. הפעלת צילום תמונת מצב באופן ידני זמינה בגרסאות GKE‏ ‎1.34.1-gke.3556000 ואילך.

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

‫
```
apiVersion: podsnapshot.gke.io/v1alpha1
kind: PodSnapshotManualTrigger
metadata:
  name: example-manual-trigger
  namespace: NAMESPACE
spec:
  targetPod: my-pod
```
הערה: מדיניות יצירת התמונות שבוחרת את ה-Pod הזה צריכה להגדיר את סוג הטריגר לערך manual.

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

kubectl apply -f example-manual-trigger.yaml --namespace NAMESPACE

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

מחליפים את POD_NAME בשם ה-Pod, לדוגמה my-app או my-pod.

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

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

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

כשיוצרים תמונת מצב של Pod, נוצר משאב PodSnapshot CRD כדי לאחסן את המצב של ה-Pod באותו זמן. השדה status במשאב הזה מציין אם פעולת ה-snapshot הצליחה ואם ה-snapshot זמין לשחזורים.

כדי לראות את כל המשאבים של PodSnapshot במרחב שמות, מריצים את הפקודה הבאה:

kubectl get podsnapshots.podsnapshot.gke.io --namespace NAMESPACE

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

NAME                                   STATUS                  POLICY           AGE
de334898-1e7a-4cdb-9f2e-7cc2181c29e4   AllSnapshotsAvailable   example-policy   47h

שחזור עומס עבודה מתמונת מצב

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

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

מוחקים את ה-Pod:
```
kubectl delete -f POD_NAME.yaml
```
מחליפים את POD_NAME בשם של ה-Pod, לדוגמה my-app.
שליחת בקשה חוזרת להצטרפות לרצף:
```
kubectl apply -f POD_NAME.yaml
```
כדי לוודא שהשחזור של תמונת המצב בוצע:
```
kubectl logs my-app --namespace NAMESPACE
```
הפלט תלוי באופן שבו הגדרתם את האפליקציה. באפליקציה לדוגמה, היומנים מציגים את הערך GKE Pod Snapshot: restore כשמתבצעת פעולת שחזור.

שחזור מתמונת מצב ספציפית

כברירת מחדל, GKE משחזר עומסי עבודה מהמשאב האחרון PodSnapshot שמתאים ל-Pod. כשמבצעים צילום מצב, GKE יוצר באופן אוטומטי שם ייחודי (UUID) למשאב PodSnapshot, שאפשר לראות אותו על ידי הרצת הפקודה kubectl get podsnapshots.gke.io --namespace NAMESPACE.

כדי לשחזר עומס עבודה ממקור PodSnapshot ישן או ספציפי, מוסיפים את ההערה podsnapshot.gke.io/ps-name למפרט של Pod עומס העבודה, ומציינים את שם המקור PodSnapshot לשימוש בשחזור עומס העבודה:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
  annotations:
    podsnapshot.gke.io/ps-name: "POD_SNAPSHOT_NAME"
spec:
  serviceAccountName: KSA_NAME
  runtimeClassName: gvisor
  containers:
  ...

מחליפים את POD_SNAPSHOT_NAME בשם של תמונת המצב שרוצים לשחזר ממנה. כדי לקבל את שמות התמונות מריצים את הפקודה kubectl get podsnapshots.gke.io --namespace NAMESPACE.

כדי ש-GKE ישתמש בתמונת המצב שצוינה לשחזור, תנאי הסטטוס של המשאב PodSnapshot צריך להיות Ready והוא צריך להיות קיים באותו מרחב שמות כמו ה-Pod. אם PodSnapshot הוא לא Ready או שהוא לא קיים באותו מרחב שמות כמו ה-Pod, עומס העבודה מבצע הפעלה במצב התחלתי (cold start) במקום לשחזר מתוך תמונת מצב.

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

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

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

kubectl delete podsnapshotpolicies.podsnapshot.gke.io SNAPSHOT_POLICY --namespace=NAMESPACE

מחליפים את SNAPSHOT_POLICY בשם של PodSnapshotPolicy שרוצים למחוק, לדוגמה example-pod-snapshot-policy.

אפשר גם למחוק משאב PodSnapshot ספציפי כדי ש-Pods לא ישוחזרו יותר מהתמונה הספציפית הזו. מחיקה של משאב PodSnapshot תגרום גם להסרת הקבצים שמאוחסנים ב-Cloud Storage.

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

kubectl delete podsnapshots.podsnapshot.gke.io POD_SNAPSHOT_NAME --namespace=NAMESPACE

מחליפים את POD_SNAPSHOT_NAME בשם של התמונה של הדיסק שרוצים למחוק, לדוגמה example-podsnapshot.

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

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

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

תמונות מצב של חנויות

יצירת קטגוריה של Cloud Storage

מתן הרשאה לעומסי עבודה לגשת לקטגוריה של Cloud Storage

הענקת הרשאת בקרה לגישה לקטגוריה של Cloud Storage

(אופציונלי) יצירת תיקיות מנוהלות לקטגוריה של Cloud Storage

הגדרת אחסון לתמונות מצב

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

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

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

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

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

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

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

שחזור עומס עבודה מתמונת מצב

שחזור מתמונת מצב ספציפית

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

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

שחזור מתמונת מצב של Pod