הגדרת גיבוי Kubernetes וביקורת עם Kasten K10

תארו לעצמכם: קלאסטר Kubernetes בייצור קורס, ואתם מאבדים נתוני PostgreSQL קריטיים — גיבויים קיימים, אבל השחזור אורך שעות ואתם לא בטוחים לגבי העקביות. Kasten K10 פותר את זה עם צילומי מצב עקביים ליישום ומדיניות אוטומטית. אנו משלבים את K10 בתשתית שלכם לגיבוי, שחזור והעברה ארגוניים. זה לא רק חלופה ל-Velero — זו פלטפורמת ניהול נתונים מלאה עם ממשק משתמש, מנוע מדיניות ותמיכה מובנית במסדי נתונים. K10 מאיץ את השחזור פי 2 באמצעות אוטומציה, וחיסכון בעלויות השבתה מגיע ל-40% בהשוואה לסקריפטים ידניים.

הוא מותקן בקלאסטר כ-Helm release, תופס namespace ייעודי kasten-io, ומנוהל דרך ממשק אינטרנט או דרך משאבי Kubernetes (Policy, BackupAction, RestoreAction).

היכן K10 מנצח את Velero

K10 מספק צילומי מצב עקביים ליישום מחוץ לקופסה עבור PostgreSQL, MySQL, MongoDB באמצעות Blueprint — הוקים מותאמים אישית ש-K10 מריץ לפני צילום המצב. Velero תומך גם בהוקים לפני/אחרי, אבל Blueprint ב-K10 הם משאבי CRD לשימוש חוזר, לא הערות inline על כל פוד. Blueprints מקצרים את זמן הגדרת גיבוי מסדי הנתונים פי 5 בהשוואה לכתיבת הוקים לפני/אחרי ידנית ב-Velero.

דוגמה ל-Blueprint עבור flush של PostgreSQL:

---
apiVersion: cr.kanister.io/v1alpha1
kind: Blueprint
metadata:
  name: postgres-hooks
  namespace: kasten-io
actions:
  backupPrehook:
    phases:
      - func: KubeExec
        name: pgFlush
        args:
          namespace: "{{ .Deployment.Namespace }}"
          pod: "{{ index .Deployment.Pods 0 }}"
          containers: ["postgres"]
          command: ["psql", "-U", "postgres", "-c", "CHECKPOINT;"]
---

K10 מזהה את ה-Blueprint לפי label על ה-Deployment — אין צורך בהערות podSpec.

הנקודה החלשה של K10 היא צריכת משאבים. בקלאסטר עם 50+ namespaces, הקטלוג ושרת ה-API של K10 צורכים יותר משמעותית מ-Velero. בקלאסטרים מנוהלים עם control planes מוגבלים, זה יכול להיות בעייתי. החיסרון השני הוא רישוי: K10 חינמי עד 10 צמתים, ואז בתשלום. זה משנה את הכלכלה של הפתרון.

בעיות התקנה אופייניות

טעות ההתחלה הנפוצה ביותר היא התקנת K10 מבלי לבדוק תחילה שה-StorageClass תומך ב-VolumeSnapshot. K10, כמו Velero, תלוי ב-CSI snapshot API. apiVersion: cr.kanister.io/v1alpha1 kind: Blueprint metadata: name: postgres-hooks namespace: kasten-io actions: backupPrehook: phases: - func: KubeExec name: pgFlush args: namespace: "{{ .Deployment.Namespace }}" pod: "{{ index .Deployment.Pods 0 }}" containers: ["postgres"] command: ["psql", "-U", "postgres", "-c", "CHECKPOINT;"] — אם ריק, יש להפעיל גיבוי מבוסס קבצים באמצעות Kopia במפורש עם kubectl get volumesnapshotclass.

