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

אתם יכולים לפתור בעיות באחסון מתמיד ב-Google Distributed Cloud, כמו פודים שנתקעו במצב ContainerCreating או VolumeSnapshots שלא מוכנים אף פעם. במאמר הזה מוסבר איך לתקן כשלים בחיבור ובניתוק של אמצעי אחסון, איך לנקות אחרי אובדן של אמצעי אחסון ואיך לטפל בהרשאות של מנהל ההתקן של vSphere CSI, במגבלות של קובצי snapshot ובדרישות של גרסת ESXi.

אי אפשר לצרף את אמצעי האחסון

הבעיה הזו יכולה לקרות אם דיסק וירטואלי מחובר למכונה וירטואלית לא נכונה, ויכול להיות שהיא נובעת מבעיה מספר 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

בדוגמה הזו, Pod אחד או יותר תקועים במצב 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 שאליו הדיסק מחובר.

אם מופיעה הודעת השגיאה "not found" שקשורה לקובץ 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

פוד אחד או יותר תקועים במצב 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.

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

הפלט של 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

‫vSphere CSI VolumeSnapshot לא מוכן בגלל הגרסה

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

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

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

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

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

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

הפלט של 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)

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

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

    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_CLUSTER_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.

במאמר קבלת תמיכה תוכלו לקרוא מידע נוסף על מקורות המידע לתמיכה, כולל: