Resolver problemas ao atualizar o AKS Arc

As versões mais antigas do PowerShell não são removidas.

Para contornar esse problema, você pode executar esse script para desinstalar versões mais antigas do PowerShell.

Depois de atualizar ou aumentar a escala do cluster de destino, o pod de renovação de certificado agora está em um estado de loop de falha. Está esperando um arquivo de tatuagem yaml cert do caminho /etc/Kubernetes/pki. O arquivo de configuração está presente nas VMs do nó do painel de controle, mas não nas VMs do nó de trabalho.

Para resolver esse problema, copie manualmente o arquivo de tatuagem cert do nó do plano de controle para cada um dos nós de trabalho.

1. Copie o arquivo da VM do plano de controle 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 works)
   scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\
   

2. Copie o arquivo do computador host para a VM do nó de trabalho.

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

3. Defina as informações do proprietário e do grupo neste arquivo de volta para root se ele ainda não estiver definido 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 cert file to correct location)
   sudo chown root cert-tattoo-kubelet.yaml
   sudo chgrp root cert-tattoo-kubelet.yaml
   

4. Repita as etapas 2 e 3 para cada um dos nós de trabalho.

Quando um cluster não é atualizado há mais de 60 dias, o agente do nó falha ao iniciar durante uma reinicialização do agente do nó devido à expiração do token. Essa falha faz com que os agentes estejam na fase inicial. Tentativas contínuas de ingressar no cloudagent podem esgotar o fornecimento de portas no host. O status do comando a seguir é Iniciando.

Get-Service wssdagent | Select-Object -Property Name, Status

Comportamento esperado: O agente do nó deve estar na fase inicial, que tenta constantemente ingressar no agente de nuvem, esgotando as portas.

Para resolver o problema, interrompa a execução do wssdagent. Como o serviço está na fase inicial, isso pode impedir que você interrompa o serviço. Nesse caso, encerre o processo antes de tentar interromper o serviço.

1. Confirme se o wssdagent está na fase inicial.

   Get-Service wssdagent | Select-Object -Property Name, Status
   

2. Mate o processo.

   kill -Name wssdagent -Force
   

3. Parar o serviço.

   Stop-Service wssdagent -Force
   

Get-Process -Name wssdagent

PS C:\WINDOWs\system32 Get-process -Name wssdagent 
Get-process : Cannot find a process with the name "wssdaqent". Verify the process name and call the cmdlet again.
At line: 1 char: 1 
+ Get-process -Name wssdagent
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + Categorylnfo          : ObjectNotFound: (wssdagent:String) [Get-Process], ProcessCommandException 
    + FullyQua1ifiedErrorId : NoProcess FoundForGivenName , Microsoft.PowerShell.Commands.Getprocesscommand

1. Repita as etapas 1, 2 e 3 em cada nó do cluster local do Azure que tem esse problema.

2. Depois de confirmar que o wssdagent não está em execução, inicie o cloudagent se ele não estiver em execução.

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName

1. Confirme se o cloudagent está ativo e em execução.

   Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
   

2. Execute o seguinte comando para corrigir o wssdagent:

   Repair-Moc
   

3. Depois que esse comando for concluído, o wssdagent deverá estar no estado de execução.

   Get-Service wssdagent | Select-Object -Property Name, Status
   

Quando o AKS no Azure Local não atualiza da versão de maio para a versão de junho, a expectativa é que o AKS no Azure Local reverta para a versão de maio e continue a funcionar. Mas isso deixa os agentes do MOC em um estado parado e as tentativas manuais de iniciar o agente não os ativam.

Etapas para reproduzir

1. Instale o módulo AKS-HCI PowerShell versão 1.1.36.
2. Atualize o AKS no Azure Local. Se a atualização falhar, o AKS no Azure Local voltará para maio, mas os agentes MOC estarão inativos.

Comportamento esperado

Se a atualização do AKS no Azure Local falhar, a expectativa é que o AKS no Azure Local seja revertido para a versão anterior e continue a funcionar sem problemas.

Sintomas

