Storage

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

סיכום

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

  • מנהל התקן של vSphere Container Storage Interface ‏ (CSI)
  • מנהלי התקנים של 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 שמוגדר כברירת מחדל, ומופיע בו מנהל ההקצאות (provisioner) של 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 migration.

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

בעבר, תוסף נפח vSphere בתוך העץ היה ספק השירות של StorageClass שמוגדר כברירת מחדל באשכולות משתמשים. אבל עכשיו התוסף של נפח vSphere בתוך העץ הוצא משימוש, והדרייבר של vSphere CSI הוא ספק השירות של 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.

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

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

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

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

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

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

ניקוי נפח

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

פתרון בעיות

פתרון בעיות באחסון

קריאה נוספת