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 o escalonamento do cluster de destino, o pod de renovação do certificado está agora 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 plano de controle, mas não nas VMs do nó de trabalho.

Para resolver esse problema, copie manualmente o arquivo cert tattoo 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 da 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 works)
   scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\
   

2. Copie o arquivo da máquina 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 a reinicialização do agente do nó devido à expiração do token. Esta 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 constantemente tenta se juntar ao 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. Em caso afirmativo, mate o processo antes de tentar parar 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. Pare 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á instalado e em execução.

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

2. Execute o seguinte comando para corrigir o wssdagent:

   Repair-Moc
   

3. Quando esse comando for concluído, o wssdagent deverá estar em estado de execução.

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

Quando o AKS no Azure Local não consegue atualizar 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 deixa os agentes MOC em um estado parado, e as tentativas manuais de iniciar o agente não os ativam.

Passos 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 reverta 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 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"

Exemplo de saída

"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 de nó: reg query "HKLM\System\CurrentControlSet\Services\wssdagent"

Exemplo de saída

"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 todas as manchas, 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 manchas, rótulos e funções personalizados quando executado 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 manchas para os 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, porque ele agora 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 pronto. Se você executar Sync-AksHciBilling, ele retornará a 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, o faturamento 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 eles. Essa perda de vNICs faz com que as VMs percam a conectividade de rede e o cluster fica em um estado ruim.

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. Repita.

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 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. A seguir está o comando para vNIC disconnect.

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

ou

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

Pods presos à espera que os pods estáticos tenham 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 logon 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, o Windows Admin Center não tem suporte para instalar módulos em um ambiente proxy.

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

Ao atualizar clusters Kubernetes com um Open Policy Agent (OPA), como o OPA GateKeeper, o processo pode travar e não ser possível concluir. 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, certifique-se de que suas políticas permitam 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 sua política: ecpacr.azurecr.io.

Executar 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 do MOC NodeAgent 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 AKS existente de HCI para HCIv2 OS, uma operação AKS como New-AksHciCluster pode falhar. A mensagem de erro indica 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 seguinte comando:

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 esteja 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 correspondente à 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á preso.

Para localizar essas informações, execute o cmdlet e o comando a seguir. Por padrão, o cmdlet Get-AksHciCredential grava o kubeconfig em ~/.kube/config. Se você especificar um local diferente para seu cluster de carga de trabalho kubeconfig ao chamar Get-AksHciCredential, você precisará fornecer esse local para 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 desse 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 para a 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á.

Executar 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, 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 AKS HCI OS do HCI para o HCIv2. Em seguida, tente executar comandos que tentam alcançar o cluster de gerenciamento, como Get-AksHciCluster. Todas as operações que tentam alcançar 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 o ID do kube-vip contêiner:

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

A saída deve ter esta aparência, com o 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 PowerShell.

Analise as seguintes causas raiz para resolver o problema:

• Primeiro motivo: Durante a atualização do Operador de Faturamento AksHci, o operador se marcou incorretamente como fora da política. Para resolver esse problema, abra uma nova janela do PowerShell e execute Sync-AksHciBilling. Você verá a operação de faturamento continuar nos próximos 20 a 30 minutos.

• Segundo motivo: 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, faturamento 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 Faturamento AksHci pode estar sem espaço de armazenamento, o que se deve 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 faturamento 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 faturamento usando o seguinte comando:

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

Quando você atualiza clusters da Atualização de fevereiro de 2022 do AKS no Azure Local para a Atualização de abril de 2022, a atualização pode ficar bloqueada na atualização por um período de tempo indefinido. Pode haver cápsulas presas Terminating no estado ou CrashLoopBackoff no estado.

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

O addon 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 addon em um estado sem resposta durante a atualização. O driver CSI .spec.fsGroupPolicy foi definido para 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 conciliados. Todos os recursos da 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 addon AksHci CSI dentro de 10 minutos e recria o driver junto com o resto dos recursos de addon 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.

A compilação de junho 1.0.1.10628 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 melhorado 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ê enfrentar 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óximos passos

• Descrição geral da resolução de problemas
• Problemas e erros de instalação
• Problemas conhecidos do Windows Admin Center

Se você continuar a ter problemas quando estiver usando o AKS Arc, poderá arquivar bugs através do GitHub.