Container Service for Kubernetes:Manage the csi-plugin and csi-provisioner components

Falha na inicialização: exec /usr/bin/plugin.csi.alibabacloud.com: exec format error

Sintoma

O contêiner csi-plugin no Pod csi-plugin falha ao iniciar e o log exibe o erro: exec /usr/bin/plugin.csi.alibabacloud.com: exec format error.

Causa

Esse erro geralmente indica incompatibilidade de arquitetura de CPU. No entanto, o csi-plugin suporta as arquiteturas amd64 e arm64 por padrão. Portanto, se esse erro ocorrer em um nó suportado, a causa mais provável é um arquivo de imagem CSI corrompido.

Isso pode acontecer se o processo de pull da imagem for interrompido, por exemplo, por um desligamento forçado, deixando um arquivo de imagem incompleto no nó. Embora os metadados da imagem existam, o executável binário fica inválido ou danificado, impedindo o início do contêiner csi-plugin.

Solução

• Escale horizontalmente adicionando um novo nó e, em seguida, drene o nó problemático.

• Se for necessário manter o nó atual, execute as seguintes etapas:

  1. Drene o nó para evacuar suas cargas de trabalho e, em seguida, remova o nó do cluster.

  2. Faça login no nó e exclua todos os contêineres, se houver.

  3. Exclua todos os arquivos do diretório /var/lib/containerd.

  4. Adicione o nó novamente ao cluster.

Problemas de OOM em componentes de armazenamento

O contêiner sidecar no pod do componente csi-provisioner armazena em cache informações de recursos, como pods, PVs e PVCs. Em clusters de grande escala, isso pode consumir muita memória e causar erro de Out-of-Memory (OOM) no contêiner.

• csi-provisioner gerenciado: Envie um ticket para obter assistência.

• csi-provisioner não gerenciado: Se ocorrer erro OOM, ajuste os limites de recursos com base no tamanho do cluster.

  1. Na página Clusters, clique no nome do cluster. No painel de navegação à esquerda, clique em Components and Add-ons.

  2. Localize o componente csi-provisioner, clique no ícone e, em seguida, clique em View in YAML.

  3. Edite o yaml do componente para ajustar os limites de recursos de acordo com o tamanho do cluster.

     containers:
         - name: external-disk-provisioner
           image: registry-vpc.cn-huhexxxx.yuncs.com/acs/csi-provisioner:v3.0.0-080f01e64-aliyun
           resources:
             requests:
               cpu: 10m
               memory: 16Mi
             limits:
               cpu: 500m
               memory: 1024Mi

Alto tráfego de rede no csi-plugin

Sintoma

No painel de monitoramento de pods do cluster, os pods do componente csi-plugin apresentam alto tráfego de rede.

Causa

Este é um comportamento esperado. O componente csi-plugin gerencia a montagem de volumes de armazenamento NAS nos nós. Quando um pod de aplicação lê ou grava dados por um ponto de montagem NAS, o tráfego de rede resultante passa pelo namespace de rede do pod csi-plugin. Por isso, o sistema de monitoramento atribui esse tráfego ao pod csi-plugin.

Solução

Nenhuma ação é necessária; ignore este alerta com segurança. O tráfego é atribuído ao pod csi-plugin apenas para fins de contabilização. Ele não consome recursos do pod, nem resulta em tráfego duplicado ou faturamento duplo. Trata-se de um artefato de monitoramento sem impacto no desempenho.

Os logs do componente csi-provisioner relatam o erro failed to renew lease xxx timed out waiting for the condition

Sintoma

Execute o comando kubectl logs csi-provisioner-xxxx -n kube-system para visualizar os logs do CSI. O erro failed to renew lease xxx timed out waiting for the condition é relatado.

Causa

O componente csi-provisioner usa modelo de múltiplas réplicas para alta disponibilidade. Para garantir que apenas uma instância atenda às solicitações por vez, as réplicas usam o mecanismo Lease do Kubernetes para eleição de líder. Esse mecanismo depende de comunicação estável com o servidor de API.

Esse erro indica que o csi-provisioner não consegue acessar o servidor de API, causando falha na eleição de líder. Como resultado, nenhuma réplica assume a liderança para fornecer o serviço.

Solução

Verifique a conectividade de rede do cluster e o status do servidor de API. Se o problema persistir, envie um ticket para obter assistência.

Falha na verificação pré-atualização do csi-plugin