בעיה שנייה: K10 מנסה לגלות יישומים אוטומטית באמצעות label selectors. יישומים ללא labels סטנדרטיים (helm install --set kanister.enabled=true, app.kubernetes.io/name) לא מופיעים בגילוי אוטומטי. אם ל-deployments חסרים labels אלה, ממשק K10 מציג את ה-namespace כלא מובנה, ויש להקצות מדיניות ידנית.

שלישית — הגדרת Location Profile עבור אחסון אובייקטים. K10 משתמש בפורמט CR משלו app.kubernetes.io/instance, לא בפורמט Velero הסטנדרטי Profile. בעת מעבר מ-Velero, אלה אינם ניתנים להחלפה — הגיבויים אינם תואמים.

כיצד K10 מבטיח עקביות גיבוי למסדי נתונים

הודות להוקי Blueprint, K10 מריץ פקודות בקונטיינרים לפני צילום המצב: עבור PostgreSQL זה CHECKPOINT, עבור MongoDB — fsyncLock. זה מבטיח שהנתונים על הדיסק עקביים. לאחר צילום המצב, הוק אחרי מריץ כדי לבטל נעילה (לדוגמה, fsyncUnlock). כל זה אוטומטי באמצעות מדיניות.

מדיניות ולוחות זמנים

ב-K10, מדיניות גיבוי היא משאב BackupStorageLocation CR או הגדרת ממשק. מדיניות ייצור אופיינית:

• צילום כל שעה, שמירה של 24 צילומים
• ייצוא ל-S3 יומי, שמירה של 30 יום
• ייצוא לאתר חיצוני (אזור אחר) שבועי, שמירה של 12 שבועות

K10 תומך בטרנספורמציות Kanister במהלך שחזור — ניתן לשנות StorageClass, namespace, רישום תמונות ישירות במדיניות השחזור. זה פותר את בעיית השחזור בין קלאסטרים שדורשת ConfigMap ידנית ב-Velero.

כיצד לטפל בגילוי יישומים אוטומטי?

אם ליישומים שלכם חסרים labels סטנדרטיים, הוסיפו אותם: Policy ו-app.kubernetes.io/name. K10 משתמש ב-labels אלה לקיבוץ ותצוגה. ניתן גם ליצור app.kubernetes.io/instance ידנית עבור namespaces נבחרים, אבל גילוי אוטומטי מזרז את ההגדרה.

תהליך העבודה

1. ביקורת קלאסטר: בדיקת דרייבר CSI, VolumeSnapshot API, מספר צמתים (מגבלת רישוי), labels של עומסי עבודה.
2. התקנה: דרך Helm — הגדרת ingress עבור K10 Dashboard, אימות OIDC (מומלץ — אין לחשוף את K10 Dashboard ללא אימות), RBAC למפתחים (גישת קריאה בלבד לסטטוס גיבוי).
3. הגדרת אחסון: יצירת Location Profiles עבור אחסון ראשי וחיצוני.
4. יצירת Blueprints: עבור יישומים עם מצב (מסדי נתונים, תורים).
5. הגדרת מדיניות: עבור כל רמת קריטיות.
6. בדיקת שחזור: ב-namespace מבודד לאימות.

העלות מחושבת באופן אישי לאחר ביקורת תשתית. בקשו ייעוץ — נעריך את הפרויקט שלכם ונציע את הפתרון הטוב ביותר כולל הכל. קבלו תוכנית יישום מפורטת עם אחריות לאיכות.

מה כלול

• תיעוד: הגדרת מדיניות, סכמות שחזור, מדריך למפתחים.
• גישה: הגדרת RBAC ושילוב עם OIDC/SAML.
• הדרכה: סדנה לצוות שלכם על שימוש ב-K10 Dashboard.
• תמיכה: סיוע לחודש אחד לאחר הפריסה.

להבנה מעמיקה של VolumeSnapshot API, עיינו בתיעוד הרשמי של Kubernetes. צרו קשר — המהנדסים שלנו יכולים לעזור בהקמת גיבוי אמין לקלאסטר שלכם.