Container Service for Kubernetes:Disk volume FAQ

Falha na criação dinâmica de PV: InvalidDataDiskCatagory.NotSupported

Sintoma

A criação do PV falha, e um evento de PVC exibe a mensagem de erro InvalidDataDiskCategory.NotSupported.

Causa

O StorageClass especifica um tipo de disco em cloud indisponível na zona atual ou com estoque insuficiente.

Solução

• Atualize o plug-in CSI e utilize o StorageClass alicloud-disk-topology-alltype, ou crie um StorageClass personalizado com múltiplos tipos de disco em cloud. Consulte Use a dynamically provisioned disk volume.

• Adicione múltiplas zonas ao cluster. Consulte High-availability configuration recommendations for disk volumes.

Falha na criação dinâmica de PV: Estoque insuficiente na AZone

Sintoma

A criação do PV falha, e um evento de PVC exibe a mensagem de erro The specified AZone inventory is insufficient.

Causa

A criação do disco em cloud falha por estoque insuficiente na zona especificada.

Solução

• Atualize o plug-in CSI e utilize o StorageClass alicloud-disk-topology-alltype, ou crie um StorageClass personalizado com múltiplos tipos de disco em cloud. Consulte Use a dynamically provisioned disk volume.

• Adicione múltiplas zonas ao cluster. Consulte High-availability configuration recommendations for disk volumes.

Falha na criação dinâmica de PV: Tamanho de disco não suportado

Sintoma

A criação dinâmica de PV falha, e um evento de PVC exibe a mensagem de erro disk size is not supported.

Causa

O PVC especifica uma capacidade inválida. Os limites mínimos variam conforme cloud disk type.

Solução

Ajuste a capacidade declarada no PVC para um valor suportado.

Falha na criação dinâmica de PV: Aguardando primeiro consumidor

Sintoma

A criação do PV falha ao usar um StorageClass com o modo de vinculação WaitForFirstConsumer, e um evento de PVC exibe a mensagem de erro persistentvolume-controller waiting for first consumer to be created before binding.

Causa

O PVC não detectou o nó ao qual o pod foi agendado.

• Se você definiu explicitamente nodeName no YAML da aplicação, o pod ignora o scheduler. Isso impede que o PVC descubra o nó, tornando-o incompatível com o modo de vinculação WaitForFirstConsumer.

• Nenhum pod está referenciando o PVC atual.

Solução

• Remova o campo nodeName do arquivo YAML da aplicação e adote um método de agendamento diferente.

• Crie um pod que utilize o PVC atual.

Falha na criação dinâmica de PV: Nenhuma topology key no CSINode

Sintoma

A criação do PV falha, e um evento de PVC exibe a mensagem de erro no topology key found on CSINode node-XXXX.

Causa

• Causa 1: O plug-in CSI no nó correspondente node-XXXX falhou ao iniciar.

• Causa 2: Um driver não suportado pelo sistema está sendo usado para montagem. Por padrão, o sistema suporta os drivers Disk, NAS e OSS.

Solução

1. Verifique o status do pod.

   kubectl get pods -n kube-system -o wide | grep node-XXXX

   • Status anormal: consulte os logs de erro com kubectl logs csi-plugin-xxxx -nkube-system -c csi-plugin. Isso geralmente é causado por conflito de porta no nó. Resolva da seguinte forma:

     • Encerre o processo que está ocupando a porta.

     • Adicione a variável de ambiente SERVICE_PORT ao plug-in CSI para especificar uma nova porta.

       kubectl set env -n kube-system daemonset/csi-plugin --containers="csi-plugin" SERVICE_PORT="XXX"

   • Se o status estiver normal, prossiga para o próximo passo.

2. Utilize um driver padrão do sistema, como Disk, NAS ou OSS. Consulte a documentação de Storage.

Falha na criação dinâmica de PV: selfLink was empty

Sintoma

A criação do PV falha, e um evento de PVC exibe a mensagem de erro selfLink was empty, can't make reference.

Causa

1. A versão do cluster e a versão do plug-in CSI são incompatíveis.

2. O cluster utiliza o plug-in de armazenamento FlexVolume.

Solução

1. Atualize a versão do plug-in CSI. A versão do plug-in deve ser compatível com a versão do cluster. Por exemplo, um cluster Kubernetes 1.20 requer CSI versão 1.20 ou superior.

2. Se o cluster utiliza o plug-in de armazenamento FlexVolume, consulte Migrate from FlexVolume to CSI.

Falha na criação dinâmica de PV: Capacidade do PVC < 20 GiB

Os StorageClasses padrão do ACK (por exemplo, alicloud-disk-topology-alltype, alicloud-disk-essd) exigem capacidade mínima de 20 GiB. Para volumes menores, crie um StorageClass personalizado com um tipo de disco que suporte capacidades inferiores, como ESSD AutoPL ou ESSD PL0.

• Consulte Use a dynamically provisioned disk volume.

• Para os intervalos de capacidade por tipo de disco, consulte Block storage performance.

Falha na inicialização do pod: Conflito de afinidade de nó do volume

Sintoma

Um pod com disco em cloud montado falha ao iniciar, e um evento de pod exibe a mensagem de erro had volume node affinity conflict.

Causa

Todo PV possui uma propriedade nodeaffinity. Esse erro ocorre quando a nodeaffinity do PV conflita com a nodeaffinity do pod, impedindo o agendamento.

Solução

Garanta que a nodeaffinity do PV e a nodeaffinity do pod sejam consistentes.

Falha na inicialização do pod: Disco não encontrado

Sintoma

Um pod com disco em cloud montado falha ao iniciar, e um evento de pod exibe a mensagem de erro can't find disk.

Causa

• O PV foi configurado com um ID de disco em cloud incorreto ou com um ID de disco de outra região.

• A conta não tem permissão para acessar o disco em cloud, possivelmente porque ele pertence a outra conta.

Solução

• Se estiver usando um disco em cloud provisionado estaticamente, verifique se ele atende aos seguintes requisitos:

  • A região do disco em cloud é a mesma região do cluster.

  • O ID do disco em cloud está correto.

  • O disco em cloud e o cluster pertencem à mesma conta Alibaba Cloud.

• Se o disco em cloud for montado dinamicamente, verifique as permissões do plug-in CSI.

  Verifique se existe um Addon Token no cluster.

  • Se existir um Addon Token, verifique a versão do plug-in CSI no cluster, atualize-o para a versão mais recente e tente novamente.

  • Se não existir um Addon Token, o AccessKey personalizado da função RAM worker do nó é usado por padrão. Verifique as permissões da política RAM correspondente.

Falha na inicialização do pod: Ação de anexação em andamento

Sintoma

Um pod com disco em cloud montado exibe Previous attach action is still in process, mas inicia com sucesso após alguns segundos.

Causa

Instâncias ECS anexam um disco em cloud por vez. Quando múltiplos pods que usam disco são agendados no mesmo host, os discos são anexados sequencialmente. Essa mensagem indica que outra anexação está em andamento.

Solução

Nenhuma ação necessária. O sistema realiza novas tentativas automaticamente.

Falha na inicialização do pod: InvalidInstanceType.NotSupportDiskCategory

Sintoma

Ao iniciar um pod com um disco em cloud montado, a mensagem de erro InvalidInstanceType.NotSupportDiskCategory é exibida.

Causa

O pod foi agendado para um nó ECS cujo tipo de instância não suporta esse tipo de disco em cloud.

Solução

Tente uma das seguintes opções:

• Verifique se o cluster possui um nó ECS com tipo de instância que suporte esse disco em cloud e se o pod pode ser agendado nele.

• Se nenhum tipo de instância de nó suportar esse disco em cloud, mude para um tipo de disco compatível.

Falha na inicialização do pod: Driver CSI não registrado

Sintoma

Ao iniciar um pod, o seguinte aviso é exibido.

Warning  FailedMount       98s (x9 over 3m45s)  kubelet, cn-zhangjiakou.172.20.XX.XX  MountVolume.MountDevice failed for volume "d-xxxxxxx" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name diskplugin.csi.alibabacloud.com not found in the list of registered CSI drivers

Causa

• Geralmente ocorre em nós recém-adicionados, quando o pod de aplicação tenta montar um volume antes de o plug-in CSI — que está iniciando em paralelo — concluir seu registro.

• O plug-in CSI no nó falhou ao se registrar, possivelmente devido a uma falha na inicialização.

Solução

• Em nós recém-adicionados, nenhuma ação é necessária. O sistema realiza novas tentativas automaticamente.

• Se o plug-in CSI falhar ao se registrar, verifique seu status e logs. Se o plug-in estiver normal, entre no grupo de usuários DingTalk (ID: 35532895) para obter assistência.

Falha na inicialização do pod: Erro Multi-Attach

Sintoma

Um pod que monta um disco em cloud exibe warning failedAttachVolume xxx xxx Multi-Attach error for volume "xxx" nos eventos. Ao executar kubectl describe pvc <pvc-name>, são identificados múltiplos pods referenciando o mesmo PVC.

Causa

• Causa 1: Sem multi-attach ativado, um disco em cloud só pode ser montado em um único pod.

• Causa 2: O pod que usava o PVC foi excluído, mas o disco em cloud não foi desmontado corretamente.

  No ECS console, localize o nó ao qual o disco em cloud do PVC está anexado. Verifique os logs do pod do plug-in CSI nesse nó. Se aparecer Path is mounted, no remove: /var/lib/kubelet/plugins/kubernetes.io/csi/diskplugin.csi.alibabacloud.com/xxx/globalmount, confirme se o plug-in CSI monta diretamente o HostPath /var/run:

  kubectl get ds -n kube-system csi-plugin -ojsonpath='{.spec.template.spec.volumes[?(@.hostPath.path=="/var/run/")]}'

  Uma saída não vazia confirma o problema.

Solução

• Solução para a Causa 1:

  Garanta que apenas um pod referencie o PVC.

• Solução para a Causa 2:

  Aplique manualmente o patch no arquivo YAML do plug-in CSI:

  kubectl patch -n kube-system daemonset csi-plugin -p '
  spec:
    template:
      spec:
        containers:
          - name: csi-plugin
            volumeMounts:
              - mountPath: /host/var/run/efc
                name: efc-metrics-dir
              - mountPath: /host/var/run/ossfs
                name: ossfs-metrics-dir
              - mountPath: /host/var/run/
                $patch: delete
        volumes:
          - name: ossfs-metrics-dir
            hostPath:
              path: /var/run/ossfs
              type: DirectoryOrCreate
          - name: efc-metrics-dir
            hostPath:
              path: /var/run/efc
              type: DirectoryOrCreate
          - name: fuse-metrics-dir
            $patch: delete'

Falha na inicialização do pod: Timeout de montagem

Sintoma

Ao iniciar um pod com volume montado, um evento de pod exibe a mensagem de erro Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition.

Causa

Esse evento é uma mensagem de erro reportada pelo kubelet. O kubelet verifica periodicamente se os volumes usados pelos pods em todos os nós estão com status Ready. Se um volume não estiver Ready, a mensagem de erro acima é exibida.

Esse evento indica que a montagem estava incompleta no momento da verificação. As possíveis causas são:

• Causa 1: Ocorreu um erro de montagem, mas o evento detalhado foi sobrescrito. Apenas o evento de erro do kubelet permanece.

• Causa 2: O kubelet excedeu o tempo ao recuperar o configmap/serviceaccount defaulttoken. Trata-se de um problema de rede no nó. É necessário tentar novamente em outro nó.

• Causa 3: Quando securityContext.fsGroup está definido, o kubelet altera recursivamente a propriedade de todos os arquivos durante a montagem. Esse processo é lento para volumes com muitos arquivos.

• Causa 4: Para volumes provisionados estaticamente, verifique se o campo driver está correto (sem erros de digitação). Um nome de driver incorreto impede que o volume alcance o status Ready.

Solução

• Solução para a Causa 1: Reinicie o pod excluindo-o. Localize e diagnostique o evento de erro real.

• Solução para a Causa 2: Reagende o pod para outro nó. Consulte Schedule an application to a specified node.

• Solução para a Causa 3: Em clusters versão 1.20+, defina fsGroupChangePolicy como OnRootMismatch. Isso restringe as alterações recursivas de propriedade apenas à primeira montagem quando as permissões do diretório raiz forem diferentes, normalizando o tempo de montagem em reinicializações subsequentes do pod. Para mais informações sobre o parâmetro fsGroupChangePolicy, consulte Configure a Security Context for a Pod or Container. Se insuficiente, utilize um initContainer para os ajustes de permissão.

• Solução para a Causa 4: Verifique e especifique o nome correto do driver. Exemplos:

  • diskplugin.csi.alibabacloud.com

  • nasplugin.csi.alibabacloud.com

  • ossplugin.csi.alibabacloud.com

Falha na inicialização do pod: Formato de dispositivo inválido para NVMe

Sintoma

Um pod com disco em cloud montado falha ao iniciar, e um evento de pod exibe a mensagem de erro validate error Device /dev/nvme1n1 has error format more than one digit locations.

Causa

O nó é de um tipo de instância baseado em NVMe (como g7se, r7se, c7se ou qualquer ECS de 8ª geração), mas as versões do cluster e do plug-in CSI são antigas demais para suportá-lo.

Solução

Garanta que o cluster ACK esteja na versão 1.20+ e atualize o plug-in CSI para v1.22.9-30eb0ee5-aliyun ou superior. Consulte Manage components.

Falha na inicialização do pod: Conflito de tarefa ECS

Sintoma

Um pod com disco em cloud montado falha ao iniciar, e um evento de pod exibe a mensagem de erro ecs task is conflicted.

Causa

Algumas tarefas ECS devem ser executadas em sequência. Quando múltiplas solicitações são enviadas ao ECS simultaneamente, ocorre um erro de conflito de tarefa ECS.

Solução

Opções disponíveis:

• Aguarde o plug-in CSI realizar novas tentativas automaticamente. Após a conclusão das demais tarefas ECS, a montagem é concluída com sucesso.

• Consulte Enable parallel attachment of cloud disks.

Falha na inicialização do pod: Sistema de arquivos corrompido

Sintoma

Um pod com disco em cloud montado falha ao iniciar, e um evento de pod exibe a seguinte mensagem de erro.

wrong fs type, bad option, bad superblock on /dev/xxxxx  missing codepage or helper program, or other error

Causa

O disco em cloud não pode ser montado porque seu sistema de arquivos está corrompido.

Solução

Geralmente causado por uma desmontagem inadequada. Para resolver:

1. Verifique se a aplicação atende aos seguintes requisitos:

   • No máximo um pod está montando o mesmo disco em cloud.

   • Não escreva dados durante o processo de desanexação do disco.

2. Faça login no host do pod e execute fsck -y /dev/xxxxx para reparar o sistema de arquivos.

   Substitua /dev/xxxxx pelo caminho do dispositivo exibido no evento do pod. O reparo modifica os metadados do sistema de arquivos. Se o reparo falhar, o sistema de arquivos ficará permanentemente corrompido.

Falha na inicialização do pod: Limite máximo de volumes excedido

Sintoma

Um pod com disco em cloud montado permanece em Pending e não pode ser agendado, mesmo que o tipo de instância ECS permita mais anexações de disco:

0/1 nodes are available: 1 node(s) exceed max volume count.

Causa

O agendamento é limitado pela variável de ambiente MAX_VOLUMES_PERNODE.

Falha na inicialização do pod: Limite de discos da instância atingido

Sintoma

Um pod com disco em cloud montado permanece em ContainerCreating. Evento do pod:

MountVolume.MountDevice failed for volume "d-xxxx" : rpc error: code = Aborted desc = NodeStageVolume: Attach volume: d-xxxx with error: rpc error: code = Internal desc = SDK.ServerError
ErrorCode: InstanceDiskLimitExceeded
Message: The amount of the disk on instance in question reach its limits

Causa

O valor da variável de ambiente MAX_VOLUMES_PERNODE está muito alto.

Erro OperationDenied.HpnZoneMismatch em nós Lingjun

O disco em cloud não possui a tag attachToHpnZone:XX exigida para o nó Lingjun. Essa tag só pode ser adicionada no momento da criação do disco. Crie um novo disco em cloud com a tag.

1. Acesse ECS console - Block Storage - Disks.

2. Adicione as seguintes tags durante a criação (não é possível adicioná-las posteriormente):

   • createdByProduct:eflo

   • attachToHpnZone:XX (Substitua XX pelo valor real de HpnZone. Execute um comando para query nodes e obtenha o HpnZone.)

   Consulte Create an empty data disk.

3. Exclua o PV e o PVC antigos e crie novos com o disco em cloud substituto. Consulte Use a statically provisioned disk volume ou Use a dynamically provisioned disk volume.

Alterar a configuração padrão do StorageClass

O StorageClass padrão não pode ser alterado.

Após a instalação do csi-provisioner, um StorageClass padrão (por exemplo, alicloud-disk-topology-alltype) é criado. Não modifique os StorageClasses padrão. Create a new StorageClass com o tipo de volume ou política de recuperação de sua preferência.

Usar um único disk volume para múltiplas aplicações

Discos em cloud oferecem armazenamento não compartilhado. Sem multi-attach ativado, um disco em cloud só pode ser montado em um único pod. Consulte Enable NVMe-based multi-attach for cloud disks and configure reservations.

Erro de I/O da aplicação no volume de disco

Sintoma

O disco em cloud monta normalmente e a aplicação inicia, mas logo em seguida reporta um input/output error.

Causa

O disco em cloud utilizado pela aplicação foi desanexado ou excluído.

Solução

Verifique o status do disco em cloud e tome as medidas adequadas conforme o status.

1. Identifique o PVC a partir da definição de VolumeMount do pod para o diretório de montagem afetado.

2. Execute kubectl get pvc <pvc-name> para verificar o status do PVC e anote o PV vinculado.

3. Obtenha o ID do disco em cloud a partir do campo volumeHandle no YAML do PV.

4. Na página EBS do console do ECS, verifique o status do disco em cloud com base no ID do disco.

   • Se o disco em cloud estiver Available, ele foi desmontado. Reinicie o pod para remontá-lo.

     Nota

     O pod está em execução, o que significa que o disco foi montado e depois desmontado — provavelmente porque vários pods referenciam o mesmo disco. Execute kubectl describe pvc <pvc-name> e verifique o campo UsedBy para confirmar.

   • Se o disco em cloud não for encontrado, ele foi liberado e não pode ser recuperado.

     Importante

     Ao montar um ESSD, use snapshots automáticos para proteger os dados do volume de disco. Consulte Data loss due to unexpected cloud disk deletion.

Definir permissões de usuário para o diretório de montagem

Não é possível definir permissões de acesso de usuário para discos em cloud. Caso seja necessário definir permissões de acesso de usuário para um diretório de montagem, configure o securityContext do pod ao criar a aplicação para modificar as permissões. Para mais informações, consulte Configure Volume Permission and Ownership Change Policy for Pods.

Expansão automática de volume de disco

