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

Este erro de permissão negada indica que a classe de armazenamento predefinida pode não ser adequada para as cargas de trabalho e ocorre em cargas de trabalho do Linux em execução na versão 1.19.x ou posterior do Kubernetes. Seguindo as melhores práticas de segurança, muitas cargas de trabalho do Linux especificam a securityContext fsGroup definição para um pod. As cargas de trabalho não iniciam no AKS no Azure Stack HCI, uma vez que a classe de armazenamento predefinida não especifica o fstype (=ext4) parâmetro, pelo que o Kubernetes não altera a propriedade dos ficheiros e dos volumes persistentes com base nos fsGroup pedidos pela carga de trabalho.

Para resolver este problema, defina uma classe de armazenamento personalizada que pode utilizar para aprovisionar PVCs.

Foi criado um novo cluster de carga de trabalho do Kubernetes com a versão 1.16.10 do Kubernetes e, em seguida, atualizado para a versão 1.16.15. Após a atualização, o csi-msk8scsi-node-9x47m pod ficou bloqueado no estado ContainerCreating e o kube-proxy-qqnkr pod ficou bloqueado no estado Terminação , 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 kubelet vez que acabou num mau estado e já não consegue falar com o servidor de API, a única solução é reiniciar o kubelet serviço. Depois de reiniciar, o cluster entra num estado de execução .

O armazenamento de discos pode ser preenchido a partir de registos de falha de sistema criados. Isto deve-se a um certificado de cliente do agente geneva expirado. Os sintomas podem ser os seguintes:

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

Este problema pode afetar qualquer operação que envolva alocar espaço em disco ou escrever novos ficheiros, pelo que qualquer erro de "espaço/recursos em disco insuficiente" é uma boa sugestão. Para verificar se este problema está presente num determinado nó, execute o seguinte comando da shell:

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

Este comando comunica o espaço de armazenamento consumido pelos ficheiros de diagnóstico.

Causa raiz

A expiração do certificado de cliente utilizado para autenticar o agente geneva no ponto final de serviço faz com que o agente falhe, resultando numa falha de sistema. O ciclo de falha/repetição do agente é de cerca de 5 segundos no arranque inicial e não há tempo limite. Isto significa que é criado um novo ficheiro (cerca de 330 MB) no sistema de ficheiros do nó a cada poucos segundos, o que pode consumir rapidamente o armazenamento de discos.

Mitigação

A mitigação preferencial é atualizar para a versão mais recente, a versão 1.10.18.10425, que tem um certificado atualizado. Para tal, atualize manualmente os clusters de cargas de trabalho para qualquer versão secundária suportada antes de atualizar o anfitrião AKS-HCI.

Para obter mais informações sobre as versões do AKS Arc e todas as notícias mais recentes do AKS-HCI, subscreva a página de lançamentos do AKS.

Se a atualização não for uma opção, pode desativar o serviço mdsd . Para cada nó de 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 desativado com êxito:

   sudo systemctl status mdsd
   

3. Elimine ficheiros 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. Reinicie o nó:

   sudo reboot
   

Pode ocorrer um erro se tiver um controlador CSI SMB ou NFS instalado na sua implementação e atualizar para a compilação may a partir de uma versão mais antiga. Um dos parâmetros, denominado createSubDir, já não é aceite. Se isto se aplicar à sua implementação, siga as instruções abaixo para resolver a falha da classe de armazenamento.

Se ocorrer este erro, o pod de armazenamento falha e os registos indicam que o createSubDir parâmetro é inválido.

Recrie a classe de armazenamento.

Depois de eliminar um volume persistente ou uma afirmação de volume persistente num ambiente do AKS Arc, é criado um novo volume persistente para mapear para a mesma partilha. No entanto, ao tentar montar o volume, a montagem falha e o pod excede o limite de tempo com o erro . NewSmbGlobalMapping failed

Para contornar a falha ao montar o novo volume, pode aceder ao SSH no nó do Windows e executar Remove-SMBGlobalMapping e fornecer a partilha que corresponde ao volume. Depois de executar este comando, as tentativas de montar o volume devem ser bem-sucedidas.

Passos seguintes

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