אחסון נתונים באשכול Kubernetes

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

שיטה 1: ציין PV במניפסט הפוד

מניפסט טיפוסי המתאר תרמיל באשכול Kubernetes:

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

בסעיף VolumeMounts ציין את נקודות ההרכבה (mountPath) - באיזו ספרייה בתוך המיכל יורכב אמצעי האחסון הקבוע, וכן את שם אמצעי האחסון.

בסעיף x מפרט את כל הכרכים שבהם נעשה שימוש בתרמיל. ציין את השם של כל אמצעי אחסון, כמו גם את הסוג (במקרה שלנו: awsElasticBlockStore) ופרמטרי החיבור. אילו פרמטרים מופיעים במניפסט תלוי בסוג נפח.

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

שיטת החיבור הזו הומצאה כבר בהתחלה, כשקוברנטס הייתה רק בחיתוליה, והיום השיטה מיושנת.

ישנן מספר בעיות בעת השימוש:

1. יש ליצור את כל אמצעי האחסון באופן ידני; Kubernetes לא יכול ליצור שום דבר עבורנו;
2. פרמטרי גישה לכל נפח הם ייחודיים, ויש לציין אותם במניפסטים של כל הפודים המשתמשים בנפח;
3. כדי לשנות את מערכת האחסון (לדוגמה, לעבור מ-AWS ל-Google Cloud), עליך לשנות את ההגדרות ואת סוג אמצעי האחסון המותקנות בכל המניפסטים.

כל זה מאוד לא נוח, כך שבמציאות שיטה זו משמשת לחיבור רק כמה סוגים מיוחדים של אמצעי אחסון: configMap, secret, emptyDir, hostPath:

• configMap ו- secret הם אמצעי אחסון של שירות המאפשרים ליצור אמצעי אחסון עם קבצים ממניפסטים של Kubernetes במיכל.

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

• hostPath - מאפשר לטעון כל ספרייה בדיסק המקומי של השרת בו האפליקציה פועלת בתוך הקונטיינר עם האפליקציה, כולל /etc/kubernetes. זוהי תכונה לא בטוחה, ולכן מדיניות אבטחה אוסרת בדרך כלל שימוש בנפחים מסוג זה. אחרת, אפליקציה של תוקף תוכל להעלות את ספריית HTC Kubernetes בתוך המיכל שלה ולגנוב את כל אישורי האשכול. בדרך כלל, אמצעי אחסון hostPath מותרים לשימוש רק על ידי יישומי מערכת הפועלים במרחב השמות של מערכת kube.

מערכות אחסון ש-Kubernetes עובדת איתן מהקופסה ניתנים בתיעוד.

שיטה 2. חיבור למוקדי SC/PVC/PV

שיטת חיבור חלופית היא הרעיון של Storage class, PersistentVolumeClaim, PersistentVolume.

שיעור אחסון מאחסן פרמטרים של חיבור למערכת אחסון הנתונים.

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

מהות הרעיון: במניפסט הפוד הם מציינים נפח מסוג PersistentVolumeClaim ומציינים את השם של הישות הזו בפרמטר claimName.

מניפסט PersistentVolumeClaim מתאר את הדרישות לנפח הנתונים שהאפליקציה דורשת. לְרַבּוֹת:

• גודל דיסק;
• שיטת גישה: ReadWriteOnce או ReadWriteMany;
• קישור למחלקת Storage - באיזו מערכת אחסון נתונים אנו רוצים ליצור את הנפח.

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

