Storage

בדף הזה מוסברים מושגים שקשורים לאחסון ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware.

סיכום

‫Google Distributed Cloud משתלב עם מערכות חיצוניות לאחסון בלוקים או קבצים באמצעות:

  • מנהל התקן ה-CSI של vSphere Container Storage Interface
  • מנהלי התקנים של CSI של צד שלישי
  • פלאגינים של נפחים בתוך העץ ב-Kubernetes

מאגרי נתונים של vSphere

כשיוצרים אשכול ניהול, מציינים מאגר נתונים קיים של vSphere לנתוני ה-etcd של האשכול.

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

אפשר לגבות את מאגרי הנתונים של vSphere שבהם משתמשים אשכולות האדמין והמשתמשים באמצעות NFS,‏ vSAN או VMFS במכשיר בלוקים, כמו מערך אחסון חיצוני. בסביבה עם כמה מארחים, כל מכשיר בלוקים צריך להיות מחובר לכל המארחים בסביבה, ומאגר הנתונים צריך להיות מוגדר בכל מארח באמצעות האפשרות Mount Datastore on Additional Hosts.

StorageClasses

כשיוצרים PersistentVolumeClaim, אפשר לציין StorageClass שמספק מידע על אופן הקצאת האחסון. אם לא מציינים StorageClass, המערכת משתמשת ב-StorageClass שמוגדר כברירת מחדל.

‫StorageClass של אשכול האדמין

באשכולות ניהול, יש StorageClass בשם standard, והוא מוגדר כ-StorageClass שמוגדר כברירת מחדל. ב-standard StorageClass מופיע התוסף של נפח vSphere בתוך העץ כספק השירות.

כדי לראות את standard StorageClass:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
    standard --output yaml

בפלט אפשר לראות ש-standard הוא StorageClass שמוגדר כברירת מחדל, ושה-provisioner הוא התוסף vSphere in-tree volume,‏ kubernetes.io/vsphere-volume. אפשר גם לראות את השם של מאגר נתונים של vSphere.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  ...
  labels:
    bundle.gke.io/component-name: admin-storage-class
  name: standard
...
parameters:
  datastore: vsanDatastore
provisioner: kubernetes.io/vsphere-volume
...

‫StorageClasses באשכול משתמש

באשכולות משתמשים יש StorageClass בשם standard ועוד StorageClass בשם standard-rwo.

standard-rwo StorageClass מוגדר כ-StorageClass שמוגדר כברירת מחדל, ומופיע בו מנהל ההקצאה של vSphere CSI driver.

כדי לראות את standard-rwo StorageClass:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
    standard-rwo --output yaml

בפלט אפשר לראות ש-standard-rwo הוא StorageClass שמוגדר כברירת מחדל, ושה-provisioner הוא מנהל ההקצאה של vSphere CSI, ‏ csi.vsphere.vmware.com. אפשר גם לראות את כתובת ה-URL של מאגר נתונים ב-vSphere:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
    ...
  labels:
    bundle.gke.io/component-name: user-vsphere-csi-driver-addon
    ...
  name: standard-rwo
...
parameters:
  datastoreURL: ds:///vmfs/volumes/vsan:52fb6ca22be2454e-e67f620175964a9f/
provisioner: csi.vsphere.vmware.com
...

פלאגינים של נפחים בתוך העץ ב-Kubernetes

‫Kubernetes מגיעה עם מספר תוספים לניהול נפח אחסון בתוך העץ. עם זאת, רוב התוספים האלה של נפחים בתוך העץ הוצאו משימוש (כולל התוסף של נפחים בתוך העץ של vSphere). למידע נוסף, אפשר לעיין בפרויקט העברה ל-CSI.

העברת CSI למנהל האחסון של vSphere

בעבר, תוסף נפח vSphere בתוך העץ היה ספק השירות של StorageClass שמוגדר כברירת מחדל באשכולות משתמשים. אבל עכשיו התוסף vSphere volume in-tree הוצא משימוש, וה-driver של vSphere CSI הוא ה-provisioner של StorageClass שמוגדר כברירת מחדל באשכולות משתמשים. מומלץ להשתמש במקום זאת במנהל התקנים של vSphere CSI.

החל מגרסה 1.15 של Google Distributed Cloud, תכונת ההעברה של Kubernetes CSI מופעלת כברירת מחדל עבור התוסף של נפח vSphere בתוך העץ. כלומר, אם עומס עבודה משתמש בנפח vSphere בתוך העץ, כל הקריאות לפעולות אחסון פנימיות מנותבות מחדש באופן אוטומטי לדרייבר vSphere CSI.

