Corrigir problemas e erros conhecidos ao gerenciar o armazenamento no AKS Arc

Esse erro de permissão negada indica que a classe de armazenamento padrão pode não ser adequada para suas cargas de trabalho e ocorre em cargas de trabalho do Linux executadas sobre o Kubernetes versão 1.19.x ou posterior. Seguindo as práticas recomendadas de segurança, muitas cargas de trabalho do Linux especificam a securityContext fsGroup configuração de um pod. As cargas de trabalho não são iniciadas no AKS no Azure Local, pois a classe de armazenamento padrão não especifica o fstype (=ext4) parâmetro, portanto, o Kubernetes não consegue alterar a propriedade de arquivos e volumes persistentes com base no fsGroup solicitado pela carga de trabalho.

Para resolver esse problema, defina uma classe de armazenamento personalizada que você pode usar para provisionar PVCs.

Um novo cluster de carga de trabalho do Kubernetes foi criado com o Kubernetes versão 1.16.10 e, em seguida, atualizado para 1.16.15. Após a atualização, o csi-msk8scsi-node-9x47m pod ficou preso no estado ContainerCreating e o kube-proxy-qqnkr pod ficou preso no estado Terminating , conforme mostrado na saída abaixo:

Error: kubectl.exe get nodes  
NAME              STATUS     ROLES    AGE     VERSION 
moc-lf22jcmu045   Ready      <none>   5h40m   v1.16.15 
moc-lqjzhhsuo42   Ready      <none>   5h38m   v1.16.15 
moc-lwan4ro72he   NotReady   master   5h44m   v1.16.15

\kubectl.exe get pods -A 

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE 
    5h38m 
kube-system   csi-msk8scsi-node-9x47m     0/3     ContainerCreating   0          5h44m 
kube-system   kube-proxy-qqnkr            1/1     Terminating         0          5h44m  

Uma vez que kubelet acabou em um mau estado e não pode mais falar com o servidor de API, a única solução é reiniciar o kubelet serviço. Após a reinicialização, o cluster entra em um estado de execução .

O armazenamento em disco pode ser preenchido a partir de logs de despejo de falhas criados. Isto deve-se a um certificado de cliente do agente Geneva expirado. Os sintomas podem ser os seguintes:

• Os serviços não são iniciados.
• Pods do Kubernetes, implantações, etc. não são iniciados devido a recursos insuficientes.

Esse problema pode afetar qualquer operação que envolva alocar espaço em disco ou gravar novos arquivos, portanto, qualquer erro "espaço em disco insuficiente/recursos" é uma boa dica. Para verificar se esse problema está presente em um determinado nó, execute o seguinte comando shell:

clouduser@moc-lwm2oudnskl $ sudo du -h /var/lib/systemd/coredump/

Este comando relata o espaço de armazenamento consumido pelos arquivos de diagnóstico.

Causa raiz

A expiração do certificado de cliente usado para autenticar o agente de Genebra no ponto de extremidade de serviço faz com que o agente falhe, resultando em um despejo de falha. O loop de falha/repetição do agente é de cerca de 5 segundos na inicialização inicial e não há tempo limite. Isso significa que um novo arquivo (cerca de 330 MB) é criado no sistema de arquivos do nó a cada poucos segundos, o que pode consumir rapidamente o armazenamento em disco.

Mitigação

A atenuação preferida é atualizar para a versão mais recente, versão 1.10.18.10425, que tem um certificado atualizado. Para fazer isso, primeiro atualize manualmente seus clusters de carga de trabalho para qualquer versão secundária com suporte antes de atualizar seu host Local do Azure.

Para obter mais informações sobre as versões do AKS Arc e todas as últimas notícias do AKS no Azure Local, inscreva-se na página de lançamentos do AKS.

Se a atualização não for uma opção, você pode desativar o serviço mdsd . Para cada nó Mariner:

1. Desligue o agente de Genebra com os seguintes comandos shell:

   sudo systemctl disable --now mdsd
   

2. Verifique se o agente de Genebra foi desativado com êxito:

   sudo systemctl status mdsd
   

3. Exclua arquivos acumulados com o seguinte comando:

   sudo find /var/lib/systemd/coredump/ -type f -mmin +1 -exec rm -f {} \;
   sudo find /run/systemd/propagate -name 'systemd-coredump@*' -delete
   sudo journalctl --rotate && sudo journalctl --vacuum-size=500M
   

4. Reinicialize o nó:

   sudo reboot
   

Pode ocorrer um erro se você tiver um driver CSI SMB ou NFS instalado em sua implantação e atualizar para a compilação de maio a partir de uma versão mais antiga. Um dos parâmetros, chamado createSubDir, não é mais aceito. Se isso se aplicar à sua implantação, siga as instruções abaixo para resolver a falha da classe de armazenamento.

Se ocorrer esse erro, o pod de armazenamento trava e os logs indicam que o createSubDir parâmetro é inválido.

Recrie a classe de armazenamento.

Depois de excluir um volume persistente ou uma declaração de volume persistente em um ambiente AKS Arc, um novo volume persistente é criado para mapear para o mesmo compartilhamento. No entanto, ao tentar montar o volume, a montagem falha e o tempo limite do pod expira com o erro, NewSmbGlobalMapping failed.

Para contornar a falha na montagem do novo volume, você pode SSH no nó do Windows e executar Remove-SMBGlobalMapping e fornecer o compartilhamento que corresponde ao volume. Depois de executar esse comando, as tentativas de montar o volume devem ser bem-sucedidas.

Próximos passos

• Descrição geral da resolução de problemas
• Problemas conhecidos do Windows Admin Center