Resolver problemas de cluster de carga de trabalho e gestão do Kubernetes no AKS Arc

Ao executar o comando Remove-ClusterNode , o nó é expulso do cluster de ativação pós-falha, mas se Remove-AksHciNode não for executado posteriormente, o nó continuará a existir no CloudAgent.

Uma vez que o nó foi removido do cluster, mas não do CloudAgent, se utilizar o VHD para criar um novo nó, é apresentado um erro "Ficheiro não encontrado". Este problema ocorre porque o VHD está no armazenamento partilhado e o nó removido não tem acesso ao mesmo.

Para resolver este problema, remova um nó físico do cluster e siga estes passos:

1. Execute Remove-AksHciNode para anular o registo do nó a partir do CloudAgent.
2. Efetue a manutenção de rotina, como voltar a imaginar o computador.
3. Volte a adicionar o nó ao cluster.
4. Execute Add-AksHciNode para registar o nó no CloudAgent.

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

Isto acontece porque o comando do PowerShell para zipar um ficheiro, "Compress-Archive", tem um limite de tamanho de ficheiro de saída de 2 GB.

Depois de atualizar ou aumentar verticalmente o cluster de cargas de trabalho, o pod de renovação do certificado encontra-se agora num estado de ciclo de falha porque o pod está à espera do ficheiro YAML de tatuagem de certificado a partir da localização /etc/Kubernetes/pkido ficheiro.

Este problema pode dever-se a um ficheiro de configuração que está presente nas VMs do plano de controlo, mas não nas VMs do nó de trabalho.

Para resolver este problema, copie manualmente o ficheiro YAML de tatuagem de certificado do nó do plano de controlo para todos os nós de trabalho.

1. Copie o ficheiro YAML da VM do plano de controlo no cluster de carga de trabalho para o diretório atual do seu computador anfitrião:

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 ficheiro YAML do computador anfitrião para a VM do nó de trabalho. Antes de copiar o ficheiro, tem de alterar o nome do computador no ficheiro YAML para o nome do nó para o qual está a copiar (este é o nome do nó do plano de controlo do cluster de cargas 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 ficheiro YAML ainda não estiverem definidas como raiz, defina as informações para 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 os passos 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 anfitrião antes de criarem nós do Kubernetes. Este problema pode levar ao esgotamento da memória e às máquinas virtuais que não são iniciadas.

Esta falha não é atualmente processada corretamente e a implementação deixará de responder sem uma mensagem de erro clara. Se tiver uma implementação que deixe de responder, abra Visualizador de Eventos e verifique se existe uma mensagem de erro relacionada com Hyper-V que indique que não existe memória suficiente para iniciar a VM.

Ao executar Get-AksHciCluster para verificar o estado de uma instalação do AKS Arc no Windows Admin Center, o resultado 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 este problema, execute Uninstall-AksHcie, em seguida, execute uma nova compilação do AKS Arc.

Ao utilizar a ferramenta de administração do cluster para mover uma VM de um nó (Nó A) para outro nó (Nó B) no cluster do Azure Stack HCI, a VM pode não ser iniciada no novo nó. Depois de mover a VM de volta para o nó original, também não iniciará aí.

Este problema acontece porque a lógica para limpar a primeira migração é executada de forma assíncrona. Como resultado, a lógica "atualizar localização da VM" do Azure Kubernetes Service localiza a VM no Hyper-V original no nó A e elimina-a, em vez de a anular o registo.

Para resolver este problema, certifique-se de que a VM foi iniciada com êxito no novo nó antes de movê-la novamente para o nó original.

Ao utilizar 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 cargas de trabalho, a instalação fica bloqueada em "contagem de planos de controlo em 2, ainda à espera do estado pretendido: 3". Após um período de tempo, é apresentada outra mensagem de erro: "Erro: tempo limite excedido à espera da condição".

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

Se receber este erro, verifique se os endereços IP foram atribuídos aos nós criados com o Gestor de Hyper-V ou o PowerShell:

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

Em seguida, verifique as definições de rede para garantir que existem endereços IP suficientes no conjunto para criar mais VMs.

Comandos como Update-AksHci, Update-AksHciCertificates, Update-AksHciClusterCertificatese todas as interações com o cluster de gestão podem devolver "Erro: tem de ter sessão iniciada no servidor (Não Autorizado)".

Este erro pode ocorrer quando o ficheiro 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 este script apresentar uma data anterior à data atual, o ficheiro kubeconfig expirou.

Para mitigar o problema, copie o ficheiro admin.conf , que está dentro da VM do plano de controlo de gestão, para o anfitrião HCI:

• SSH para a VM do plano de controlo de gestão:

  • Obtenha o IP da VM do plano de controlo de gestão:

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

  • SSH no mesmo:

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

• Copie o ficheiro para a localização do clouduser :

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

• Conceder acesso ao clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Opcional] Crie uma cópia de segurança do ficheiro 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 verifica o gestor de Hyper-V, as elevadas exigências de CPU e memória para o cluster de gestão podem ser ignoradas com segurança. Estão relacionados com picos na utilização de recursos de computação ao aprovisionar clusters de cargas de trabalho.

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

Verá este problema se seguir estes passos:

1. Criar um cluster do Kubernetes.
2. Dimensione o cluster para mais de dois nós.
3. Elimine um nó ao executar o seguinte comando:

kubectl delete node <node-name>

4. Devolva uma lista dos nós ao executar 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.

Esta falha faz com que o sistema não reconheça que o nó está em falta e, portanto, um novo nó não irá girar.

Se não utilizar um cluster de gestão ou carga de trabalho durante mais de 60 dias, os certificados expiram e tem de renová-los antes de poder atualizar o AKS Arc. Quando um cluster do AKS não é atualizado no prazo de 60 dias, o token de plug-in KMS e os certificados expiram dentro de 60 dias. O cluster ainda está funcional. No entanto, uma vez que são mais de 60 dias, tem de ligar para o suporte da Microsoft para atualizar. Se o cluster for reiniciado após este período, este permanecerá num estado não funcional.

Para resolver este problema, execute os seguintes passos:

1. Repare o certificado do cluster de gestão ao rodar manualmente o token e, em seguida, reinicie o plug-in e o contentor KMS.
2. Repare os mocctl certificados ao executar Repair-MocLogin.
3. Repare os certificados do cluster de carga de trabalho ao rodar manualmente o token e, em seguida, reinicie o plug-in e o contentor KMS.

O cluster de cargas de trabalho pode não ser encontrado se os conjuntos de endereços IP de duas implementações do AKS no Azure Stack HCI forem iguais ou se se sobreporem. Se implementar dois anfitriões do AKS e utilizar a mesma AksHciNetworkSetting configuração para ambos, o PowerShell e o Windows Admin Center poderão falhar ao localizar o cluster de cargas de trabalho, uma vez que o servidor de API receberá o mesmo endereço IP em ambos os clusters, resultando num conflito.

A mensagem de erro que receber terá um aspeto semelhante ao exemplo apresentado 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 implementação de um cluster grande pode exceder o tempo limite após duas horas. No entanto, este é um tempo limite estático.

Pode ignorar esta ocorrência de tempo limite, uma vez que a operação está em execução em segundo plano. Utilize o kubectl get nodes comando para aceder ao cluster e monitorizar o progresso.

Ao tentar criar um AKS na implementação do Azure Stack HCI após alguns dias, Kubectl não executou nenhum dos respetivos comandos. O registo de plug-in do Key Management Service (KMS) apresentou 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 falha se o servidor de API estiver inativo. Se o AKS no Azure Stack HCI não tiver sido atualizado durante 60 ou mais dias, quando tentar reiniciar o plug-in KMS, este não será iniciado. Esta falha também faz com que o servidor de API falhe.

Para corrigir este problema, tem de rodar manualmente o token e, em seguida, reiniciar o plug-in KMS e o contentor para obter a cópia de segurança do servidor de API. Para tal, execute os seguintes passos:

1. Rode o token ao executar 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 com o seguinte comando. A ip definição no comando abaixo refere-se ao endereço IP do plano de controlo do anfitrião 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 contentor.

   Para obter o ID do contentor, execute o seguinte comando:

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

   O resultado deve aparecer com os seguintes campos:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   O resultado deve ter um aspeto 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. Por fim, reinicie o contentor ao executar o seguinte comando:

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

Numa instalação do AKS no Azure Stack HCI com a extensão de Windows Admin Center versão 1.82.0, o cluster de gestão foi configurado com o PowerShell e foi efetuada uma tentativa de implementar um cluster de cargas de trabalho com Windows Admin Center. Uma das máquinas tinha a versão 1.0.2 do módulo do PowerShell instalada e outras máquinas tinham o módulo 1.1.3 do PowerShell instalado. A tentativa de implementar o cluster de cargas 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 um erro de correspondência da 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 predefinição, este parâmetro é agora obrigatório ao utilizar a extensão de Windows Admin Center versão 1.82.0.

Para resolver este problema, efetue um dos seguintes procedimentos:

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

Este problema não ocorre se o cluster de gestão for implementado com Windows Admin Center, uma vez que já tem os módulos mais recentes do PowerShell instalados.