Volumes de disco não se expandem automaticamente. Para expandir, atualize a capacidade de armazenamento do PVC. Consulte Online expansion of disk volumes.

Para ativar a expansão automática, use um CRD para expandir os volumes quando o uso ultrapassar um limiar. Consulte Configure automatic expansion.

Falha na expansão do disco: Aguardando reinicialização do pod pelo usuário

Sintoma

Após atualizar a capacidade de armazenamento do PVC, o campo StorageCapacity no status do PVC não é alterado e o evento do PVC reporta:

 Waiting for user to (re-)start a pod to finish file system resize of volume on node.

Causa

A expansão do disco em cloud ocorre em duas etapas: expansão da capacidade do disco via API ResizeDisk e, em seguida, expansão do sistema de arquivos. Esse erro indica que a primeira etapa foi concluída com sucesso, mas a segunda falhou, o que aponta para um problema no nó.

Solução

Determine o tipo do nó atual.

• Se o nó for ECI, execute kubectl get configmap -n kube-system eci-profile -o jsonpath="{.data.enablePVCController}" e verifique se o valor é true. Consulte eci-profile configuration parameters.

  Se o problema persistir, abra um chamado para obter assistência.

• Se o nó for ECS, execute kubectl get pods -n kube-system -l app=csi-plugin --field-selector=spec.nodeName=<node-name> para verificar o status do plug-in CSI.

  • Se o plug-in CSI estiver normal, entre no grupo de usuários DingTalk (ID: 35532895) para obter assistência.

  • Se estiver com problema, reinicie o pod do plug-in CSI e tente novamente. Se o problema persistir, entre no grupo de usuários DingTalk (ID: 35532895) para obter assistência.

Falha na expansão do disco: PVC estático ou redimensionamento não permitido

Sintoma

Após atualizar a capacidade de armazenamento do PVC, o seguinte erro é reportado:

only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize 

Causa

• Causa 1: O PVC e o PV do volume de disco foram criados manualmente de forma estática. O parâmetro storageClassName no PVC não foi especificado, ou não existe nenhuma StorageClass com o nome especificado no cluster.

• Causa 2: Na StorageClass referenciada pelo PVC, o parâmetro allowVolumeExpansion está definido como false. A expansão não é compatível.

Solução

• Solução para a Causa 1: Verifique a configuração de storageClassName do PVC e certifique-se de que existe uma StorageClass com o mesmo nome no cluster. Caso contrário, crie uma StorageClass correspondente com base nas propriedades do volume de disco existente e configure allowVolumeExpansion: true.

• Solução para a Causa 2: StorageClasses são imutáveis. Crie uma nova StorageClass com o parâmetro allowVolumeExpansion definido como true. Em seguida, modifique o PVC para referenciar a nova StorageClass antes de expandi-lo.

Falha na exclusão do pod: Disco não portátil

Sintoma

Ao desmontar um disco em cloud, a mensagem de erro The specified disk is not a portable disk é exibida.

Causa

O método de faturamento do disco em cloud é por assinatura. Isso pode ocorrer pela aquisição de um disco com assinatura ou pela conversão do método de faturamento durante a atualização de uma instância ECS.

Solução

Altere o método de faturamento do disco em cloud para pagamento conforme o uso.

Falha na exclusão do pod: Desmontagem falha devido a um pod órfão

Sintoma

A desmontagem de um pod falha e os logs do kubelet mostram um pod órfão não gerenciado pelo ACK.

Causa

O pod foi encerrado de forma anormal, deixando um ponto de montagem de volume órfão. Em versões do Kubernetes anteriores à 1.22, o GC de volumes do kubelet era incompleto, exigindo limpeza manual.

Solução

Execute o script a seguir no nó com problema para limpar os pontos de montagem com falha.

wget https://raw.githubusercontent.com/AliyunContainerService/kubernetes-issues-solution/master/kubelet/kubelet.sh
sh kubelet.sh

Falha na reinicialização do pod: Falha de montagem irrecuperável

