CSN-Speicher-Pod-Container blieb in ContainerCreating
hängen
In diesem Dokument wird die Benutzererfahrung eines seltenen Problems erläutert, wo die CSN-Speicher-Pods im ContainerCreating
Zustand gerendert werden können. Dazu gibt es auch eine Problemumgehung zur Problembehebung.
Ursache
Ein Laufzeitupgrade ersetzt das Betriebssystem der Baremetal-Knoten, das den IQN (iSCSI Qualified Name) neu erstellt und in seltenen Fällen einen iSCSI-Anmeldefehler verursachen kann. Der iscsi-Fehler tritt auf bestimmten Knoten auf, bei denen die Portalanmeldung nicht erfolgreich ist. Diese Anleitung bietet eine Lösung für dieses besondere Problem.
In der Anleitung wird der Vorgang zum Löschen von Volumeattachment kurz beschrieben. Zur Problembehebung wird d der Pod wird neu gestartet.
Prozess
Überprüfen Sie, warum der Pod im ContainerCreating
Zustand bleibt:
Warning FailedMapVolume 52s (x19 over 23m) kubelet MapVolume.SetUpDevice failed for volume "pvc-b38dcc54-5e57-435a-88a0-f91eac594e18" : rpc error: code = Internal desc = required at least 2 portals but found 0 portals
Hier konzentrieren wir uns nur auf den Ort baremetal_machine
, wo das Problem aufgetreten ist.
Führen Sie folgenden Ausführungsbefehl aus, um das Problem des in containerCreating hängen gebliebenen Pods zu beheben
az networkcloud baremetalmachine run-command --bare-metal-machine-name <control-plane-baremetal-machine> \
--subscription <subscription> \
--resource-group <cluster-managed-resource-group> \
--limit-time-seconds 60 \
--script "cG9kcz0kKGt1YmVjdGwgZ2V0IHBvZHMgLW4gbmMtc3lzdGVtIHxncmVwIC1pIGNvbnRhaW5lcmNyZWF0aW5nIHwgYXdrICd7cHJpbnQgJDF9JykKCmZvciBwb2RuYW1lIGluICRwb2RzOyBkbwogICAga3ViZWN0bCBkZXNjcmliZSBwbyAkcG9kbmFtZSAtbiBuYy1zeXN0ZW0KCiAgICBwdmNuYW1lPSQoa3ViZWN0bCBnZXQgcG8gJHBvZG5hbWUgLW4gbmMtc3lzdGVtIC1vIGpzb24gfCBqcSAtciAnLnNwZWMudm9sdW1lc1swXS5wZXJzaXN0ZW50Vm9sdW1lQ2xhaW0uY2xhaW1OYW1lJykKCiAgICBwdm5hbWU9JChrdWJlY3RsIGdldCBwdmMgJHB2Y25hbWUgLW4gbmMtc3lzdGVtIC1vIGpzb24gfCBqcSAtciAnLnNwZWMudm9sdW1lTmFtZScpCgogICAgbm9kZW5hbWU9JChrdWJlY3RsIGdldCBwbyAkcG9kbmFtZSAtbiBuYy1zeXN0ZW0gLW9qc29uIHwganEgLXIgJy5zcGVjLm5vZGVOYW1lJykKCiAgICB2b2xhdHRhY2hOYW1lPSQoa3ViZWN0bCBnZXQgdm9sdW1lYXR0YWNobWVudCB8IGdyZXAgLWkgJHB2bmFtZSB8IGF3ayAne3ByaW50ICQxfScpCgogICAga3ViZWN0bCBkZWxldGUgdm9sdW1lYXR0YWNobWVudCAkdm9sYXR0YWNoTmFtZQoKICAgIGt1YmVjdGwgY29yZG9uICRub2RlbmFtZSAtbiBuYy1zeXN0ZW07a3ViZWN0bCBkZWxldGUgcG8gLW4gbmMtc3lzdGVtICRwb2RuYW1lCmRvbmU="
Der Ausführungsbefehl führt das folgende Skript aus.
pods=$(kubectl get pods -n nc-system |grep -i containercreating | awk '{print $1}')
for podname in $pods; do
kubectl describe po $podname -n nc-system
pvcname=$(kubectl get po $podname -n nc-system -o json | jq -r '.spec.volumes[0].persistentVolumeClaim.claimName')
pvname=$(kubectl get pvc $pvcname -n nc-system -o json | jq -r '.spec.volumeName')
nodename=$(kubectl get po $podname -n nc-system -ojson | jq -r '.spec.nodeName')
volattachName=$(kubectl get volumeattachment | grep -i $pvname | awk '{print $1}')
kubectl delete volumeattachment $volattachName
kubectl cordon $nodename -n nc-system;kubectl delete po -n nc-system $podname
done
Der Befehl ruft das PVC vom Pod ab und löscht dann das Objekt volumeattachment
. Anschließend wird der Pod gelöscht. Der Pod wird später zusammen mit einem erfolgreichen Volumeanlageobjekt auf einem anderen Knoten neu erstellt.
Sollten Sie weitere Fragen haben, wenden Sie sich an den Support. Weitere Informationen zu Supportplänen finden Sie unter Azure-Supportpläne.