kubectl -nkube-system get ds csi-plugin flexvolume

NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
csi-plugin   4         4         4       4            4           kubernetes.io/os=linux   7d
flexvolume   4         4         4       4            4           kubernetes.io/os=linux   7d                                  

Falha na atualização do csi-plugin após verificação prévia

O componente csi-plugin é implantado como DaemonSet, exigindo que todos os nós estejam saudáveis. A atualização falha se o cluster tiver algum nó em estado NotReady ou não Running.

Repare o nó defeituoso antes de tentar a atualização novamente. Se não conseguir identificar a causa, entre em contato conosco para solicitar uma atualização manual assistida.

csi-provisioner ausente no console

Versões anteriores do csi-provisioner (1,14 e anteriores) são implantadas como StatefulSet. Se ainda existirem instâncias StatefulSet do csi-provisioner no cluster atual, exclua-as manualmente (kubectl delete sts csi-provisioner) antes de reinstalar.

Se encontrar problemas durante essa operação, entre em contato conosco para solicitar uma atualização manual assistida.

Falha na verificação pré-atualização do csi-provisioner

kubectl -nkube-system get ds csi-plugin flexvolume

NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
csi-plugin   4         4         4       4            4           kubernetes.io/os=linux   7d
flexvolume   4         4         4       4            4           kubernetes.io/os=linux   7d                                  

Falha na atualização do csi-provisioner após verificação prévia

Entre em contato conosco para solicitar uma atualização manual assistida.

Falha na atualização do csi-provisioner: Contagem de nós ou permissões

Sintoma

• Cenário 1: A verificação pré-atualização do componente csi-provisioner falha, indicando que o cluster não possui nós suficientes.

• Cenário 2: A verificação prévia e a atualização do componente csi-provisioner são bem-sucedidas. No entanto, o Pod do componente entra no estado CrashLoopBackOff e os logs mostram um erro 403 Forbidden.

  time="2023-08-05T13:54:00+08:00" level=info msg="Use node id : <?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n         \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" lang=\"en\">\n <head>\n  <title>403 - Forbidden</title>\n </head>\n <body>\n  <h1>403 - Forbidden</h1>\n </body>\n</html>\n"

Causa e solução

• Cenário 1

  • Causa: O componente csi-provisioner usa modelo de implantação ativo-standby. Suas duas réplicas devem ser agendadas em nós diferentes para satisfazer requisitos de anti-afinidade. Clusters de nó único não atendem a essa condição, fazendo a segunda réplica permanecer no estado Pending e impedindo a conclusão da atualização.

  • Solução: Adicione pelo menos mais um nó ao cluster para garantir o agendamento correto das múltiplas réplicas.

• Cenário 2

  • Causa: O componente csi-provisioner precisa acessar os metadados da instância do nó para obter informações como ID da instância e região, necessárias para chamar APIs do Alibaba Cloud. Se o reforço de segurança estiver ativado no nó ou se políticas de rede restritivas estiverem configuradas, o acesso ao serviço de metadados poderá ser bloqueado.

  • Solução: Ajuste ou desative as políticas de reforço de segurança no nó para garantir que o pod acesse o serviço de metadados. Verifique também regras do grupo de segurança, configurações de firewall do SO e scripts de segurança relevantes.

Falha na atualização do csi-provisioner: Modificação da StorageClass

Sintoma

A instalação ou atualização do csi-provisioner falha na verificação prévia, indicando que as propriedades da StorageClass não atendem às expectativas.

Causa

A StorageClass padrão fornecida pelo ACK possui configuração fixa. Campos principais como provisioner e parameters não podem ser alterados. Excluir e recriar manualmente uma StorageClass com o mesmo nome causa falha na validação e interrompe a atualização do componente.

O instalador do CSI valida rigorosamente a integridade desses recursos para garantir comportamento consistente do componente.

Solução

1. Exclua os objetos StorageClass padrão do cluster, incluindo alicloud-disk-essd, alicloud-disk-available, alicloud-disk-efficiency, alicloud-disk-ssd e alicloud-disk-topology.

   Esta operação não afeta o uso normal de PVs e PVCs existentes.

2. Após excluir os objetos StorageClass, reinstale o csi-provisioner. O instalador recriará automaticamente os objetos StorageClass. Nenhuma ação adicional é necessária.

Se precisar de uma StorageClass personalizada, crie sempre uma nova com nome diferente. Não modifique nem recrie os objetos StorageClass padrão.