שימוש במנהל התקן ה-CSI של דיסקים לאחסון מתמיד ב-Compute Engine

טייס אוטומטי רגילה

‫Google Kubernetes Engine‏ (GKE) מספק דרך פשוטה לפרוס ולנהל באופן אוטומטי את מנהל ההתקן של Container Storage Interface‏ (CSI) של דיסק מתמשך ב-Compute Engine באשכולות. מנהל ההתקן של CSI לדיסק אחסון מתמיד ב-Compute Engine תמיד מופעל באשכולות Autopilot, ואי אפשר להשבית או לערוך אותו. באשכולות Standard, צריך להפעיל את מנהל ההתקן של ממשק אחסון בקונטיינרים (CSI) לדיסק אחסון מתמיד של Compute Engine.

גרסת ה-CSI Driver של דיסק מתמשך ב-Compute Engine קשורה למספרי הגרסאות של GKE. גרסת ה-CSI Driver של דיסק מתמשך ב-Compute Engine היא בדרך כלל הגרסה העדכנית ביותר שזמינה בזמן שחרור גרסת GKE. העדכון של מנהלי ההתקנים מתבצע באופן אוטומטי כשמשדרגים את האשכול לתיקון (patch) האחרון של GKE.

הערה: מכיוון שמנהל ההתקן של CSI לדיסק הקבוע של Compute Engine וחלק מרכיבי ה-CSI המשויכים האחרים נפרסים כקונטיינרים נפרדים, הם צורכים משאבים (מעבד של VM, זיכרון ודיסק אתחול) בצומתי Kubernetes. השימוש במעבד (CPU) של המכונה הווירטואלית הוא בדרך כלל עשרות מילי-ליבות, והשימוש בזיכרון הוא בדרך כלל עשרות מגה-בייט. השימוש בדיסק האתחול נובע בעיקר מהיומנים של מנהל ההתקן CSI וקונטיינרים אחרים של המערכת בפריסה.

יתרונות

לשימוש במנהל התקן CSI של דיסק לאחסון מתמיד ב-Compute Engine יש את היתרונות הבאים:

• הוא מאפשר פריסה וניהול אוטומטיים של מנהל ההתקן של Persistent Disk, בלי צורך להגדיר אותו באופן ידני.
• אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). המפתחות האלה משמשים להצפנת המפתחות להצפנת נתונים, שבאמצעותם מוצפנים הנתונים שלכם. למידע נוסף על CMEK ב-GKE, קראו את המאמר שימוש ב-CMEK.
• אפשר להשתמש בתמונות מצב של נפחים עם מנהל התקן ה-CSI של דיסק מתמשך ב-Compute Engine. תמונות מצב של נפח אחסון מאפשרות ליצור עותק של נפח האחסון בנקודת זמן ספציפית. אתם יכולים להשתמש בעותק הזה כדי להחזיר נפח אחסון למצב קודם או כדי להקצות נפח אחסון חדש.
• אפשר להשתמש בשיבוט נפחים עם מנהל ההתקן של ה-CSI של דיסק מתמשך ב-Compute Engine באשכולות שמריצים GKE בגרסה 1.22 ואילך. שיבוט נפח מאפשר ליצור עותק של הנפח בנקודת זמן ספציפית, עם כל הנתונים מנפח המקור.
• תיקוני באגים ועדכוני תכונות מופצים בנפרד מגרסאות Kubernetes משניות. לוח הזמנים הזה בדרך כלל מוביל לקצב מהיר יותר של פרסום גרסאות.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

• מפעילים את ממשק ה-API של Google Kubernetes Engine.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, צריך להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

הפעלת מנהל התקן CSI של דיסק קבוע ב-Compute Engine

כדי להפעיל את מנהל התקן ה-CSI של Persistent Disk ב-Compute Engine באשכולות Standard קיימים, משתמשים ב-Google Cloud CLI או במסוף Google Cloud .

כדי להפעיל את ה-driver באשכול קיים, מבצעים את השלבים הבאים:

gcloud

gcloud container clusters update CLUSTER-NAME \
   --update-addons=GcePersistentDiskCsiDriver=ENABLED

מחליפים את CLUSTER-NAME בשם של האשכול הקיים.

המסוף

1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

   כניסה ל-Google Kubernetes Engine

2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

