Solucionar problemas de gerenciamento do Kubernetes e cluster de carga de trabalho no AKS Arc

Ao executar o comando Remove-ClusterNode , o nó é removido do cluster de failover, mas se Remove-AksHciNode não for executado posteriormente, o nó ainda existirá no CloudAgent.

Como o nó foi removido do cluster, mas não do CloudAgent, se você usar o VHD para criar um novo nó, um erro "Arquivo não encontrado" será exibido. Esse problema ocorre porque o VHD está no armazenamento compartilhado e o nó removido não tem acesso a ele.

Para resolver esse problema, remova um nó físico do cluster e siga estas etapas:

1. Execute Remove-AksHciNode para cancelar o registro do nó do CloudAgent.
2. Realize manutenções de rotina, como a criação de novas imagens da máquina.
3. Adicione o nó de volta ao cluster.
4. Execute Add-AksHciNode para registrar o nó com o CloudAgent.

Com clusters grandes, o Get-AksHciLogs comando pode lançar uma exceção, não enumerar nós ou não gerar o arquivo de saída c:\wssd\wssdlogs.zip.

Isso ocorre porque o comando do PowerShell para compactar um arquivo, 'Compress-Archive', tem um limite de tamanho de arquivo de saída de 2 GB.

Depois de atualizar ou dimensionar o cluster de carga de trabalho, o pod de renovação de certificado agora está em um estado de loop de falha porque o pod está esperando o arquivo YAML de tatuagem de certificado do local /etc/Kubernetes/pkido arquivo.

Esse problema pode ser devido a um arquivo de configuração que está presente nas VMs do plano de controle, mas não nas VMs do nó de trabalho.

Para resolver esse problema, copie manualmente o arquivo YAML de tatuagem de certificado do nó do plano de controle para todos os nós de trabalho.

1. Copie o arquivo YAML da VM do plano de controle no cluster de carga de trabalho para o diretório atual da sua máquina host:

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Copie o arquivo YAML da máquina host para a VM do nó de trabalho. Antes de copiar o arquivo, você deve alterar o nome da máquina no arquivo YAML para o nome do nó para o qual você está copiando (este é o nome do nó para o plano de controle de cluster de carga de trabalho).

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. Se as informações do proprietário e do grupo no arquivo YAML ainda não estiverem definidas como root, defina as informações como root:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Repita as etapas 2 e 3 para todos os nós de trabalho.

Os comandos do PowerShell Aks-Hci não validam a memória disponível no servidor host antes de criar nós do Kubernetes. Esse problema pode levar ao esgotamento da memória e máquinas virtuais que não são iniciadas.

No momento, essa falha não é tratada normalmente e a implantação deixará de responder sem nenhuma mensagem de erro clara. Se você tiver uma implantação que para de responder, abra o Visualizador de Eventos e verifique se há uma mensagem de erro relacionada ao Hyper-V indicando que não há memória suficiente para iniciar a VM.

Ao executar Get-AksHciCluster para verificar o status de uma instalação do AKS Arc no Windows Admin Center, a saída mostra um erro: "Uma versão com a versão 1.0.3.10818 NÃO FOI ENCONTRADA." No entanto, ao executar Get-AksHciVersion, mostrou que a mesma versão foi instalada. Este erro indica que a compilação expirou.

Para resolver esse problema, execute Uninstall-AksHcie, em seguida, execute uma nova compilação do AKS Arc.

Ao usar a ferramenta de administração de cluster para mover uma VM de um nó (Nó A) para outro nó (Nó B) no cluster Local do Azure, a VM pode falhar ao iniciar no novo nó. Depois de mover a VM de volta para o nó original, ela também não será iniciada lá.

Esse problema acontece porque a lógica para limpar a primeira migração é executada de forma assíncrona. Como resultado, a lógica "atualizar local da VM" do Serviço Kubernetes do Azure localiza a VM no Hyper-V original no nó A e a exclui, em vez de cancelá-la.

Para contornar esse problema, verifique se a VM foi iniciada com êxito no novo nó antes de movê-lo de volta para o nó original.

