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 nível de expansão 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 plano de controle, mas não nas VMs do nó de trabalho.

Para resolver esse problema, copie manualmente o arquivo de tatuagem de certificado 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 de proprietário e grupo neste arquivo de volta para raiz se ele ainda não estiver definido 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 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. 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 se juntar ao agente de nuvem, esgotando as portas.

Para resolver o problema, pare a execução do wssdagent. Como o serviço está na fase inicial, isso pode impedir que você pare 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. Matar 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 HCI 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á em funcionamento.

   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-HCI não conseguir atualizar da versão de maio para a versão de junho, a expectativa é que o AKS-HCI reverta para a versão de maio e continue funcionando. 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-HCI. Se a atualização falhar, o AKS-HCI volta para maio, mas os agentes do MOC estão inativos.

Comportamento esperado

Se a atualização do Aks-Hci falhar, a expectativa é que o AksHci 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 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ó: consulta reg "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 todas as manchas, funções e rótulos personalizados adicionados 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 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 manchas 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, porque 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' para 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 ficará fora da política.

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

Se os nós HCI do Azure Stack 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 cai em um estado incorreto.

Para reproduzir

1. Reinicialize um nó HCI do Azure Stack.
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 estar í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

or

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

2. Conecte a vNIC à VM.

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

or

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

3. Se o comando vNIC connect falhar, tente desconectar e conectar-se novamente. A seguir está o comando para desconexão vNIC.

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

or

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 Stack HCI é 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 Stack HCI usando o comando proxy PowerShell.

Ao atualizar clusters do 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 diretiva 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 uma OPA, verifique se suas políticas permitem extrair imagens do Registro de Contêiner do Azure. Para uma atualização do AKS no Azure Stack HCI, você deve adicionar o seguinte ponto de extremidade na lista da sua política: ecpacr.azurecr.io.

A execução de uma atualização do sistema operacional em um host com uma implantação do AKS no Azure Stack HCI pode fazer com que a implantação entre em um estado incorreto e falhe nas operações do segundo dia. O MOC NodeAgent Services pode 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, uma operação AKS como New-AksHciCluster pode falhar. A mensagem de erro indica que os nós MOC sã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 paralisa.

Execute o comando a seguir para verificar se há uma máquina com PHASE Exclusão 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 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á preso.

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

A execução de uma atualização do sistema operacional em um host com uma implantação de HCI do AKS no Azure Stack 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 de HCI para HCIv2. Em seguida, tente executar comandos que tentem 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 ser algo assim, 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 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ê deve ver a operação de faturamento continuar dentro dos próximos 20-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 torne todos os comandos de Get-AksHciCluster, faturamento e atualização excedentes. Como solução alternativa, defina a VM do cluster de gerenciamento como 32 GB no Hyper-V e reinicie-a.

• Motivo três: O AksHci Billing Operator pode estar sem espaço de armazenamento, o que é 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 faturamento usando as seguintes etapas.

  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 de armazenamento de 100Mi para 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 Stack HCI para a atualização de abril de 2022, a atualização pode ficar travada por um período de tempo indefinido. Pode haver vagens 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 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 addon AksHci CSI dentro dos 10 minutos e recria o driver junto com o resto dos recursos adicionais 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 Stack HCI 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ê 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 salvou:

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

3. Finalmente, 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 quando estiver usando AKS Arc, você pode arquivar bugs através do GitHub.