Incompatibilidade entre a versão Aks-HCI e a versão MOC

• Get-AksHciVersion: 1.0.10.10513
• Get-MocVersion: 1.0.11.10707

Incompatibilidade entre Get-MocVersion e wssdcloudagent.exe versão

Get-MocVersion indica que a compilação de junho está instalada, enquanto a versão wssdcloudagent.exe indica que a compilação de maio está instalada.

O caminho da imagem dos serviços do agente MOC tem o parâmetro de ID de implantação

Execute o seguinte comando para mostrar o caminho da imagem para o agente de nuvem:

reg query "HKLM\System\CurrentControlSet\Services\wssdcloudagent"

Saída de exemplo

"C:\Program Files\AksHci\wssdcloudagent.exe" --service --basedir "base dir" --cloudagentfqdn "cloudagent fqdn" --dotfolderpath "dot folder path" --objectdatastore "data store" --clusterresourcename "cluster name" --certificatevalidityfactor 1 --deploymentid "deployment id"

Use o seguinte comando para mostrar o caminho da imagem para o agente do nó: reg query "HKLM\System\CurrentControlSet\Services\wssdagent"

Saída de exemplo

"C:\Program Files\AksHci\wssdagent.exe" --service --basedir "base dir" --cloudloginfile "cloud login file path" --dotfolderpath "dotfolder path" --nodeagentfqdn "node fqdn" --objectdatastore "object data store" --wssdproviderspec "provider spec" --deploymentid "deployment id"

Para atenuar o problema, execute os seguintes cmdlets do PowerShell:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdcloudagent" -Name ImagePath -Value 'above cloud agent image path without the deployment id'
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdagent" -Name ImagePath -Value 'above node agent image path without the deployment id'

Ao atualizar, você pode perder todos os taints, funções e rótulos personalizados que adicionou aos nós de trabalho. Como o AKS é um serviço gerenciado, não há suporte para a adição de taints, rótulos e funções personalizados quando executados fora dos cmdlets do PowerShell fornecidos ou do Windows Admin Center.

Para contornar esse problema, execute o cmdlet New-AksHciNodePool para criar corretamente um pool de nós com taints para seus nós de trabalho.

Se você criou um cluster de gerenciamento, mas não implantou um cluster de carga de trabalho nos primeiros 60 dias, será impedido de criar um, pois agora ele está fora da política. Nessa situação, quando você executa Update-AksHci, o processo de atualização é bloqueado com o erro Aguardando a implantação 'AksHci Billing Operator' estar pronta. Se você executar Sync-AksHciBilling, ele retornará uma saída bem-sucedida. No entanto, se você executar Get-AksHciBillingStatus, o status da conexão será OutofPolicy.

Se você não tiver implantado um cluster de carga de trabalho em 60 dias, a cobrança sairá da política.

A única maneira de corrigir esse problema é reimplantar com uma instalação limpa.

Se os nós locais do Azure forem reinicializados um após o outro, algumas das máquinas virtuais perderão as vNICs anexadas a elas. Essa perda de vNICs faz com que as VMs percam a conectividade de rede e o cluster caia em um estado ruim.

Para reproduzir

1. Reinicialize um nó local do Azure.
2. Aguarde até que o nó conclua a reinicialização. O nó precisa ser marcado Up no cluster de failover.
3. Reinicialize os outros nós.
4. Repeat.

Comportamento esperado O estado do cluster deve ser íntegro. Todas as VMs devem ter NICs anexadas a elas.

Para resolver o problema, use os comandos MOC para adicionar a vNIC à VM.

1. Obtenha o nome do vNIC para a VM.

(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

ou

mocctl.exe compute vm get --name <vmname> --group <group>

2. Conecte a vNIC à VM.

Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

ou

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>

3. Se o comando vNIC connect falhar, tente desconectar e conectar novamente. Veja a seguir o comando para desconexão do vNIC.

Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

ou

mocctl.exe compute vm nic remove --name <vnicname> --vm-name <vmname> --group <group>

Os pods ficaram presos esperando que os pods estáticos tivessem uma condição pronta.

Para liberar os pods e resolver esse problema, você deve reiniciar o kubelet. Para exibir o nó NotReady com os pods estáticos, execute o seguinte comando:

kubectl get nodes -o wide

Para obter mais informações sobre o nó defeituoso, execute o seguinte comando:

kubectl describe node <IP of the node>

Use SSH para fazer login no nó NotReady executando o seguinte comando:

ssh -i <path of the private key file> administrator@<IP of the node>

Em seguida, para reiniciar o kubelet, execute o seguinte comando:

/etc/.../kubelet restart

Ao executar uma atualização no Windows Admin Center, ocorreu o seguinte erro:

Error occurred while fetching platform upgrade information. RemoteException: No match was found for the specified search criteria and module name 'AksHci'. Try Get-PSRepository to see all available registered module repositories.

Essa mensagem de erro normalmente ocorre quando o AKS no Azure Local é implantado em um ambiente que tem um proxy configurado. Atualmente, Windows Admin Center não tem suporte para instalar módulos em um ambiente de proxy.

Para resolver esse erro, configure o AKS no Azure Local usando o comando proxy do PowerShell.

Ao atualizar clusters do Kubernetes com um OPA (Open Policy Agent), como o OPA GateKeeper, o processo pode travar e não ser concluído. Esse problema pode ocorrer porque o agente de política está configurado para impedir a extração de imagens de contêiner de registros privados.

Para resolver esse problema, se você atualizar clusters implantados com um OPA, verifique se suas políticas permitem extrair imagens do Registro de Contêiner do Azure. Para uma atualização do AKS no Azure Local, você deve adicionar o seguinte ponto de extremidade na lista da política: ecpacr.azurecr.io.

A execução de uma atualização do sistema operacional em um host com um AKS na implantação local do Azure pode fazer com que a implantação entre em um estado incorreto e falhe nas operações do segundo dia. Os Serviços NodeAgent do MOC podem falhar ao iniciar em hosts atualizados. Todas as chamadas MOC para os nós falham.

Para reproduzir: quando você atualiza um cluster com uma implantação existente do AKS do HCI para o sistema operacional HCIv2, uma operação do AKS pode New-AksHciCluster falhar. A mensagem de erro informa que os nós MOC estão OutOfCapacity. Por exemplo:

System.Collections.Hashtable.generic_non_zero1 [Error: failed to create nic test-load-balancer-whceb-nic for machinetest-load-balancer-whceb: unable to create VM network interface: failed to create network interface test-load-balancer-whceb-nic in resource group clustergroup-test: rpc error: code = Unknown desc = Location 'MocLocation' doesn't expose any nodes to create VNIC 'test-load-balancer-whceb-nic' on: OutOfCapacity]

Para resolver esse problema, inicie o serviço wssdagent Moc NodeAgent nos nós afetados. Isso resolverá o problema e trará a implantação de volta a um bom estado. Execute o comando a seguir:

Get-ClusterNode -ErrorAction Stop | ForEach-Object { Invoke-Command -ComputerName $_ -ScriptBlock { Start-Service wssdagent -WarningAction:SilentlyContinue } }

Depois de executar Update-AksHciCluster, o processo de atualização é interrompido.

Execute o comando a seguir para verificar se há uma máquina com PHASE Excluindo que está executando a versão anterior do Kubernetes da qual você está atualizando.

kubectl get machines -o wide --kubeconfig (Get-KvaConfig).kubeconfig

Se houver uma máquina com PHASE Excluindo e VERSION correspondendo à versão anterior do Kubernetes, prossiga com as etapas a seguir.

Para resolver esse problema, você precisa das seguintes informações:

1. Versão do Kubernetes para a qual você está atualizando seu cluster de carga de trabalho.
2. Endereço IP do nó que está travado.

Para encontrar essas informações, execute o cmdlet e o comando a seguir. Por padrão, o cmdlet Get-AksHciCredential grava o kubeconfig no ~/.kube/config. Se você especificar um local diferente para o kubeconfig do cluster de carga de trabalho ao chamar Get-AksHciCredential, precisará fornecer esse local ao kubectl como outro argumento. Por exemplo, kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

Get-AksHciCredential -name <workload cluster name>
kubectl get nodes -o wide

O nó que precisa ser corrigido deve mostrar STATUS Ready,SchedulingDisabled. Se você vir um nó com esse status, use o INTERNAL-IP valor deste nó como o valor do endereço IP no comando a seguir abaixo. Use a versão do Kubernetes para a qual você está atualizando como o valor da versão; Isso deve corresponder ao VERSION valor do nó com ROLES control-plane,master. Certifique-se de incluir o valor completo da versão do Kubernetes, incluindo o v, por exemplo v1.22.6.

ssh -i (Get-MocConfig).sshPrivateKey -o StrictHostKeyChecking=no  clouduser@<IP address> sudo crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Depois de executar este comando ssh, os nós restantes com a versão antiga do Kubernetes devem ser excluídos e a atualização continuará.

A execução de uma atualização do sistema operacional em um host com uma implantação local do AKS no Azure pode fazer com que a implantação entre em um estado incorreto, o que torna o servidor de API do cluster de gerenciamento inacessível e falha nas operações do segundo dia. O kube-vip pod não pode aplicar a configuração VIP à interface e, como resultado, o VIP fica inacessível.

Para reproduzir: Atualize um cluster com uma implantação existente do sistema operacional HCI do AKS de HCI para HCIv2. Em seguida, tente executar comandos que tentam acessar o cluster de gerenciamento, como Get-AksHciCluster. Todas as operações que tentam acessar o cluster de gerenciamento falham com erros como:

PS C:\Users\wolfpack> Get-AksHciCluster
C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9
attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)]
At C:\Program Files\WindowsPowerShell\Modules\Kva\1.0.22\Common.psm1:2164 char:9
+         throw $errMessage
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (C:\Program File...iting headers)]:String) [], RuntimeException
    + FullyQualifiedErrorId : C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9 attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)]

Para resolver esse problema: reinicie o kube-vip contêiner para trazer a implantação de volta a um bom estado.

1. Obtenha a ID do kube-vip contêiner:

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

A saída deve ser semelhante a esta, com a ID do contêiner sendo o primeiro valor 4a49a5158a5f8. Por exemplo:

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55

1. Reinicie o Reinicie o contêiner:

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

Essa mensagem de status aparece ao executar o cmdlet Update-AksHci do PowerShell.

Revise as seguintes causas raiz para resolver o problema:

• Razão um: Durante a atualização do Operador de Cobrança AksHci, o operador marcou incorretamente a si mesmo como fora da política. Para resolver esse problema, abra uma nova janela do PowerShell e execute Sync-AksHciBilling. Você deve ver a operação de cobrança continuar nos próximos 20 a 30 minutos.

• Motivo dois: a VM do cluster de gerenciamento pode estar sem memória, o que faz com que o servidor de API fique inacessível e faz com que todos os comandos de Get-AksHciCluster, cobrança e atualização atinjam o tempo limite. Como solução alternativa, defina a VM do cluster de gerenciamento como 32 GB no Hyper-V e reinicie-a.

• Razão três: O Operador de Cobrança AksHci pode estar sem espaço de armazenamento, devido a um bug nas definições de configuração do Microsoft SQL. A falta de espaço de armazenamento pode estar fazendo com que a atualização pare de responder. Para contornar esse problema, redimensione manualmente o pod pvc de cobrança usando as etapas a seguir.

  1. Execute o seguinte comando para editar as configurações do pod:

     kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

  2. Quando o Bloco de Notas ou outro editor abrir com um arquivo YAML, edite a linha para armazenamento de 100Mi a 5Gi:

     spec:
       resources:
         requests:
           **storage: 5Gi**
     

  3. Verifique o status da implantação de cobrança usando o seguinte comando:

     kubectl get deployments/billing-manager-deployment --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

Quando você atualiza clusters do AKS na Atualização Local do Azure de fevereiro de 2022 para a Atualização de abril de 2022, a atualização pode ficar travada na atualização por um período indefinido. Pode haver pods presos no Terminating estado or CrashLoopBackoff .

Você pode ver que alguns dos recursos adicionais do AksHci CSI estão ausentes. Esses pods de recursos são implantados usando o csi-akshcicsi-controller ou do csi-akshcicsi-node daemonset.

O complemento AksHci CSI na atualização de fevereiro de 2022 continha uma alteração na especificação do driver CSI que às vezes pode deixar os recursos do complemento em um estado sem resposta durante a atualização. O driver .spec.fsGroupPolicy CSI foi definido como um novo valor, embora seja um campo imutável. Como o campo é imutável, a especificação do driver não é atualizada. Uma consequência disso é que os outros recursos adicionais do AksHci CSI podem não ser totalmente reconciliados. Todos os recursos do CSI seriam recriados.

Para resolver manualmente o problema, o driver CSI pode ser excluído manualmente. Depois de removê-lo, o operador de nuvem reconcilia o complemento AksHci CSI em 10 minutos e recria o driver junto com o restante dos recursos de complemento ausentes.

kubectl --kubeconfig $(Get-AksHciConfig).Kva.kubeconfig delete csidriver disk.csi.akshci.com`

Após uma atualização bem-sucedida, o painel de atualização do Windows Admin Center ainda mostra a versão anterior.

Atualize o navegador para corrigir esse problema.

O build 1.0.1.10628 de junho do AKS no Azure Local cria um número excessivo de segredos de configuração do Kubernetes no cluster. O caminho de atualização da versão 1.0.1.10628 de junho para a versão 1.0.2.10723 de julho foi aprimorado para limpar os segredos extras do Kubernetes. No entanto, em alguns casos, durante a atualização, os segredos ainda não foram limpos e, portanto, o processo de atualização falha.

Se você tiver esse problema, execute as seguintes etapas:

1. Salve o script abaixo como um arquivo chamado fix_leaked_secrets.ps1:

   upgparam (
   [Parameter(Mandatory=$true)]
   [string] $ClusterName,
   [Parameter(Mandatory=$true)]
   [string] $ManagementKubeConfigPath
   )
   
   $ControlPlaneHostName = kubectl get nodes --kubeconfig $ManagementKubeConfigPath -o=jsonpath='{.items[0].metadata.name}'
   "Hostname is: $ControlPlaneHostName"
   
   $leakedSecretPath1 = "$ClusterName-template-secret-akshci-cc"
   $leakedSecretPath2 = "$ClusterName-moc-kms-plugin"
   $leakedSecretPath3 = "$ClusterName-kube-vip"
   $leakedSecretPath4 = "$ClusterName-template-secret-akshc"
   $leakedSecretPath5 = "$ClusterName-linux-template-secret-akshci-cc"
   $leakedSecretPath6 = "$ClusterName-windows-template-secret-akshci-cc"
   
   $leakedSecretNameList = New-Object -TypeName 'System.Collections.ArrayList';
   $leakedSecretNameList.Add($leakedSecretPath1) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath2) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath3) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath4) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath5) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath6) | Out-Null
   
   foreach ($leakedSecretName in $leakedSecretNameList)
   {
   "Deleting secrets with the prefix $leakedSecretName"
   $output = kubectl --kubeconfig $ManagementKubeConfigPath exec etcd-$ControlPlaneHostName -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt del /registry/secrets/default/$leakedSecretName --prefix=true"
   "Deleted: $output"
   }
   

2. Em seguida, execute o seguinte comando usando o arquivo fix_secret_leak.ps1 que você salvou:

      .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
   

3. Por fim, use o seguinte comando do PowerShell para repetir o processo de atualização:

      Update-AksHci
   

Próximas etapas

• Visão geral de solução de problemas
• Problemas e erros de instalação
• Problemas conhecidos do Windows Admin Center

Se você continuar a ter problemas ao usar o AKS Arc, poderá registrar bugs por meio do GitHub.