Ao usar o PowerShell para criar um cluster com endereços IP estáticos e, em seguida, tentar aumentar o número de nós de trabalho no cluster de carga de trabalho, a instalação fica presa em "contagem de plano de controle em 2, ainda aguardando o estado desejado: 3". Após um período de tempo, outra mensagem de erro aparece: "Erro: tempo limite expirado aguardando a condição."

Quando Get-AksHciCluster foi executado, mostrou que os nós do plano de controle foram criados e provisionados e estavam em um estado Ready . No entanto, quando kubectl get nodes foi executado, mostrou que os nós do plano de controle tinham sido criados, mas não provisionados e não estavam em um estado Pronto .

Se você receber esse erro, verifique se os endereços IP foram atribuídos aos nós criados usando o Gerenciador do Hyper-V ou o PowerShell:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Em seguida, verifique as configurações de rede para garantir que haja endereços IP suficientes no pool para criar mais VMs.

Comandos como Update-AksHci, Update-AksHciCertificates, Update-AksHciClusterCertificatese todas as interações com o cluster de gerenciamento podem retornar "Erro: Você deve estar conectado ao servidor (Não autorizado)".

Este erro pode ocorrer quando o arquivo kubeconfig expirou. Para verificar se expirou, execute o seguinte script:

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Se esse script exibir uma data anterior à data atual, o arquivo kubeconfig expirou.

Para atenuar o problema, copie o arquivo admin.conf , que está dentro da VM do plano de controle de gerenciamento, para o host Local do Azure:

• SSH para a VM do plano de controle de gerenciamento:

  • Obtenha o plano de controle de gerenciamento VM IP:

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • SSH nele:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Copie o arquivo para o local do usuário na nuvem:

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Dê acesso ao clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Opcional] Crie um backup do arquivo kubeconfig :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Copie o ficheiro:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Quando você verifica o gerenciador do Hyper-V, as altas demandas de CPU e memória para o cluster de gerenciamento podem ser ignoradas com segurança. Eles estão relacionados a picos no uso de recursos de computação ao provisionar clusters de carga de trabalho.

O aumento da memória ou do tamanho da CPU para o cluster de gerenciamento não mostrou uma melhoria significativa e pode ser ignorado com segurança.

Você verá esse problema se seguir estas etapas:

1. Crie um cluster do Kubernetes.
2. Dimensione o cluster para mais de dois nós.
3. Exclua um nó executando o seguinte comando:

kubectl delete node <node-name>

4. Retorna uma lista dos nós executando o seguinte comando:

kubectl get nodes

O nó removido não está listado na saída. 5. Abra uma janela do PowerShell com privilégios administrativos e execute o seguinte comando:

get-vm

O nó removido ainda está listado.

Essa falha faz com que o sistema não reconheça que o nó está faltando e, portanto, um novo nó não girará.

Se você não usar um cluster de gerenciamento ou carga de trabalho por mais de 60 dias, os certificados expirarão e você deverá renová-los antes de atualizar o AKS Arc. Quando um cluster AKS não é atualizado dentro de 60 dias, o token de plug-in KMS e os certificados expiram dentro dos 60 dias. O cluster ainda está funcional. No entanto, como já passou de 60 dias, você precisa ligar para o suporte da Microsoft para atualizar. Se o cluster for reinicializado após esse período, ele permanecerá em um estado não funcional.

Para resolver esse problema, execute as seguintes etapas:

1. Repare o certificado do cluster de gerenciamento girando manualmente o token e reinicie o plug-in e o contêiner KMS.
2. Repare os mocctl certificados executando Repair-MocLogin.
3. Repare os certificados de cluster de carga de trabalho girando manualmente o token e reinicie o plug-in e o contêiner KMS.

O cluster de carga de trabalho pode não ser encontrado se os pools de endereços IP de dois AKS em implantações do Azure Local forem os mesmos ou se sobreporem. Se você implantar dois hosts AKS e usar a mesma AksHciNetworkSetting configuração para ambos, o PowerShell e o Windows Admin Center potencialmente não conseguirão localizar o cluster de carga de trabalho, pois o servidor de API receberá o mesmo endereço IP em ambos os clusters, resultando em um conflito.

A mensagem de erro que você recebe será semelhante ao exemplo mostrado abaixo.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

A implantação de um cluster grande pode atingir o tempo limite após duas horas. No entanto, este é um tempo limite estático.

Você pode ignorar essa ocorrência de tempo limite, pois a operação está sendo executada em segundo plano. Use o kubectl get nodes comando para acessar seu cluster e monitorar o progresso.

Ao tentar exibir um AKS na implantação do Azure Local após alguns dias, Kubectl não executou nenhum de seus comandos. O log de plug-in do Serviço de Gerenciamento de Chaves (KMS) exibiu a mensagem rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificatesde erro .

O cmdlet Repair-AksHciClusterCerts falhará se o servidor de API estiver inativo. Se o AKS no Azure Local não tiver sido atualizado por 60 ou mais dias, quando você tentar reiniciar o plug-in KMS, ele não será iniciado. Essa falha também faz com que o servidor de API falhe.

Para corrigir esse problema, você precisa girar manualmente o token e, em seguida, reiniciar o plug-in KMS e o contêiner para obter o backup do servidor de API. Para tal, execute os seguintes passos:

1. Gire o token executando o seguinte comando:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Copie o token para a VM usando o comando a seguir. A ip configuração no comando abaixo refere-se ao endereço IP do plano de controle do host AKS.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Reinicie o plug-in KMS e o contêiner.

   Para obter a ID do contêiner, execute o seguinte comando:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   A saída deve aparecer com os seguintes campos:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   A saída deve ser semelhante a este exemplo:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Finalmente, reinicie o contêiner executando o seguinte comando:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

Em uma instalação do AKS no Azure Local com a extensão do Windows Admin Center versão 1.82.0, o cluster de gerenciamento foi configurado usando o PowerShell e foi feita uma tentativa de implantar um cluster de carga de trabalho usando o Windows Admin Center. Uma das máquinas tinha o módulo do PowerShell versão 1.0.2 instalado e outras máquinas tinham o módulo do PowerShell 1.1.3 instalado. A tentativa de implantar o cluster de carga de trabalho falhou com o erro "Não é possível encontrar um parâmetro que corresponda ao nome do parâmetro 'nodePoolName'." Este erro pode ter ocorrido devido a uma incompatibilidade de versão. A partir da versão 1.1.0 do PowerShell, o -nodePoolName <String> parâmetro foi adicionado ao cmdlet New-AksHciCluster e, por design, esse parâmetro agora é obrigatório ao usar a extensão do Windows Admin Center versão 1.82.0.

Para resolver este problema, efetue um dos seguintes procedimentos:

• Use o PowerShell para atualizar manualmente o cluster de carga de trabalho para a versão 1.1.0 ou posterior.
• Use o Windows Admin Center para atualizar o cluster para a versão 1.1.0 ou para a versão mais recente do PowerShell.

Esse problema não ocorre se o cluster de gerenciamento for implantado usando o Windows Admin Center, pois ele já tem os módulos mais recentes do PowerShell instalados.

Quando você implanta o AKS no Azure Local e, em seguida, executa kubectl get podso , os pods no mesmo nó ficam presos no estado de Encerramento . A máquina rejeita conexões SSH porque o nó provavelmente está enfrentando alta demanda de memória. Esse problema ocorre porque os nós do Windows são provisionados em excesso e não há reserva para componentes principais.

Para evitar essa situação, adicione os limites de recursos e as solicitações de recursos para CPU e memória à especificação do pod para garantir que os nós não sejam provisionados em excesso. Os nós do Windows não suportam remoção com base nos limites de recursos, portanto, você deve estimar quanto os contêineres usarão e, em seguida, garantir que os nós tenham quantidades suficientes de CPU e memória. Você pode encontrar mais informações em requisitos do sistema.

O dimensionamento automático do cluster pode falhar quando você usa a seguinte política do Azure em seu cluster de gerenciamento de host AKS: "Os clusters Kubernetes não devem usar o namespace padrão." Isso acontece porque a política, quando implementada no cluster de gerenciamento de host AKS, bloqueia a criação de perfis de autoscaler no namespace padrão. Para corrigir esse problema, escolha uma das seguintes opções:

• Desinstale a extensão Azure Policy no cluster de gerenciamento de host AKS. Saiba mais sobre como desinstalar as extensões do Azure Policy aqui.
• Altere o escopo da política do Azure para excluir clusters de gerenciamento de host AKS. Saiba mais sobre os escopos da Política do Azure aqui.
• Defina o modo de imposição de política como "Desativado" para o cluster de gerenciamento de host AKS. Saiba mais sobre o modo de imposição aqui.

Este é um problema conhecido com o AKS na Atualização Local de julho do Azure (versão 1.0.2.10723). O erro ocorre porque o serviço CloudAgent atinge o tempo limite durante a distribuição de máquinas virtuais em vários volumes compartilhados de cluster no sistema.

Para resolver esse problema, você deve atualizar para a versão mais recente do AKS no Azure Local.

Se você provisionar um cluster AKS no Azure Local com zero nós Linux ou Windows, quando executar Get-AksHciCluster, a saída será uma cadeia de caracteres vazia ou um valor nulo.

Nulo é um retorno esperado para nós zero.

Quando você desliga um cluster de gerenciamento ou carga de trabalho por mais de quatro dias, os certificados expiram e o cluster fica inacessível. Os certificados expiram porque são alternados a cada 3-4 dias por motivos de segurança.

Para reiniciar o cluster, você precisa reparar manualmente os certificados antes de executar qualquer operação de cluster. Para reparar os certificados, execute o seguinte comando Repair-AksHciClusterCerts :

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

Ao dimensionar um cluster de carga de trabalho, as VMs Linux e Windows correspondentes foram adicionadas como nós de trabalho, mas não foram configuradas como VMs altamente disponíveis. Ao executar o comando Get-ClusterGroup , a VM Linux recém-criada não foi configurada como um Grupo de Clusters.

Trata-se de um problema conhecido. Após uma reinicialização, a capacidade de configurar VMs como altamente disponíveis às vezes é perdida. A solução alternativa atual é reiniciar wssdagent em cada um dos nós locais do Azure. Isso funciona apenas para novas VMs que são geradas pela criação de pools de nós ao executar uma operação de expansão ou ao criar novos clusters Kubernetes depois de reiniciar o wssdagent nos nós. No entanto, você terá que adicionar manualmente as VMs existentes ao cluster de failover.

Quando você reduz a escala de um cluster, os recursos de cluster de alta disponibilidade ficam em um estado de falha enquanto as VMs são removidas. A solução alternativa para esse problema é remover manualmente os recursos com falha.

Um cluster AKS implantado em uma VM do Azure estava funcionando bem, mas depois que o host AKS foi desativado por vários dias, o Kubectl comando não funcionou. Depois de executar o Kubectl get nodes comando ou Kubectl get services , esta mensagem de erro apareceu: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Esse problema ocorreu porque o host AKS foi desligado por mais de quatro dias, o que fez com que os certificados expirassem. Os certificados são frequentemente alternados em um ciclo de quatro dias. Execute Repair-AksHciClusterCerts para corrigir o problema de expiração do certificado.

Em um cluster de carga de trabalho com endereços IP estáticos e nós do Windows, todos os pods em um nó (incluindo os daemonset pods) ficam presos em um estado ContainerCreation . Ao tentar se conectar a esse nó usando SSH, a conexão falha com um Connection timed out erro.

Para resolver esse problema, use o Gerenciador do Hyper-V ou o Gerenciador de Cluster de Failover para desativar a VM desse nó. Após 5 a 10 minutos, o nó deveria ter sido recriado, com todos os pods em execução.

Quando o kubelet está sob pressão de disco, ele coleta imagens de contêiner não utilizadas, que podem incluir imagens de pausa e, quando isso acontece, o ContainerD não pode puxar a imagem.

Para resolver esse problema, execute as seguintes etapas:

1. Conecte-se ao nó afetado usando SSH e execute o seguinte comando:

sudo su

2. Para extrair a imagem, execute o seguinte comando:

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Próximos passos

• Descrição geral da resolução de problemas
• Problemas e erros de rede
• Problemas conhecidos de armazenamento