3. בקטע Features (תכונות), לצד השדה Compute Engine persistent disk CSI Driver (מנהל התקן CSI של דיסק לאחסון מתמיד ב-Compute Engine), לוחצים על Edit Compute Engine CSI driver (עריכת מנהל התקן CSI של Compute Engine).

4. מסמנים את התיבה Enable Compute Engine Persistent Disk CSI Driver.

5. לוחצים על שמירת השינויים.

אחרי שמפעילים את מנהל ההתקן CSI של Persistent Disk ב-Compute Engine, אפשר להשתמש במנהל ההתקן בנפחי אחסון של Kubernetes באמצעות שם מנהל ההתקן ומנהל ההקצאות: pd.csi.storage.gke.io.

השבתת מנהל התקן CSI של דיסק לאחסון מתמיד ב-Compute Engine

אפשר להשבית את מנהל ההתקן CSI של דיסק מתמשך ב-Compute Engine עבור אשכולות רגילים באמצעות Google Cloud CLI או Google Cloud המסוף.

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

הערה: סוג הנפח gcePersistentDisk מועבר למנהל ההתקן של ה-CSI של דיסקים קשיחים ב-Compute Engine בגרסה 1.22 ואילך. לכן, אם משביתים את מנהל ההתקן של ה-CSI של דיסקים קשיחים, גם סוג הנפח gcePersistentDisk מפסיק לפעול.

אזהרה: יש בעיה מוכרת ב-GKE בגרסה 1.21 ואילך אם אתם משתמשים במנהל ההתקן של דיסקים קשיחים בתוך העץ ורוצים למחוק דיסקים אזוריים. יכולה להיות דליפה של דיסק אזורי של Compute Engine כשמוחקים את משאב ה-PersistentVolume שקשור אליו. אפשר לזהות את הבעיה הזו אם הקריאה ל-API למחיקת הדיסק האזורי נכשלת ומוחזר קוד שגיאה שאינו NotFound. מידע נוסף זמין בבעיה הזו ב-GitHub.

כדי להשבית את מנהל ההתקן באשכול Standard קיים:

gcloud

gcloud container clusters update CLUSTER-NAME \
    --update-addons=GcePersistentDiskCsiDriver=DISABLED

מחליפים את CLUSTER-NAME בשם של האשכול הקיים.

המסוף

1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

   מעבר אל Google Kubernetes Engine

2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

3. בקטע Features (תכונות), לצד השדה Compute Engine persistent disk CSI Driver (מנהל התקן CSI של דיסק לאחסון מתמיד ב-Compute Engine), לוחצים על Edit Compute Engine CSI driver (עריכת מנהל התקן CSI של Compute Engine).

4. מבטלים את הסימון בתיבה Enable Compute Engine Persistent Disk CSI Driver.

5. לוחצים על שמירת השינויים.

שימוש במנהל התקן ה-CSI של דיסקים לאחסון מתמיד ב-Compute Engine לאשכולות Linux

בקטעים הבאים מתואר התהליך האופייני לשימוש בנפח Kubernetes שמגובה על ידי דרייבר CSI ב-GKE. הקטעים האלה רלוונטיים רק לאשכולות שמשתמשים ב-Linux.

יצירת StorageClass

אחרי שמפעילים את מנהל ה-CSI של דיסק מתמשך ב-Compute Engine, ‏ GKE מתקין אוטומטית את StorageClasses הבאים:

• ‫standard-rwo, באמצעות דיסק אחסון מתמיד מאוזן
• ‫premium-rwo, באמצעות דיסק מתמיד שמבוסס על SSD

באשכולות Autopilot, ברירת המחדל של StorageClass היא standard-rwo, שמשתמשת במנהל התקן ה-CSI של דיסק מתמשך ב-Compute Engine. באשכולות Standard, סוג האחסון (StorageClass) שמוגדר כברירת מחדל משתמש בתוסף נפח gcePersistentDisk בתוך העץ של Kubernetes.

כדי לראות את השם של StorageClasses שהותקנו, מריצים את הפקודה הבאה:

kubectl get sc

אפשר גם להתקין StorageClass אחר שמשתמש במנהל התקן ה-CSI של דיסק מתמשך ב-Compute Engine. כדי לעשות את זה, מוסיפים pd.csi.storage.gke.io בשדה provisioner.

לדוגמה, אפשר ליצור StorageClass באמצעות הקובץ הבא, שנקרא pd-example-class.yaml.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-example
provisioner: pd.csi.storage.gke.io
# Recommended setting. Delays the binding and provisioning of a PersistentVolume until a Pod that uses the
# PersistentVolumeClaim is created and scheduled on a node.
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced

אפשר לציין את סוגי הדיסקים הקבועים הבאים בפרמטר type:

• pd-balanced
• pd-ssd
• pd-standard
• ‫pd-extreme (נתמך ב-GKE מגרסה 1.26 ואילך)

אם אתם משתמשים ב-pd-standard או ב-pd-extreme, כדאי לעיין בסוגי מכונות שלא נתמכים כדי לקבל מידע על הגבלות נוספות לשימוש.

כשמשתמשים באפשרות pd-extreme, צריך להוסיף את השדה provisioned-iops-on-create למניפסט. הערך של השדה הזה צריך להיות זהה לערך ה-IOPS שהוקצה שציינתם כשנוצר הדיסק הקשיח.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-extreme-example
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-extreme
  provisioned-iops-on-create:'10000'

אחרי שיוצרים את הקובץ pd-example-class.yaml, מריצים את הפקודה הבאה:

kubectl create -f pd-example-class.yaml

יצירת PersistentVolumeClaim

אפשר ליצור PersistentVolumeClaim שמפנה ל-StorageClass של מנהל ה-CSI של דיסק קבוע ב-Compute Engine.

הקובץ הבא, שנקרא pvc-example.yaml, משתמש בסוג האחסון (storage class) שהותקן מראש standard-rwo:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard-rwo
  resources:
    requests:
      storage: 6Gi

אחרי שיוצרים את מניפסט PersistentVolumeClaim, מריצים את הפקודה הבאה:

kubectl create -f pvc-example.yaml

ב-StorageClass שהותקן מראש (standard-rwo), volumeBindingMode מוגדר ל-WaitForFirstConsumer. כשהערך של volumeBindingMode הוא WaitForFirstConsumer, לא מתבצעת הקצאה של PersistentVolume עד שתזמון של Pod שמפנה אל PersistentVolumeClaim. אם volumeBindingMode ב-StorageClass מוגדר ל-Immediate (או אם הוא מושמט), PersistentVolume שמגובה בדיסק קבוע מוקצה אחרי שנוצר PersistentVolumeClaim.

יצירת Pod שמשתמש בנפח האחסון

כשמשתמשים בפודים עם PersistentVolumes, מומלץ להשתמש בבקר של עומס עבודה (כמו Deployment או StatefulSet). בדרך כלל לא משתמשים ב-Pod עצמאי, אבל בדוגמה הבאה משתמשים בו כדי לפשט את הדברים.

בדוגמה הבאה נעשה שימוש בנפח האחסון שיצרתם בקטע הקודם:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /var/lib/www/html
         # The name of the volume that is being defined in the "volumes" section.
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       # References the PersistentVolumeClaim created earlier.
       claimName: podpvc
       readOnly: false

תזמון תאימות האחסון ב-GKE Autopilot

באשכולות Autopilot, ‏ GKE מנהל באופן אוטומטי את הקצאת הצמתים והמשאבים. כדי שמערכת Autopilot תקצה צמתים שתואמים לסוג האחסון המבוקש, צריך לציין את הפרמטר use-allowed-disk-topology: "true" בהגדרה המותאמת אישית של StorageClass.

הגדרת הפרמטר הזה מחייבת את התנהגויות התזמון הבאות:

• הכלי Cluster Autoscaler מקצה רק צמתים חדשים עם סוגי מכונות שתומכים בסוג הדיסק המבוקש.
• ה-Pod מתוזמן בצומת תואם. התזמון הזה מונע מה-Pod להיתקע במצבים ContainerCreating או Pending.

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

בסדרות חדשות יותר של מכונות, כמו C3 או E4, נדרש אחסון ב-Google Cloud Hyperdisk (כמו hyperdisk-balanced). בסדרות המכונות האלה אין תמיכה בסוגים קודמים של נפחי אחסון ב-Persistent Disk, כמו נפחי אחסון ב-Persistent Disk רגיל (pd-standard) או ב-SSD Persistent Disk (pd-ssd). התאימות של האחסון משפיעה על התזמון באופן הבא:

• מעבר חלקה: אם עומס עבודה עם שמירת מצב משתמש בסוג נפח של Persistent Disk מגרסה קודמת, כמו נפחים של Persistent Disk רגיל (pd-standard) או SSD Persistent Disk ‏ (pd-ssd), אבל לא מבקש במפורש סדרת מכונות ספציפית, GKE מתזמן אוטומטית את ה-Pods בצמתי E2 כי הם תומכים בסוגי הנפח האלה של Persistent Disk. עומס העבודה חוזר בשקט מהחומרה החדשה יותר שמוגדרת כברירת מחדל.
• תזמון נכשל (בהמתנה): יכול להיות שביקשתם במפורש סדרת מכונות חדשה יותר (לדוגמה, באמצעות שדות nodeSelector או ComputeClass מותאם אישית). אם מצרפים גם סוג קודם של נפח Persistent Disk, כמו נפחי דיסק מתמיד סטנדרטי (pd-standard) או נפחי דיסק מתמיד שמבוסס על SSD‏ (pd-ssd), GKE לא יכול למצוא צומת שעומד בשתי המגבלות. ה-Pod נשאר במצב Pending.
• קונפליקט בין סוגי אחסון שונים (בהמתנה): אם Pod מפנה לכמה PVC שמשתמשים בסוגי אחסון שונים (לדוגמה, שילוב של סוג נפח מוקדם יותר של Persistent Disk כמו Persistent Disk רגיל (pd-standard) ואחסון Google Cloud Hyperdisk), יכול להיות ש-GKE לא יוכל למצוא סוג צומת שתומך בכל האילוצים. במקרה כזה, ה-Pod נשאר במצב Pending.
• ‫Insufficient CPU request for extreme disks (Pending): סוגי נפחים קיצוניים, כמו hyperdisk-extreme ו-pd-extreme, דורשים צורות גדולות של מכונות וירטואליות עם מספרים גבוהים של vCPU. אם בקשת ה-Pod שלכם כוללת מעט מדי ליבות וירטואליות של CPU‏ (vCPU), יכול להיות ש-GKE יקצה צורה של צומת שלא תומכת בסוג הנפח, ולכן ה-Pod יישאר במצב Pending. כדי לוודא שהתזמון מתבצע בצורה תקינה, צריך לציין בקשות למעבדים שהן גדולות מספיק כדי ש-Autopilot יקצה צורה נתמכת של מכונה וירטואלית. רשימה של סוגי המכונות הנתמכים ודרישות המינימום של vCPU זמינה במאמר תמיכה במכונות.

הוראות לפתרון בעיות ופרטים על אופן האימות של ההתנהגות הזו באמצעות בדיקת יומנים זמינים במאמר Workload scheduled on older machine series or stuck in Pending state due to storage incompatibility (עומס עבודה מתוזמן בסדרת מכונות ישנה יותר או תקוע במצב בגלל חוסר תאימות לאחסון).

שימוש במנהל התקן ה-CSI של דיסקים לאחסון מתמיד ב-Compute Engine עבור אשכולות Windows

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

חשוב לוודא ש:

• גרסת האשכול היא 1.19.7-gke.2000,‏ 1.20.2-gke.2000 או גרסה מתקדמת יותר.
• גרסאות הצמתים הן ‎1.18.12-gke.1203,‏ ‎1.19.6-gke.800 או גרסה חדשה יותר.

יצירת StorageClass

יצירת StorageClass ל-Windows דומה מאוד ליצירה ל-Linux. חשוב לדעת ש-StorageClass שמותקן כברירת מחדל לא יפעל ב-Windows כי סוג מערכת הקבצים שונה. מנהל התקן ה-CSI של דיסק לאחסון מתמיד ב-Compute Engine ל-Windows דורש NTFS כסוג מערכת הקבצים.

לדוגמה, אפשר ליצור StorageClass באמצעות הקובץ הבא שנקרא pd- windows-class.yaml. חשוב להוסיף את csi.storage.k8s.io/fstype: NTFS לרשימת הפרמטרים:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-sc-windows
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: NTFS

יצירת PersistentVolumeClaim

אחרי שיוצרים StorageClass ל-Windows, אפשר ליצור PersistentVolumeClaim שמפנה ל-StorageClass הזה:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc-windows
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: pd-sc-windows
  resources:
    requests:
      storage: 6Gi

יצירת Pod שמשתמש בנפח האחסון