לדוגמה, נניח ש-PersistentVolumeClaim מציין את standardStorageClass, שבו מפורט התוסף kubernetes.io/vsphere-volume של נפח vSphere בתוך העץ, כמנהל הקצאות. לאחר מכן, כל עומס עבודה שמשתמש ב-PersistentVolumeClaim הזה יגרום להפניה מחדש של הקריאות לפעולות אחסון אל מנהל ההתקן של vSphere CSI,‏ csi.vsphere.vmware.com.

בדיקות קדם הפעלה

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

לדוגמה, בדיקות קדם ההפעלה:

  • מוודאים שהגרסאות של vCenter ו-ESXI מתאימות.
  • מוודאים שמנהל ההתקן של vSphere CSI מופעל אם יש כרכים מתמידים של vSphere בתוך העץ.
  • מוודאים של-StorageClasses ב-vSphere אין פרמטרים מסוימים שמתעלמים מהם אחרי העברת CSI.
  • אימות ההערות ב-PersistentVolumes וב-PersistentVolumeClaims שנוצרו באופן סטטי בתוך העץ, שנדרשים להעברה ל-CSI.
  • מוודאים שהאשכול יכול להריץ עומס עבודה באמצעות נפח CSI שהוקצה על ידי מנהל ההתקן של vSphere CSI.

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

בעיות מוכרות

יש כמה בעיות מוכרות שקשורות ל-vSphere CSI Driver. מידע ופתרונות זמינים בקטע 'בעיות מוכרות' בנתוני הגרסה של VMWare vSphere CSI Driver 3.0.

השלמת המיגרציה ל-CSI

התכונה Kubernetes CSI migration מופעלת כברירת מחדל בגרסה 1.15. התכונה מאפשרת ל-PersistentVolume שמגובה על ידי הפלאגין in-tree vSphere volume להמשיך לפעול בסביבה שבה מותקן רק CSI. התכונה פשוט מפנה את הקריאות לפעולות של הפלאגין in-tree אל פלאגין ה-CSI. מכיוון שמפרט PersistentVolume הוא קבוע, המפרט יהיה זהה לזה של תוסף נפח בתוך העץ.

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

שימוש במנהלי התקנים של צד שלישי

אם רוצים להקצות נפחי אחסון שאינם מאגרי נתונים של vSphere, אפשר ליצור StorageClass חדש באשכול שמשתמש במנהל התקנים שונה של אחסון. אחר כך אפשר להגדיר את StorageClass כברירת המחדל של האשכול או להגדיר את עומסי העבודה כך שישתמשו ב-StorageClass (דוגמה ל-StatefulSet).

שותפי אחסון

אנחנו משתפים פעולה עם הרבה ספקי אחסון כדי לאשר את מערכות האחסון שלהם לשימוש ב-Google Distributed Cloud. כאן מפורטת הרשימה המלאה של שותפים שעומדים בדרישות לאחסון.

הרחבת נפח

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

במקרה של vSphere CSI driver, אפשר להרחיב את נפח האחסון במצב אופליין בגרסאות vSphere החל מגרסה 7.0, ובמצב אונליין בגרסאות vSphere החל מגרסה 7.0 Update 2.

ב-StorageClass, הערך של allowVolumeExpansion מוגדר כ-true כברירת מחדל עבור אשכולות חדשים שפועלים ב-vSphere 7.0 ומעלה.standard-rwo אפשר להשתמש בהרחבה אונליין ואופליין של נפחים באמצעות StorageClass הזה. במקרה של שדרוג אשכול, מכיוון ש-StorageClasses לא משתנים בשדרוגי אשכולות, כשמשדרגים אשכול מגרסה 1.7 לגרסה 1.8, ההגדרה allowVolumeExpansion ב-standard-rwo נשארת לא מוגדרת, מה שאומר שאסור להרחיב את נפח האחסון.

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

תמונות מצב של נפחי אחסון ב-CSI

אפשר ליצור תמונות מצב של אחסון מתמשך באמצעות המשאבים VolumeSnapshot ו-VolumeSnapshotClass. כדי להשתמש בתכונה הזו בנפח CSI, מנהל ההתקן של CSI צריך לתמוך בתמונות מצב של נפח, וקובץ ה-sidecar של external-snapshotter צריך להיכלל בפריסת מנהל ההתקן של CSI.

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

בקרי הצילום של CSI נפרסים באופן אוטומטי כשיוצרים אשכול.

ניקוי נפח האחסון

כשמוחקים אשכול משתמשים, אמצעי אחסון שהוקצו על ידי מנהל התקני ה-CSI של vSphere לא נמחקים. לפני שמוחקים את האשכול, צריך למחוק את כל הווליומים, את PersistentVolumeClaims ואת StatefulSets.

פתרון בעיות

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

קריאה נוספת