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. Execute a manutenção de rotina, como recriar a imagem da máquina.
3. Adicione o nó de volta ao cluster.
4. Execute Add-AksHciNode para registrar o nó no CloudAgent.

Com clusters grandes, o Get-AksHciLogs comando pode lançar uma exceção, falhar ao 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 escalar verticalmente 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 painel 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 painel de controle no cluster de carga de trabalho para o diretório atual do computador 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 do computador host para a VM do nó de trabalho. Antes de copiar o arquivo, você deve alterar o nome do computador no arquivo YAML para o nome do nó para o qual você está copiando (esse é o nome do nó para o plano de controle do 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 raiz, defina as informações como raiz:

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 Aks-Hci do PowerShell 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 às 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 pare 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, ele mostrou que a mesma versão foi instalada. Esse erro indica que a compilação expirou.

Para resolver esse problema, execute Uninstall-AksHcie, em seguida, execute um novo build 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 ocorre porque a lógica para limpar a primeira migração é executada de forma assíncrona. Como resultado, a lógica de "atualizar local da VM" do Serviço de Kubernetes do Azure localiza a VM no Hyper-V original no nó A e a exclui, em vez de cancelar o registro.

Para contornar esse problema, verifique se a VM foi iniciada com êxito no novo nó antes de movê-la 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 na "contagem do plano de controle em 2, ainda aguardando o estado desejado: 3". Após um período de tempo, outra mensagem de erro é exibida: "Erro: expirou aguardando a condição".

Quando Get-AksHciCluster foi executado, ele mostrou que os nós do plano de controle foram criados e provisionados e estavam em um estado Pronto . No entanto, quando kubectl get nodes foi executado, ele mostrou que os nós do plano de controle haviam 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 restantes 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)".

Esse erro pode ocorrer quando o arquivo kubeconfig expira. 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 painel de controle de gerenciamento, para o host local do Azure:

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

  • Obtenha o IP da VM do plano de controle de gerenciamento:

    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 clouduser:

  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 arquivo:

  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.

Aumentar a memória ou o 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. Retorne 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á ausente e, portanto, um novo nó não será ativado.

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 do AKS não é atualizado em 60 dias, o token de plug-in do KMS e os certificados expiram em 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 do KMS.
2. Repare os mocctl certificados executando Repair-MocLogino .
3. Repare os certificados de cluster de carga de trabalho girando manualmente o token e reinicie o plug-in e o contêiner do KMS.

O cluster de carga de trabalho poderá não ser encontrado se os pools de endereços IP de duas implantações locais do AKS no Azure forem iguais ou se sobrepuserem. Se você implantar dois hosts AKS e usar a mesma AksHciNetworkSetting configuração para ambos, o PowerShell e o Windows Admin Center potencialmente falharão ao 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, esse é 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 comando para acessar o kubectl get nodes cluster e monitorar o progresso.

Ao tentar ativar um AKS na implantação local do Azure após alguns dias, Kubectl não executou nenhum de seus comandos. O log do plug-in KMS (Serviço de Gerenciamento de Chaves) exibia 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 dias ou mais, 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 reiniciar o plug-in e o contêiner do KMS para obter o backup do servidor de API. Para fazer isso, execute os seguintes etapas:

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 painel 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 esse exemplo:

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

4. Por fim, 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 local do AKS no Azure 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. Um dos computadores tinha o módulo do PowerShell versão 1.0.2 instalado e outros computadores 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 foi possível encontrar um parâmetro que corresponda ao nome do parâmetro 'nodePoolName'". Esse 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 Windows Admin Center versão 1.82.0.

Para resolver esse problema, execute um destes procedimentos:

• Use o PowerShell para atualizar manualmente o cluster de carga de trabalho para a versão 1.1.0 ou posterior.
• Use 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 ocorrerá se o cluster de gerenciamento for implantado usando Windows Admin Center, pois ele já tem os módulos mais recentes do PowerShell instalados.

Quando você implanta o AKS no Azure Local e executa kubectl get podso , os pods no mesmo nó ficam presos no estado Terminating . 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 estão superprovisionados e não há reserva para os 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 dão suporte à remoção com base em 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 no cluster de gerenciamento de host do AKS: "Os clusters do Kubernetes não devem usar o namespace padrão". Isso acontece porque a política, quando implementada no cluster de gerenciamento de host do AKS, bloqueia a criação de perfis de dimensionador automático no namespace padrão. Para corrigir esse problema, escolha uma das seguintes opções:

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

Esse é um problema conhecido com a Atualização Local de Julho do AKS no 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 do AKS no Azure Local com zero nós do Linux ou do Windows, ao executar Get-AksHciCluster, a saída será uma cadeia de caracteres vazia ou um valor nulo.

Null é um retorno esperado para zero nós.

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 a 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 escalar horizontalmente 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 do Linux recém-criada não foi configurada como um Grupo de Clusters.

Esse é 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 geradas pela criação de pools de nós ao executar uma operação de expansão ou ao criar novos clusters do Kubernetes após reiniciar o wssdagent nos nós. No entanto, você precisará adicionar manualmente as VMs existentes ao cluster de failover.

Quando você reduz verticalmente 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 do AKS implantado em uma VM do Azure estava funcionando bem anteriormente, mas depois que o host do 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 do AKS foi desativado 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) estão presos em um estado ContainerCreating . 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ó deve 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 extrair 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óximas etapas

• Visão geral de solução de problemas
• Problemas e erros de rede
• Problemas conhecidos de armazenamento