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 em execução na parte superior do 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 Stack HCI, 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 resolve 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 Terminando , 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 um estado inválido 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 em execução .

O armazenamento em disco pode ser preenchido a partir de logs de despejo de memória criados. Isso ocorre devido a um certificado de cliente do agente de Genebra expirado. 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 alocar espaço em disco ou gravar novos arquivos, portanto, qualquer erro de "espaço/recursos em disco insuficiente" é uma boa dica. Para marcar se esse problema estiver presente em um determinado nó, execute o seguinte comando de 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 de Genebra 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.

Atenuaçã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 o host AKS-HCI.

Para obter mais informações sobre as versões do AKS Arc e todas as últimas notícias do AKS-HCI, assine a página de versões do AKS.

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

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

   sudo systemctl disable --now mdsd
   

2. Verifique se o agente de Genebra foi desabilitado 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
   

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

Se você enfrentar 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 ao montar o 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 ter êxito.

Próximas etapas

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