Sintoma

Após a exclusão, o pod não consegue reiniciar e reporta uma falha de montagem irrecuperável:

Warning FailedMount 9m53s (x23 over 40m) kubelet MountVolume.SetUp failed for volume “xxxxx” : rpc error: code = Internal desc = stat /var/lib/kubelet/plugins/kubernetes.io/csi/pv/xxxxx/globalmount: no such file or directory

Escopo

• A versão do cluster ACK é 1.20.4-aliyun-1.

• A aplicação usa um disco em cloud como meio de armazenamento.

• Um StatefulSet é utilizado e a propriedade podManagementPolicy: "Parallel" está definida.

Causa

Consulte Pod fails to start after restarting rapidly.

Solução

• Adicione novos nós e remova os antigos. O pod com falha se recupera automaticamente. Consulte Create and manage node pools e Remove a node.

• Altere o podManagementPolicy do StatefulSet para OrderedReady ou remova o campo podManagementPolicy: "Parallel".

• Para clusters pequenos:

  1. Marque o nó do pod como não agendável com cordon.

  2. Exclua o pod e aguarde até que seu status se torne Pending.

  3. Remova o cordon do nó e aguarde o pod reiniciar.

• Em clusters grandes, o pod se recupera assim que for agendado em um nó diferente.

Falha na exclusão do pod: Destino ocupado

Sintoma

Ao excluir um pod, o evento do pod ou o log do kubelet (/var/log/messages) exibe:

unmount failed, output <mount-path> target is busy

Causa

Um processo ainda está usando o dispositivo. Acesse o host para identificar e encerrar o processo.

Solução

1. Localize o dispositivo de bloco no caminho de montagem correspondente.

   mount | grep <mount-path>
   /dev/vdtest <mount-path>

2. Identifique o ID do processo que está usando o dispositivo de bloco.

   fuser -m /dev/vdtest

3. Encerre o processo.

   O disco em cloud é desmontado automaticamente após o encerramento do processo.

Disco em cloud permanece após exclusão do PVC

Sintoma

Um PVC é excluído, mas o disco em cloud permanece no console do ECS.

Causa

• Causa 1: O reclaimPolicy do PV é Retain, portanto o PV e o disco em cloud persistem após a exclusão do PVC.

• Causa 2: O PVC e o PV são excluídos ao mesmo tempo, ou o PV é excluído antes do PVC.

Solução

• Solução para a Causa 1: Com o reclaimPolicy definido como Retain, o CSI não exclui o PV nem o disco em cloud quando o PVC é excluído. Exclua-os manualmente.

• Solução para a Causa 2: Se um PV tiver uma deleteTimestamp annotation, o CSI não irá reclamar o disco em cloud. Consulte controller. Exclua o PVC — o PV vinculado é limpo automaticamente.

PVC permanece após exclusão

Sintoma

A exclusão do PVC falha mesmo com o flag --force.

Causa

Um pod ainda usa o PVC, portanto o finalizer impede a exclusão.

Solução

1. Visualize os pods que estão referenciando o PVC.

   kubectl describe pvc <pvc-name> -n kube-system

2. Confirme que o pod referenciado não está mais em uso, exclua-o e tente excluir o PVC novamente.

Alterar o método de faturamento de um volume para assinatura

Discos em cloud usados como volumes devem utilizar o faturamento por pagamento conforme o uso e não podem ser convertidos para assinatura.

Identificar o disco em cloud de um volume no console do ECS

Obtenha o ID do disco em cloud (formato d-********) e localize-o na página EBS no console do ECS para identificar os discos em cloud associados.

• Para PVs criados dinamicamente, o nome do PV é o ID do disco em cloud. Visualize-o na página Volumes > Persistent Volumes do cluster.

• Se o nome do PV não for o ID do disco em cloud, execute kubectl get pv <pv-name> -o yaml. O campo volumeHandle contém o ID do disco em cloud.