מניפסטים של PersistentVolume מציינים את מחלקת האחסון ופרמטרי גישה עבור אמצעי אחסון ספציפי (מזהה אמצעי אחסון, נתיב וכו').

בעת יצירת PVC, Kubernetes בוחנת איזה גודל נפח ואיזה מחלקת אחסון נדרשת, ובוחרת נפח Persistent חינם.

אם PVs כאלה אינם זמינים, Kubernetes יכול להשיק תוכנית מיוחדת - Provisioner (השם שלה מצוין במחלקת Storage). תוכנית זו מתחברת למערכת האחסון, יוצרת נפח בגודל הנדרש, מקבלת מזהה ויוצרת מניפסט PersistentVolume באשכול Kubernetes, המשויך ל-PersistentVolumeClaim.

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

כל הפרמטרים לחיבור למערכת אחסון הנתונים ממוקמים במחלקת Storage, עליה אחראים מנהלי אשכולות. כל מה שאתה צריך לעשות בעת מעבר מ-AWS ל-Google Cloud הוא לשנות את השם של מחלקת האחסון ל-PVC במניפסטים של האפליקציה. נפח התמדה לאחסון נתונים ייווצר באשכול באופן אוטומטי באמצעות תוכנית Provisioner.

שיטה 3: ממשק אחסון מיכל

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

כדי לפתור את הבעיה, מפתחים מ-Cloud Foundry, Kubernetes, Mesos ו-Docker יצרו את ה-Container Storage Interface (CSI) - ממשק מאוחד פשוט המתאר את האינטראקציה של מערכת ניהול המכולות ומנהל התקן מיוחד (CSI Driver) שעובד עם ספציפי מערכת אחסון. כל הקוד לאינטראקציה עם מערכות אחסון הועבר מליבת Kubernetes למערכת נפרדת.

תיעוד ממשק אחסון מיכל.

בדרך כלל, מנהל התקן CSI מורכב משני רכיבים: Plugin Node ו-Controller plugin.

תוסף Node פועל על כל צומת ואחראי על הרכבת אמצעי אחסון וביצוע פעולות עליהם. תוסף Controller מקיים אינטראקציה עם מערכת האחסון: יוצר או מוחק אמצעי אחסון, מקצה זכויות גישה וכו'.

לעת עתה, הדרייברים הישנים נשארים בליבת Kubernetes, אך כבר לא מומלץ להשתמש בהם ולכולם מומלץ להתקין את ה-CSI Driver במיוחד עבור המערכת איתה הם יעבדו.

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

ניקח דוגמה כדי להסתכל על היתרונות שאתה יכול לקבל על ידי מעבר לחיבור מערכות אחסון Ceph באמצעות מנהל ההתקן CSI.

בעבודה עם Ceph, תוסף CSI מספק יותר אפשרויות לעבודה עם מערכות אחסון מאשר מנהלי התקנים מובנים.

1. יצירת דיסק דינמי. בדרך כלל נעשה שימוש בדיסקי RBD רק במצב RWO, אך CSI עבור Ceph מאפשר להשתמש בהם במצב RWX. מספר פודים בצמתים שונים יכולים להרכיב את אותו דיסק RDB על הצמתים שלהם ולעבוד איתם במקביל. למען ההגינות, לא הכל כל כך בהיר - ניתן לחבר את הדיסק הזה רק כהתקן בלוק, מה שאומר שתצטרכו להתאים את האפליקציה לעבוד איתו במצב ריבוי גישה.
2. יצירת צילומי מצב. באשכול Kubernetes, אתה יכול ליצור מניפסט עם הדרישה ליצור תמונת מצב. הפלאגין CSI יראה את זה ויצלם תמונת מצב מהדיסק. בהתבסס על זה, אתה יכול לעשות גיבוי או עותק של PersistentVolume.
3. הגדלת גודל הדיסק על אחסון ו-PeristentVolume באשכול Kubernetes.
4. מכסות. מנהלי ההתקן של CephFS המובנים ב-Kubernetes אינם תומכים במכסות, אך תוספים חדשים של CSI עם ה-Ceph Nautilus העדכניים ביותר יכולים לאפשר מכסות במחיצות CephFS.
5. מדדים. תוסף CSI יכול לספק ל-Prometheus מגוון מדדים לגבי אילו נפחים מחוברים, איזו תקשורת מתרחשת וכו'.
6. מודע לטופולוגיה. מאפשר לך לציין במניפסטים כיצד האשכול מופץ גיאוגרפית, ולהימנע מחיבור מערכת אחסון הממוקמת באמסטרדם לתרמילים הפועלים בלונדון.

כיצד לחבר את Ceph לאשכול Kubernetes באמצעות CSI, ראה בחלק המעשי של הרצאת בית ספר ערב סלורם. אתה יכול גם להירשם ל קורס וידאו של Ceph, שיושק ב-15 באוקטובר.

מחבר המאמר: Sergey Bondarev, אדריכל פעיל בסאות'ברידג', Certified Kubernetes Administrator, אחד ממפתחי kubespray.

קצת פוסט סקריפטום לא לפרסום, אלא לתועלת...

נ.ב. סרגיי בונדרב מוביל שני קורסים אינטנסיביים: מעודכן בסיס Kubernetes 28-30 בספטמבר ומתקדם Kubernetes Mega 14–16 באוקטובר.

מקור: www.habr.com