פתרון בעיות שקשורות לתמונות מצב של 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, לא מתבצעת להם נקודת ביקורת. בודקים את תמונות הבסיס כדי לוודא שנתונים קריטיים לא מאוחסנים בכרכים מרומזים.