פתרון בעיות שקשורות לאחסון

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

החיבור של נפח האחסון נכשל

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

הפלט של gkectl diagnose cluster אמור להיראות כך:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors

בדוגמה הזו, אחד או יותר מ-Pods תקועים במצב ContainerCreating, ומוצגות אזהרות כמו בדוגמת הפלט הבאה:

Events:
  Type     Reason              Age               From                     Message
  ----     ------              ----              ----                     -------
  Warning  FailedAttachVolume  6s (x6 over 31s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.

אם דיסק וירטואלי מצורף למכונה וירטואלית לא נכונה, אפשר לבטל את הצירוף שלו באופן ידני באמצעות השלבים הבאים:

  1. הוצאת עומס מצומת. אפשר גם לכלול את הדגלים --ignore-daemonsets ו---delete-local-data בפקודה kubectl drain.

  2. מכבים את ה-VM.

  3. עורכים את הגדרות החומרה של המכונה הווירטואלית ב-vCenter כדי להסיר את אמצעי האחסון.

  4. מפעילים את ה-VM.

  5. ביטול ההגנה על הצומת.

עוצמת הקול נעלמת

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

אם מופיעה שגיאה מסוג 'לא נמצא' שקשורה לקובץ VMDK, סביר להניח שהדיסק הווירטואלי נמחק באופן סופי.

הפלט של gkectl diagnose cluster אמור להיראות כך:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors

אחד או יותר מ-Pods תקועים במצב ContainerCreating, כפי שמוצג בפלט לדוגמה הבא:

Events:
  Type     Reason              Age                   From                                    Message
  ----     ------              ----                  ----                                    -------
  Warning  FailedAttachVolume  71s (x28 over 42m)    attachdetach-controller                 AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
  kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found

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

כדי לפתור את הבעיה, אפשר לנקות באופן ידני משאבי Kubernetes שקשורים אליה:

  1. כדי למחוק את ה-PVC שהפנה אל ה-PV, מריצים את הפקודה kubectl delete pvc [PVC_NAME].

  2. כדי למחוק את ה-Pod שהייתה אליו הפניה ב-PVC, מריצים את הפקודה kubectl delete pod [POD_NAME].

  3. חוזרים על שלב 2 בגלל בעיה מספר 74374 ב-Kubernetes.

הניתוק של נפח האחסון של vSphere CSI נכשל

הבעיה הזו מתרחשת אם ההרשאה CNS > Searchable לא הוענקה למשתמש vSphere.

אם אתם רואים ש-Pods תקועים בשלב ContainerCreating עם אזהרות FailedAttachVolume, יכול להיות שהסיבה לכך היא ניתוק שנכשל בצומת אחר.

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

kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message

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

NAME                                                                   DETACH_ERROR
csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5   rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission
csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d   <none>
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c   <none>
csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8   <none>

כדי לפתור את הבעיה, צריך להוסיף את ההרשאה CNS > Searchable לחשבון המשתמש ב-vCenter. פעולת הניתוק מנסה שוב באופן אוטומטי עד שהיא מצליחה.

מנהל ההתקן vSphere CSI לא נתמך במארח ESXi

הבעיה הזו מתרחשת כשמארח ESXi באשכול vSphere מריץ גרסה נמוכה מ-ESXi 6.7U3.

הפלט של gkectl check-config כולל את האזהרה הבאה:

The vSphere CSI driver is not supported on current ESXi host versions.
CSI requires ESXi 6.7U3 or above. See logs for ESXi version details.

כדי לפתור את הבעיה, צריך לשדרג את מארחי ESXi לגרסה 6.7U3 ואילך.

יצירת נפח אחסון של CSI נכשלת עם השגיאה NotSupported

הבעיה הזו מתרחשת כשמארח ESXi באשכול vSphere מריץ גרסה נמוכה מ-ESXi 6.7U3.

הפלט של kubectl describe pvc כולל את השגיאה הבאה:

Failed to provision volume with StorageClass <standard-rwo>: rpc error:
code = Internal desc = Failed to create volume. Error: CnsFault error:
CNS: Failed to create disk.:Fault cause: vmodl.fault.NotSupported

כדי לפתור את הבעיה, צריך לשדרג את מארחי ESXi לגרסה 6.7U3 ואילך.

החיבור של נפח האחסון ב-vSphere CSI נכשל

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

הפלט של kubectl describe pod אמור להיראות כך:

Events:
 Type    Reason                 From                     Message
 ----    ------             ... ----                     -------
 Warning FailedAttachVolume ... attachdetach-controller  Multi-Attach error for volume
                                                         "pvc-xxxxx"
                                                         Volume is already exclusively attached to one
                                                         node and can't be attached to another

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

  1. שימו לב לשם של PersistentVolumeClaim ‏ (PVC) בפלט הקודם, ומחפשים את VolumeAttachments שמשויכים ל-PVC:

    kubectl get volumeattachments | grep pvc-xxxxx

    בדוגמה הבאה של פלט מוצגים השמות של VolumeAttachments:

    csi-yyyyy   csi.vsphere.vmware.com   pvc-xxxxx   node-zzzzz ...

  2. מתארים את VolumeAttachments:

    kubectl describe volumeattachments csi-yyyyy | grep "Deletion Timestamp"

    רושמים את חותמת הזמן של המחיקה, כמו בדוגמת הפלט הבאה:

    Deletion Timestamp:   2021-03-10T22:14:58Z

  3. מחכים עד לזמן שצוין בחותמת הזמן של המחיקה, ואז מבצעים מחיקה בכפייה של VolumeAttachment. כדי לעשות זאת, עורכים את האובייקט VolumeAttachment ומוחקים את ה-finalizer.

    kubectl edit volumeattachment csi-yyyyy

    מחיקת ה-finalizer:

    [...]
  Finalizers:
   external-attacher/csi-vsphere-vmware-com

התכונה VolumeSnapshot של vSphere CSI לא מוכנה בגלל הגרסה

הבעיה הזו מתרחשת כשהגרסה של vCenter Server או של מארח ESXi נמוכה מגרסה 7.0 Update 3.

הפלט של kubectl describe volumesnapshot כולל שגיאות כמו בדוגמה הבאה:

rpc error: code = Unimplemented desc = VC version does not support snapshot operations.

כדי לפתור את הבעיה הזו, צריך לשדרג את vCenter Server ואת המארחים של ESXi לגרסה 7.0 Update 3 ואילך.

‫vSphere CSI VolumeSnapshot לא מוכן, מספר התמונות המקסימלי לכל נפח

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

הפלט של kubectl describe volumesnapshot כולל את השגיאות כמו בדוגמה הבאה:

rpc error: code = FailedPrecondition desc = the number of snapshots on the source volume 5394aac1-bc0a-44e2-a519-1a46b187af7b reaches the configured maximum (3)

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

  1. מקבלים את השם של ה-Secret שמספק את הגדרות vSphere ל-vSphere CSI controller:

    kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> get deployment vsphere-csi-controller \
    --namespace <var class="edit">USER_CLUSTER_NAME</var> \
    --output json \
    | jq -r '.spec.template.spec.volumes[] \
    | select(.name=="vsphere-secret") .secret.secretName'

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

    • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין
    • ‫USER_CLUSTER_NAME: השם של אשכול המשתמשים

  2. מקבלים את הערך של data.config מהסוד, מבצעים פענוח בפורמט Base64 ושומרים אותו בקובץ בשם config.txt:

    kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> get secret <var class="edit">SECRET_NAME</var> \
    --namespace <var class="edit">USER_CLUSTER_NAME </var> \
    --output json | jq -r '.data["config"]' | base64 -d > config.txt

    מחליפים את SECRET_NAME בשם הסוד מהשלב הקודם.

  3. פתיחת config.txt לעריכה:

    עורכים או מוסיפים את השדה global-max-snapshots-per-block-volume בקטע [Snapshot], כמו בדוגמה הבאה:

    [Global]
cluster-id = "my-user-cluster"
insecure-flag = "0"
user = "my-account.local"
password = "fxqSD@SZTUIsG"
[VirtualCenter "my-vCenter"]
port = "443"
datacenters = "my-datacenter1"
[Snapshot]
global-max-snapshots-per-block-volume = 4

  4. מוחקים את הסוד ויוצרים אותו מחדש:

    kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> delete secret <var class="edit">SECRET_NAME</var> \
    --namespace <var class="edit">USER_CLUSTER_NAME</var>

kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> create secret generic <var class="edit">SECRET_NAME</var> \
    --namespace <var class="edit">USER_CLUSTER_NAME</var> \
    --from-file=config

  5. מפעילים מחדש את הפריסה של vsphere-csi-controller:

    kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> rollout restart deployment vsphere-csi-controller \
    --namespace <var class="edit">USER_CLUSTER_NAME</var>

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

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל: