פתרון בעיות שקשורות לתמונות מצב של Pod

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

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

סיכוני מוטציה אחרי נקודת ביקורת עם PVC

אם ה-Pod משתמש ב-Persistent Volume Claim‏ (PVC), יש סיכון משמעותי במהלך תהליך העבודה של "נקודת בדיקה והמשך": אם מגדירים עומס עבודה להמשך מיד אחרי נקודת בדיקה (באמצעות השדה postCheckpoint: resume), האפליקציה נשארת פעילה ויכולה לשנות את ה-PVC אחרי נקודת הבדיקה.

  • בעיה בהפסקת פעולה מסודרת: אחרי מחזור של נקודת ביקורת והמשך, כשמוחקים Pod, ‏ Kubernetes מתחיל רצף של הפסקת פעולה מסודרת על ידי שליחת אות SIGTERM לתהליך הראשי במאגר. באפליקציות רבות מיושמת לוגיקה של כיבוי מבוקר, שבמהלכו הן עשויות להפעיל שגרות ניקוי כדי למחוק או לעדכן קבצים זמניים ב-PVC.
  • שחזור נכשל: אם השינויים האלה מתרחשים ב-PVC אחרי שנוצרת תמונת המצב של ה-Pod, תהליך השחזור יצפה למצב ה-PVC כפי שהיה ברגע המדויק של נקודת הבדיקה, מה שעלול להוביל לכשלים בשחזור או לחוסר עקביות בנתונים.
  • המלצה לצמצום הסיכון: אם השימוש ב-PVC נחוץ לעומס העבודה, אל תפעילו מחדש את עומס העבודה אחרי נקודת ביקורת. משתמשים בהגדרה postCheckpoint: stop ב-PodSnapshotPolicy. ההגדרה הזו עוזרת לוודא שלתהליך לא תהיה אפשרות לבצע כתיבות משניות או שינויים במצב אחרי השלמת שלב יצירת נקודת הבדיקה.

התקנות של ConfigMap והסתרת ספריות

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

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

בדוגמה הבאה, שינויים בספרייה /etc/my-app/ לא נכללים בתמונת המצב כי כל הספרייה היא נקודת הרכבה חיצונית:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config.json: |
    {
      "mode": "local"
    }
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: gvisor
  containers:
    - name: my-app-container
      image: my-app-image
      volumeMounts:
        - mountPath: /etc/my-app
          name: config-volume
  volumes:
    - name: config-volume
      configMap:
        name: my-config

כדי לפתור את הבעיה, צריך להשתמש בsubPath. השדה subPath עוזר לוודא שרק קובץ התצורה הספציפי מטופל כטעינה חיצונית. התצורה הזו מכוונת לקובץ המדויק, וכך שאר הקבצים והמבנה בספריית האם נשארים חלק ממערכת הקבצים המקומית של הקונטיינר, שתועדה בצורה נכונה במהלך תהליך יצירת נקודת הבדיקה.

בדוגמה הבאה מוצגת ההגדרה של volumeMounts שמשתמשת ב-subPath:

      volumeMounts:
        - mountPath: /etc/my-app/config.json
          name: config-volume
          subPath: config.json

נפחים משתמעים אנונימיים

חלק מקובצי האימג' של קונטיינרים מגדירים נפחים במטא נתונים שלהם באמצעות ההוראה VOLUME ב-Dockerfile. גם אם מפרט ה-Pod לא מגדיר נפח אחסון, Kubernetes יוצר באופן אוטומטי נפח אחסון אנונימי לכל נתיב שמוגדר כנפח אחסון בתמונת הבסיס. לדוגמה, התמונה alpine/git מגדירה את /git כנפח משתמע.

הנפחים האנונימיים האלה נחשבים כנפחים חיצוניים, וכמו PVC, לא מתבצעת בהם נקודת ביקורת. חשוב לבדוק את קובצי האימג' הבסיסיים כדי לוודא שנתונים קריטיים לא מאוחסנים בנפחים משתמעים.