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 resolve esse problema, remova um nó físico do cluster e siga estas etapas:

1. Execute Remove-AksHciNode para desativar o registro do nó do CloudAgent.
2. Execute a manutenção de rotina, como re-geração de imagens do computador.
3. Adicione novamente o nó ao cluster.
4. Execute Add-AksHciNode para registrar o nó com o CloudAgent.

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

Isso ocorre porque o comando do PowerShell para fechar 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 resolve esse problema, copie manualmente o arquivo YAML de tatuagem de certificado do nó do painel 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 (este é o nome do nó para o painel 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 de proprietário e grupo no arquivo YAML ainda não estiverem definidas como raiz, defina as informações como a 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 do PowerShell do 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 de 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 pare de responder, abra Visualizador de Eventos e marcar para 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 o build expirou.

Para resolve esse problema, execute Uninstall-AksHcie 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 do Azure Stack HCI, a VM pode falhar ao iniciar no novo nó. Depois de mover a VM de volta para o nó original, ela também falhará ao iniciar lá.

Esse problema ocorre porque a lógica para limpo 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 cancelá-la.

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 tentar aumentar o número de nós de trabalho no cluster de carga de trabalho, a instalação fica paralisada em "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: tempo limite aguardando a condição".

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

Esse erro pode ocorrer quando o arquivo kubeconfig expirar. Para marcar se tiver expirado, 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 expirará.

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

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

  • Obtenha o IP da VM do painel 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 do 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ê marcar gerenciador do Hyper-V, 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. 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á criado.

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 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 são mais de 60 dias, você precisa chamar 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 resolve esse problema, execute as seguintes etapas:

1. Repare o certificado do cluster de gerenciamento girando manualmente o token e reinicie o plug-in kms e o contêiner.
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 kms e o contêiner.

O cluster de carga de trabalho poderá não ser encontrado se os pools de endereços IP de duas implantações do AKS no Azure Stack HCI forem iguais ou sobrepostos. Se você implantar dois hosts aks e usar a mesma AksHciNetworkSetting configuração para ambos, o PowerShell e 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 recebida 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á em execução em segundo plano. Use o kubectl get nodes comando para acessar o cluster e monitorar o progresso.

Ao tentar criar uma implantação do AKS no Azure Stack HCI após alguns dias, Kubectl não executou nenhum de seus comandos. O log de plug-in do KMS (Serviço de Gerenciamento de Chaves) 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 Stack HCI 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 reiniciar o plug-in kms e o contêiner 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 a seguir refere-se ao endereço IP do painel de controle do host do 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 do AKS no Azure Stack HCI com a extensão 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 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 1.1.3 do PowerShell instalado. Falha na tentativa de implantar o cluster de carga de trabalho com o erro "Não é 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 o Windows Admin Center extensão versão 1.82.0.

Para resolver esse problema, siga 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 Stack HCI e executa kubectl get podso , os pods no mesmo nó ficam presos no estado Terminando . O computador 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 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 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 nos 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 Azure Policy no cluster de gerenciamento de host do AKS. Saiba mais sobre como desinstalar extensões Azure Policy aqui.
• Altere o escopo da política do Azure para excluir clusters de gerenciamento de host do AKS. Saiba mais sobre Azure Policy escopos 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 o AKS na Atualização de Julho do Azure Stack HCI (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 resolve esse problema, você deve atualizar para a versão mais recente do AKS no Azure Stack HCI.

Se você provisionar um cluster do AKS no Azure Stack HCI 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 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 girados 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 correspondentes do Linux e do Windows 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.

Este é 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 do Azure Stack HCI. 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 depois de 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 estão 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 corretamente, 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 girados 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 resolve 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 usadas, que podem incluir imagens de pausa e, quando isso acontece, o ContainerD não pode efetuar pull da imagem.

Para resolve esse problema, execute as seguintes etapas:

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

sudo su

2. Para efetuar pull da 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 do armazenamento