Corrigir problemas conhecidos e erros 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 em execução 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 altera 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 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  

Como kubelet acabou em mau estado e não consegue 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 memória criados. Isso se deve a um certificado expirado de cliente de agente Geneva. Os sintomas podem ser os seguintes:

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

Esse problema pode afetar qualquer operação que envolva a alocação de espaço em disco ou a gravação de novos arquivos, portanto, qualquer erro de "espaço/recursos em disco insuficientes" é 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/

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

Causa raiz

A expiração do certificado do cliente usado para autenticar o agente Geneva no ponto de extremidade de serviço faz com que o agente falhe, resultando em um despejo de memória. 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 mitigação preferencial é 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 notícias mais recentes do AKS no Azure Local, assine a página de versões do AKS.

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

1. Desative o agente Geneva com os seguintes comandos shell:

   sudo systemctl disable --now mdsd
   

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

   sudo systemctl status mdsd
   

3. Exclua os 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
   

Um erro poderá ocorrer se você tiver um driver CSI SMB ou NFS instalado em sua implantação e atualizar para a compilação de maio 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 você tiver esse erro, o pod de armazenamento falhará e os logs indicarão 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 do 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 pod atinge o tempo limite 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óximas etapas

• Visão geral de solução de problemas
• Problemas conhecidos do Windows Admin Center