Dieses Dokument enthält Hinweise zur Behebung von Speicherproblemen.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.Volume kann nicht angehängt werden
Dieses Problem kann auftreten, wenn ein virtuelles Laufwerk an die falsche virtuelle Maschine angehängt wird. Dies kann auf das Problem 32727 in Kubernetes 1.12 zurückzuführen sein.
Die Ausgabe von gkectl diagnose cluster
sieht in etwa so aus:
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
In diesem Beispiel hängen mindestens ein Pod im Status ContainerCreating
und es werden Warnungen wie in der folgenden Beispielausgabe angezeigt:
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'.
Wenn ein virtuelles Laufwerk mit der falschen virtuellen Maschine verbunden ist, können Sie es manuell trennen. Gehen Sie dazu so vor:
Knoten leeren Sie können die Flags
--ignore-daemonsets
und--delete-local-data
in den kubectl-Befehl einfügen.Entfernen Sie das Volume, indem Sie die VM-Hardwarekonfiguration in vCenter entsprechend bearbeiten.
Das Volume geht verloren
Dieses Problem kann auftreten, wenn ein virtuelles Laufwerk endgültig gelöscht wurde. Dies kann passieren, wenn ein Operator ein virtuelles Laufwerk oder die VM löscht, an die das Laufwerk angeschlossen ist.
Wenn der Fehler „not found“ für Ihre VMDK-Datei angezeigt wird, wurde das virtuelle Laufwerk wahrscheinlich endgültig gelöscht.
Die Ausgabe von gkectl diagnose cluster
sieht in etwa so aus:
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
Mindestens ein Pod hängt im Status ContainerCreating
fest, wie in der folgenden Beispielausgabe zu sehen:
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
Um dieses Problem zu vermeiden, verwalten Sie Ihre virtuellen Maschinen, wie unter Größe eines Nutzerclusters anpassen und Cluster aktualisieren beschrieben.
Zur Behebung dieses Problems können Sie zugehörige Kubernetes-Ressourcen manuell bereinigen:
Löschen Sie mit dem Befehl
kubectl delete pvc [PVC_NAME]
den PVC, der auf den PV verwiesen hat.Löschen Sie durch Ausführen von
kubectl delete pod [POD_NAME]
den Pod, der auf den PVC verwiesen hat.Wiederholen Sie Schritt 2 aufgrund des Kubernetes-Problems 74374.
vSphere-CSI-Volume kann nicht getrennt werden
Dieses Problem tritt auf, wenn die Berechtigung CNS > Searchable
dem vSphere-Nutzer nicht gewährt wurde.
Wenn Pods in der ContainerCreating
-Phase mit FailedAttachVolume
-Warnungen hängen, kann dies auf eine fehlgeschlagene Trennung auf einem anderen Knoten zurückzuführen sein.
Führen Sie den folgenden Befehl aus, um nach CSI-Trennfehlern zu suchen:
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.
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>
Fügen Sie Ihrem vCenter-Nutzerkonto die Berechtigung CNS > Searchable
hinzu, um dieses Problem zu beheben.
Der Trennvorgang wird automatisch wiederholt, bis er erfolgreich ist.
vSphere-CSI-Treiber wird auf dem ESXi-Host nicht unterstützt.
Dieses Problem tritt auf, wenn ein ESXi-Host im vSphere-Cluster eine niedrigere Version als ESXi 6.7U3 ausführt.
Die Ausgabe von gkectl check-config
enthält diese Warnung:
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.
Führen Sie zur Behebung dieses Problems ein Upgrade Ihrer ESXi-Hosts auf Version 6.7U3 oder höher durch.
Erstellen von CSI-Volumes schlägt mit dem Fehler NotSupported
fehl
Dieses Problem tritt auf, wenn ein ESXi-Host im vSphere-Cluster eine niedrigere Version als ESXi 6.7U3 ausführt.
Die Ausgabe von kubectl describe pvc
enthält den folgenden Fehler:
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
Führen Sie zur Behebung dieses Problems ein Upgrade Ihrer ESXi-Hosts auf Version 6.7U3 oder höher durch.
vSphere-CSI-Volume kann nicht angehängt werden
Dieses bekannte Kubernetes-Problem im Open-Source-vSphere-CSI-Treiber tritt auf, wenn ein Knoten heruntergefahren oder gelöscht wird oder fehlschlägt.
Die Ausgabe von kubectl describe pod
sieht so aus:
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
So beheben Sie das Problem:
Notieren Sie sich den Namen des PersistentVolumeClaim (PVC) in der vorherigen Ausgabe und suchen Sie die VolumeAttachments, die dem PVC zugeordnet sind:
kubectl get volumeattachments | grep pvc-xxxxx
Die folgende Beispielausgabe zeigt die Namen der VolumeAttachments:
csi-yyyyy csi.vsphere.vmware.com pvc-xxxxx node-zzzzz ...
Beschreiben Sie die VolumeAttachments:
kubectl describe volumeattachments csi-yyyyy | grep "Deletion Timestamp"
Notieren Sie sich den Löschzeitstempel, wie in der folgenden Beispielausgabe:
Deletion Timestamp: 2021-03-10T22:14:58Z
Warten Sie, bis die durch den Zeitstempel angegebene Zeit erreicht ist, und erzwingen Sie dann das Löschen des VolumeAttachment. Bearbeiten Sie dazu das VolumeAttachment-Objekt und löschen Sie den Finalizer.
kubectl edit volumeattachment csi-yyyyy
Löschen Sie den Finalizer:
[...] Finalizers: external-attacher/csi-vsphere-vmware-com
vSphere CSI VolumeSnapshot aufgrund der Version nicht verfügbar
Dieses Problem tritt auf, wenn die Version von vCenter Server oder des ESXi-Hosts niedriger als 7.0 Update 3 ist.
Die Ausgabe von kubectl describe volumesnapshot
enthält Fehler wie im folgenden Beispiel:
rpc error: code = Unimplemented desc = VC version does not support snapshot operations.
Führen Sie zur Behebung dieses Problems ein Upgrade von vCenter Server und den ESXi-Hosts auf Version 7.0 Update 3 oder höher durch.
vSphere CSI VolumeSnapshot nicht bereit, maximale Anzahl von Snapshots pro Volume
Dieses Problem tritt auf, wenn die Anzahl der Snapshots pro Volume den maximalen Wert für den vSphere Container Storage-Treiber erreicht. Der Standardwert ist drei.
Die Ausgabe von kubectl describe volumesnapshot
enthält Fehler wie im folgenden Beispiel:
rpc error: code = FailedPrecondition desc = the number of snapshots on the source volume 5394aac1-bc0a-44e2-a519-1a46b187af7b reaches the configured maximum (3)
Führen Sie die folgenden Schritte aus, um die maximale Anzahl von Snapshots pro Volume zu aktualisieren:
Rufen Sie den Namen des Secrets ab, das die vSphere-Konfiguration an den vSphere CSI-Controller weitergibt:
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'
Ersetzen Sie Folgendes:
- ADMIN_KUBECONFIG: Pfad der Datei "kubeconfig" Ihres Administratorclusters
- USER_CLUSTER_NAME: der Name Ihres Nutzerclusters
Rufen Sie den Wert von
data.config
aus dem Secret ab, decodieren Sie ihn mit base64 und speichern Sie ihn in einer Datei mit dem Namenconfig.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
Ersetzen Sie SECRET_NAME durch den Namen des Secrets aus dem vorherigen Schritt.
Öffnen Sie
config.txt
zum Bearbeiten:Bearbeiten oder fügen Sie das Feld
global-max-snapshots-per-block-volume
im Abschnitt[Snapshot]
hinzu, wie im folgenden Beispiel:[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
Löschen Sie das Secret und erstellen Sie es neu:
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
Starten Sie das Deployment
vsphere-csi-controller
neu:kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> rollout restart deployment vsphere-csi-controller \ --namespace <var class="edit">USER_CLUSTER_NAME</var>