בדוגמה הבאה נעשה שימוש בנפח האחסון שיצרתם במשימה הקודמת:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  # Node selector to ensure the Pod runs on a Windows node.
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: iis-server
      # The container image to use.
      image: mcr.microsoft.com/windows/servercore/iis
      ports:
      - containerPort: 80
      volumeMounts:
      # The path in the container where the volume will be mounted.
      - mountPath: /var/lib/www/html
        name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        # References the PersistentVolumeClaim created earlier.
        claimName: podpvc-windows
        readOnly: false

אפשר לשנות באופן דינמי את ה-IOPS ואת קצב העברת הנתונים של Hyperdisk באמצעות VolumeAttributeClass

אפשר להשתמש ב-VolumeAttributesClass עם מנהל התקן ה-CSI של דיסקים לאחסון מתמיד ב-Compute Engine כדי לשנות באופן דינמי מאפיינים של דיסקים לאחסון מתמיד, כולל IOPS וקצב העברת נתונים. מוודאים שגרסת אשכול GKE היא 1.34 ואילך.

בקטע הזה נסביר איך להשתמש ב-VolumeAttributesClass כדי לשנות באופן דינמי את ביצועי עוצמת הקול. יוצרים שני משאבי VolumeAttributesClass,‏ silver ו-gold, כדי להגדיר רמות שונות של IOPS ושל קצב העברת נתונים. אחר כך יוצרים StorageClass, ‏PersistentVolumeClaim שמפנה לרמה silver ו-Pod כדי לצרוך את הנפח. לבסוף, מעדכנים את PersistentVolumeClaim כך שיפנה לרמת gold, וכך מתבצע עדכון דינמי של הגדרות הביצועים של אמצעי האחסון.

הערה: למרות שבדף הזה מוסבר על השימוש הכללי ב-StorageClass ובמניפסטים של Pod עבור נפח אחסון של Persistent Disk, כדי להגדיר ולאמת את תכונות הביצועים הספציפיות של Google Cloud Hyperdisk צריך לבצע את תהליך העבודה הבא.

יוצרים VolumeAttributesClass כדי להגדיר רמות ביצועים

בקטע הזה מוגדרים משאבי VolumeAttributesClass עם רמות לדוגמה בשמות silver ו-gold.

1. שומרים את קובץ המניפסט הבא בשם vac-classes.yaml:

   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: silver
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "3000"
     throughput: "188Mi"
   ---
   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: gold
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "6000"
     throughput: "345Mi"
   

2. החלת המניפסט:

   kubectl apply -f vac-classes.yaml
   

יצירת StorageClass ל-Hyperdisk

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

1. שומרים את קובץ המניפסט הבא בשם hyperdisk-sc.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hyperdisk-example
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     type: hyperdisk-balanced
   

2. מחילים את המניפסט:

   kubectl apply -f hyperdisk-sc.yaml
   

יצירת PVC עם רמת ביצועים ראשונית

בקטע הזה נוצר PVC ונעשה שימוש ברמת המינוי הראשונית שנקראת silver.

1. שומרים את המניפסט הבא בתור vac-silver-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: silver
     resources:
       requests:
         storage: 200Gi
   

2. החלת המניפסט:

   kubectl apply -f vac-silver-pvc.yaml
   

3. כדי להקצות נפח אחסון מתמיד, יוצרים Pod שמשתמש ב-PVC. ה-StorageClass שנוצר בקטע הקודם מגדיר את volumeBindingMode: WaitForFirstConsumer, מה שמעכב את הקצאת הנפח עד ש-Pod צורך את ה-PVC. שומרים את המניפסט הבא בתור test-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pvc-pod
   spec:
     containers:
       - name: nginx-container
         image: nginx:latest
         ports:
           - containerPort: 80
         volumeMounts:
           - name: pvc-storage
             mountPath: /usr/share/nginx/html
     volumes:
       - name: pvc-storage
         persistentVolumeClaim:
           claimName: test-pv-claim
   

4. החלת המניפסט:

   kubectl apply -f test-pod.yaml
   

5. כדי לבדוק את הגדרות הביצועים של הדיסק, אפשר לעיין במאמר בדיקת הגדרות הביצועים של הדיסק במסוף Google Cloud . ערך Provisioned IOPS צריך להיות 3000 וערך Provisioned throughput צריך להיות 188.

עדכון ה-PVC לשימוש בשכבת ביצועים אחרת

בקטע הזה מעדכנים את ה-PVC כך שישתמש ברמה gold במקום ברמה silver.

1. שומרים את קובץ המניפסט הבא בשם vac-gold-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: gold
     resources:
       requests:
         storage: 200Gi
   

2. מחילים את המניפסט:

   kubectl apply -f vac-gold-pvc.yaml
   

3. כדי לוודא שהגדרות הביצועים של הדיסק עודכנו, אפשר לעיין במאמר אימות הגדרות הביצועים של הדיסק במסוף Google Cloud . ערך Provisioned IOPS צריך להיות 6000 וערך Provisioned throughput צריך להיות 345.

אימות הגדרות הביצועים של הדיסק ב Google Cloud מסוף

כדי לוודא שהגדרות ה-IOPS וקצב הנתונים חלות על ה-Persistent Disk, בודקים את פרטי הדיסק במסוף Google Cloud .

1. אחזור שם הדיסק:

   PV_NAME=$(kubectl get pvc test-pv-claim -o=jsonpath='{.spec.volumeName}')
   DISK_NAME=$(kubectl get pv $PV_NAME -o=jsonpath='{.spec.csi.volumeHandle}' | sed 's|.*/||')
   echo "Persistent disk name: $DISK_NAME"
   

2. נכנסים לדף Disks במסוף Google Cloud .

   לפתיחת הדף Disks

3. לוחצים על השם של הדיסק הקשיח התמידי שזהה לשם הדיסק מהפלט של השלב הקודם.

4. בדף Disk details (פרטי הדיסק), בקטע Performance (ביצועים), אפשר לראות את הערכים Provisioned IOPS (פעולות קלט/פלט שהוקצו) ו-Provisioned throughput (קצב העברת הנתונים שהוקצה).

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

שיקולים לגבי שינוי דינמי

• החלת הגדרות קודמות מחדש: אם אי אפשר לקשר PVC עם מחלקת מאפייני נפח בגלל שגיאה, כמו משאבים לא זמינים, אפשר להחיל מחדש את ה-PVC הקודם.
• תמיכה במכסות: מישור הבקרה של Kubernetes יכול לאכוף מכסות על PVC שמפנים אל VolumeAttributesClass ספציפי באמצעות scopeSelector ב-ResourceQuota.

שימוש במנהל התקן ה-CSI של דיסקים לאחסון מתמיד ב-Compute Engine עם סוגים של מערכות קבצים שאינם ברירת המחדל

סוג מערכת הקבצים שמוגדר כברירת מחדל בדיסקים לאחסון מתמיד של Compute Engine ב-GKE הוא ext4. אפשר גם להשתמש בסוג האחסון xfs אם תמונת הצומת תומכת בו. כאן אפשר לעיין ברשימת מנהלי ההתקנים הנתמכים לפי תמונת הצומת.

בדוגמה הבאה אפשר לראות איך משתמשים ב-xfs כסוג ברירת המחדל של מערכת הקבצים במקום ב-ext4 עם מנהל התקן ה-CSI של דיסק מתמשך ב-Compute Engine.

יצירת StorageClass

1. שומרים את המניפסט הבא כקובץ YAML בשם pd-xfs-class.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: xfs-class
   provisioner: pd.csi.storage.gke.io
   parameters:
     # The type of Compute Engine persistent disk to provision.
     type: pd-balanced
     # Specify "xfs" as the filesystem type.
     csi.storage.k8s.io/fstype: xfs
   volumeBindingMode: WaitForFirstConsumer
   

2. מחילים את המניפסט:

   kubectl apply -f pd-xfs-class.yaml
   

יצירת PersistentVolumeClaim

1. שומרים את המניפסט הבא בתור pd-xfs-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: xfs-pvc
   spec:
     # References the StorageClass created earlier.
     storageClassName: xfs-class
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         # The amount of storage requested.
         storage: 10Gi
   

2. החלת המניפסט:

   kubectl apply -f pd-xfs-pvc.yaml
   

יצירת Pod שמשתמש בנפח האחסון

1. שומרים את קובץ המניפסט הבא בשם pd-xfs-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pd-xfs-pod
   spec:
     containers:
     - name: cloud-sdk
       image: google/cloud-sdk:slim
       # Keep the container running for 1 hour.
       args: ["sleep","3600"]
       volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /xfs
         name: xfs-volume
     # Define the volumes available to the containers in the Pod.
     volumes:
     - name: xfs-volume
       persistentVolumeClaim:
         # References the PersistentVolumeClaim created earlier.
         claimName: xfs-pvc
   

2. החלת המניפסט:

   kubectl apply -f pd-xfs-pod.yaml
   

איך מוודאים שהנפח הותקן בצורה נכונה

1. פותחים סשן של מעטפת ב-Pod:

   kubectl exec -it pd-xfs-pod -- /bin/bash
   

2. מחפשים מחיצות xfs:

   df -aTh --type=xfs
   

   הפלט אמור להיראות כך:

   Filesystem     Type  Size  Used Avail Use% Mounted on
   /dev/sdb       xfs    30G   63M   30G   1% /xfs
   

צפייה ביומנים של מנהל התקן CSI של דיסק לאחסון מתמיד ב-Compute Engine

אפשר להשתמש ב-Cloud Logging כדי לראות אירועים שקשורים למנהל התקן ה-CSI של דיסק מתמשך ב-Compute Engine. יומנים יכולים לעזור לכם לפתור בעיות.

מידע נוסף על Cloud Logging זמין במאמר צפייה ביומני GKE.

כדי לראות את היומנים של מנהל ההתקן CSI של דיסק מתמשך ב-Compute Engine, פועלים לפי השלבים הבאים:

1. נכנסים לדף Cloud Logging במסוף Google Cloud .

   כניסה ל-Cloud Logging

2. כדי לסנן את הרשומות ביומן ולהציג רק את הרשומות שקשורות ל-CSI Driver שפועל במרחב השמות, מריצים את השאילתה הבאה ב-Cloud Logging:

    resource.type="k8s_container"
    resource.labels.project_id="PROJECT_ID"
    resource.labels.location="LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.namespace_name="kube-system"
    resource.labels.container_name="gce-pd-driver"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PROJECT_ID: שם הפרויקט.
   • ‫LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול.
   • ‫CLUSTER_NAME: השם של האשכול.

בעיות מוכרות

סוגי מכונות שלא נתמכים

אם אתם משתמשים בקבוצת המכונות מסדרת C3, אין תמיכה בסוג הדיסק המתמשך pd-standard.

תזמון תאימות של אחסון ב-Autopilot

עבור עומסי עבודה שפועלים במצב אוטומטי (באשכולות Autopilot או באשכולות Standard שמשתמשים ב-ComputeClasses של Autopilot), פודים עם אחסון מתמיד מצורף מתוזמנים רק בסדרות מכונות תואמות:

• Persistent Disks מדור קודם: פודים שמשתמשים בדיסקים מדור קודם של pd-standard פועלים רק בסדרות מכונות שתומכות בהם, כמו צמתים של E2.
• Hyperdisk: פודים שמשתמשים באחסון מהדור הבא כמו hyperdisk-balanced פועלים בסדרות מכונות חדשות יותר, כמו צמתי C3.
• מצב בהמתנה: אם מגדירים באופן מפורש הפעלה של Pod בסדרת מכונות חדשה יותר (לדוגמה, באמצעות בוררי צמתים כדי לבקש צמתים מסוג C3, או באמצעות הגדרה של ComputeClass בהתאמה אישית), אבל מצרפים דיסק מדור קודם מסוג pd-standard, ה-Pod נשאר במצב Pending ללא הגבלת זמן. הסיבה לכך היא ש-GKE לא יכול למצוא צומת שעומד גם באילוצים של סוג המכונה וגם באילוצים של תאימות הדיסק. כשבוחרים במפורש סדרת מכונות, אתם אחראים לוודא את התאימות של PersistentVolume ושל הדיסק.

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

AttachVolume.Attach failed for volume "pvc-d7397693-5097-4a70-9df0-b10204611053" : rpc error: code = Internal desc = unknown Attach error: failed when waiting for zonal op: operation operation-1681408439910-5f93b68c8803d-6606e4ed-b96be2e7 failed (UNSUPPORTED_OPERATION): [pd-standard] features are not compatible for creating instance.

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

אם אתם משתמשים בסוג דיסק האחסון המתמיד pd-extreme, אתם צריכים לוודא שהדיסק מחובר למכונת VM עם צורה מתאימה. מידע נוסף זמין במאמר תמיכה בתצורות מכונה.

המאמרים הבאים

• איך משתמשים בהרחבת נפח האחסון
• איך משתמשים בתמונות מצב של אמצעי אחסון
• איך משתמשים בשיבוט נפח
• איך יוצרים דיסקים קשיחים אזוריים
• מידע נוסף על מנהל ההתקן ב-GitHub