Contêiner de pod de armazenamento CSN preso em ContainerCreating

  • Artigo

Este documento detalha a experiência do usuário em relação a um problema raro que pode deixar os pods de armazenamento CSN no estado ContainerCreating. Ele também fornece uma solução alternativa para resolver o problema.

Causa

Uma atualização do runtime substitui o sistema operacional dos nós Baremetal, que recria o IQN (nome qualificado iSCSI) e pode causar uma falha de logon iscsi em raras ocasiões. A falha iscsi ocorre em nós específicos em que o logon dos portais não é bem-sucedido. Este guia fornece uma solução para esse problema específico.

O guia apresenta brevemente o processo para excluir Volumeattachment e reiniciar o pod para resolver o problema.

Processar

Verifique por que o pod permanece no estado ContainerCreating:

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

Aqui nos concentramos apenas em baremetal_machine em que o problema ocorreu.

Execute o comando de execução a seguir para resolver o problema do pod preso no containerCreating

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="

O comando executar executa o script a seguir.

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

O comando recupera o pvc do pod e exclui o objeto volumeattachment. Em seguida, ele exclui o pod. Posteriormente, o pod é recriado em outro nó junto com um objeto de anexo de volume bem-sucedido.

Se você ainda tiver dúvidas, entre em contato com o suporte. Para obter mais informações sobre planos de suporte, veja Planos de Suporte do Azure.