Quando implementa o AKS no Azure Stack HCI e, em seguida, executa kubectl get pods, os pods no mesmo nó ficam bloqueados no estado De terminação . A máquina rejeita as ligações SSH porque é provável que o nó esteja a ter uma procura de memória elevada. Este problema ocorre porque os nós do Windows estão sobreaprovisionados e não há reserva para componentes principais.

Para evitar esta situação, adicione os limites de recursos e os pedidos de recursos para CPU e memória à especificação do pod para garantir que os nós não estão sobreaprovisionados. Os nós do Windows não suportam a expulsão com base nos limites de recursos, pelo que deve estimar a quantidade que os contentores irão utilizar e, em seguida, garantir que os nós têm quantidades de CPU e memória suficientes. Pode encontrar mais informações nos requisitos de sistema.

O dimensionamento automático do cluster pode falhar quando utiliza a seguinte política do Azure no cluster de gestão de anfitriões do AKS: "Os clusters do Kubernetes não devem utilizar o espaço de nomes predefinido.". Isto acontece porque a política, quando implementada no cluster de gestão de anfitriões do AKS, bloqueia a criação de perfis de dimensionamento automático no espaço de nomes predefinido. Para corrigir este problema, escolha uma das seguintes opções:

• Desinstale a extensão Azure Policy no cluster de gestão de anfitriões do AKS. Saiba mais sobre como desinstalar extensões de Azure Policy aqui.
• Altere o âmbito da política do Azure para excluir clusters de gestão de anfitriões do AKS. Saiba mais sobre Azure Policy âmbitos aqui.
• Defina o modo de imposição de política como "Desativado" para o cluster de gestão de anfitriões do AKS. Saiba mais sobre o modo de imposição aqui.

Este é 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 excede o tempo limite durante a distribuição de máquinas virtuais em vários volumes partilhados de cluster no sistema.

Para resolver este problema, deve atualizar para o AKS mais recente na versão do Azure Stack HCI.

Se aprovisionar um cluster do AKS no Azure Stack HCI com zero nós do Linux ou Windows, quando executar Get-AksHciCluster, o resultado será uma cadeia vazia ou um valor nulo.

É uma devolução nula esperada para zero nós.

Quando encerra um cluster de gestão ou carga de trabalho durante mais de quatro dias, os certificados expiram e o cluster fica inacessível. Os certificados expiram porque são rodados a cada 3 a 4 dias por motivos de segurança.

Para reiniciar o cluster, tem de reparar manualmente os certificados antes de poder realizar quaisquer operações de cluster. Para reparar os certificados, execute o seguinte comando Repair-AksHciClusterCerts :

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

Ao aumentar horizontalmente um cluster de cargas de trabalho, as VMs do Linux e do Windows correspondentes foram adicionadas como nós de trabalho, mas não foram configuradas como VMs de elevada disponibilidade. Ao executar o comando Get-ClusterGroup , a VM do Linux recentemente criada não foi configurada como um Grupo de Clusters.

Este é um problema conhecido. Após um reinício, a capacidade de configurar VMs como altamente disponíveis é, por vezes, perdida. A solução atual é reiniciar wssdagent em cada um dos nós do Azure Stack HCI. Isto só funciona para novas VMs geradas pela criação de conjuntos de nós ao executar uma operação de escalamento horizontal ou ao criar novos clusters do Kubernetes após reiniciar os wssdagent nos nós. No entanto, terá de adicionar manualmente as VMs existentes ao cluster de ativação pós-falha.

Quando reduz verticalmente um cluster, os recursos do cluster de elevada disponibilidade estão num estado de falha enquanto as VMs são removidas. A solução para este problema é remover manualmente os recursos com falhas.

Um cluster do AKS implementado numa VM do Azure estava a funcionar corretamente, mas depois de o anfitrião do AKS ter sido desativado durante 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.

Este problema ocorreu porque o anfitrião do AKS esteve desativado durante mais de quatro dias, o que fez com que os certificados expirassem. Os certificados são frequentemente rodados num ciclo de quatro dias. Execute Repair-AksHciClusterCerts para corrigir o problema de expiração do certificado.

Num cluster de carga de trabalho com endereços IP estáticos e nós do Windows, todos os pods num nó (incluindo os daemonset pods) estão bloqueados num estado ContainerCreating . Ao tentar ligar a esse nó através de SSH, a ligação falha com um Connection timed out erro.

Para resolver este problema, utilize o Gestor de Hyper-V ou o Gestor de Clusters de Ativação Pós-falha 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 do disco, recolhe imagens de contentor não utilizadas, que podem incluir imagens em pausa e, quando isto acontece, o ContainerD não consegue extrair a imagem.

Para resolver este problema, execute os seguintes passos:

1. Ligue-se ao nó afetado através de SSH e execute o seguinte comando:

sudo su

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

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

Passos seguintes

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