Resolver problemas ao atualizar o AKS Arc

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

Para resolver este problema, pode executar este script para desinstalar versões mais antigas do PowerShell.

Depois de atualizar ou aumentar verticalmente o cluster de destino, o pod de renovação do certificado encontra-se agora num estado de ciclo de falhas. Está à espera de um ficheiro de tatuagem yaml de certificado do caminho /etc/Kubernetes/pki. O ficheiro de configuração está presente nas VMs do nó do plano de controlo, mas não em VMs de nó de trabalho.

Para resolver este problema, copie manualmente o ficheiro de tatuagem de certificado do nó do plano de controlo para cada um dos nós de trabalho.

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

2. Copie o ficheiro do computador anfitrião 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 ficheiro como raiz, se ainda não estiverem definidas 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 os passos 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ó não inicia durante um reinício do agente de nó devido à expiração do token. Esta falha faz com que os agentes estejam na fase inicial. As tentativas contínuas de associação ao cloudagent podem esgotar a oferta de portas no anfitrião. O estado do seguinte comando é Iniciar.

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

Comportamento esperado: o agente do nó deve estar na fase inicial, que tenta constantemente associar o agente da cloud, esgotando as portas.

Para resolver o problema, pare a execução do wssdagent. Uma vez que o serviço está na fase inicial, pode impedi-lo de parar o serviço. Se for o caso, termine o processo antes de tentar parar o serviço.

1. Confirme que o wssdagent está em fase inicial.

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

2. Termine 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 os passos 1, 2 e 3 em cada nó do cluster do HCI que tem este problema.

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

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

1. Confirme que o cloudagent está operacional.

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

2. Execute o seguinte comando para corrigir o wssdagent:

   Repair-Moc
   

3. Assim que este comando for concluído, o wssdagent deverá estar no 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 a funcionar. No entanto, deixa os agentes do MOC num estado parado e as tentativas manuais de iniciar o agente não os ativam.

Passos para reproduzir

1. Instale a versão 1.1.36 do módulo AKS-HCI do PowerShell.
2. Atualize o AKS-HCI. Se a atualização falhar, o AKS-HCI regressa a 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

Erro de correspondência entre a versão do Aks-Hci e a versão do MOC

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

Erro de correspondência entre a versão Get-MocVersion e wssdcloudagent.exe

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 implementação

Execute o seguinte comando para mostrar o caminho da imagem do agente da cloud:

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"

Utilize o seguinte comando para mostrar o caminho da imagem do agente do nó: consulta de registo "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 mitigar 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, pode perder todas as taints, funções e etiquetas personalizadas que adicionou aos nós de trabalho. Uma vez que o AKS é um serviço gerido, a adição de taints, etiquetas e funções personalizadas quando efetuada fora dos cmdlets ou Windows Admin Center do PowerShell fornecidos não é suportada.

Para resolver este problema, execute o cmdlet New-AksHciNodePool para criar corretamente um conjunto de nós com taints para os nós de trabalho.

Se tiver criado um cluster de gestão, mas não tiver implementado um cluster de cargas de trabalho nos primeiros 60 dias, será impedido de criar um, uma vez que está agora fora da política. Nesta situação, quando executa Update-AksHci, o processo de atualização é bloqueado com o erro A aguardar que a implementação "Operador de Faturação AksHci" esteja pronta. Se executar Sync-AksHciBilling, este devolve um resultado bem-sucedido. No entanto, se executar Get-AksHciBillingStatus, o estado da ligação é OutofPolicy.

Se não implementar um cluster de cargas de trabalho há 60 dias, a faturação fica fora da política.

A única forma de corrigir este problema é reimplementar com uma instalação limpa.

Se os nós do Azure Stack HCI forem reiniciados um após o outro, algumas das máquinas virtuais perderão os vNICs ligados aos mesmos. Esta perda de vNICs faz com que as VMs percam a conectividade de rede e o cluster cai num estado incorreto.

Para Reproduzir

1. Reinicie um nó do Azure Stack HCI.
2. Aguarde que o nó conclua o reinício. O nó tem de ser marcado Up no cluster de ativação pós-falha.
3. Reinicie os outros nós.
4. Repita.

Comportamento esperado O estado do cluster deve estar em bom estado de funcionamento. Todas as VMs devem ter NICs anexados às mesmas.

Para resolver o problema, utilize os comandos do MOC para adicionar o vNIC à VM.

1. Obtenha o nome vNIC da VM.

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

ou

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

2. Ligue 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 desligar e ligar novamente. Segue-se o comando para desligar a vNIC.

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

ou

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

Pods bloqueados à espera que os pods estáticos tenham uma condição pronta.

Para libertar os pods e resolver este problema, deve reiniciar o kubelet. Para ver 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ó com falhas, execute o seguinte comando:

kubectl describe node <IP of the node>

Utilize o SSH para iniciar sessão no nó NotReady ao executar 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.

Normalmente, esta mensagem de erro ocorre quando o AKS no Azure Stack HCI é implementado num ambiente com um proxy configurado. Atualmente, Windows Admin Center não tem suporte para instalar módulos num ambiente proxy.

Para resolver este erro, configure o AKS no Azure Stack HCI com o comando proxy do PowerShell.

Ao atualizar clusters do Kubernetes com um Agente de Política Aberta (OPA), como o OPA GateKeeper, o processo pode bloquear e não conseguir concluir. Este problema pode ocorrer porque o agente de política está configurado para impedir a extração de imagens de contentor de registos privados.

Para resolver este problema, se atualizar clusters implementados com um OPA, certifique-se de que as políticas permitem extrair imagens de Azure Container Registry. Para uma atualização do AKS no Azure Stack HCI, deve adicionar o seguinte ponto final na lista da sua política: ecpacr.azurecr.io.

Executar uma atualização do SO num anfitrião com um AKS na implementação do Azure Stack HCI pode fazer com que a implementação introduza um estado incorreto e falhe no segundo dia de operações. Os Serviços NodeAgent do MOC podem não ser iniciados em anfitriões atualizados. Todas as chamadas do MOC para os nós falham.

Para reproduzir: quando atualiza um cluster com uma implementação do AKS existente do HCI para o HCIv2, uma operação do AKS, como, por New-AksHciCluster exemplo, pode falhar. A mensagem de erro indica que os nós do 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 este problema, inicie o wssdagent Moc NodeAgent Service nos nós afetados. Isto irá resolver o problema e colocar a implementação novamente num 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 para.

Execute o seguinte comando para verificar se existe um computador com PHASE a opção Eliminar que está a executar a versão anterior do Kubernetes a partir da qual está a atualizar.

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

Se existir um computador com PHASE a opção Eliminar e VERSION corresponder à versão anterior do Kubernetes, siga os seguintes passos.

Para resolver este problema, precisa das seguintes informações:

1. Versão do Kubernetes para a qual está a atualizar o cluster de cargas de trabalho.
2. Endereço IP do nó que está bloqueado.

Para encontrar estas informações, execute o seguinte cmdlet e comando. Por predefinição, o cmdlet Get-AksHciCredential escreve o kubeconfig em ~/.kube/config. Se especificar uma localização diferente para o kubeconfig do cluster de carga de trabalho ao chamar Get-AksHciCredential, terá de fornecer essa localização 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 de ser corrigido deve mostrar STATUSReady,SchedulingDisabled. Se vir um nó com este estado, utilize o INTERNAL-IP deste nó como o valor do endereço IP no seguinte comando abaixo. Utilize a versão do Kubernetes para a qual está a atualizar como o valor da versão; deve corresponder o VERSION valor do nó com ROLEScontrol-plane,master. Certifique-se de que inclui o valor completo da versão do Kubernetes, incluindo , vpor 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 eliminados e a atualização irá continuar.

Executar uma atualização do SO num anfitrião com um AKS na implementação do Azure Stack HCI pode fazer com que a implementação introduza um estado incorreto, o que torna o servidor de API do cluster de gestão inacessível e falha no segundo dia de operações. O kube-vip pod não pode aplicar a configuração VIP à interface e, como resultado, o VIP está inacessível.

Para reproduzir: atualize um cluster com uma implementação do AKS HCI existente do HCI para o HCIv2. Em seguida, experimente executar comandos que tentam aceder ao cluster de gestão, como Get-AksHciCluster. Todas as operações que tentam aceder ao cluster de gestão 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 este problema: reinicie o kube-vip contentor para colocar a implementação novamente num bom estado.

1. Obtenha o ID do kube-vip contentor:

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

O resultado deve ter um aspeto semelhante ao seguinte, sendo o ID do contentor o primeiro valor 4a49a5158a5f8. Por exemplo:

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

1. Reinicie o contentor Reiniciar:

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

Esta mensagem de estado é apresentada ao executar o cmdlet do PowerShell Update-AksHci .

Reveja as seguintes causas para resolver o problema:

• Motivo um: durante a atualização do Operador de Faturação do AksHci, o operador marcou-se incorretamente como fora da política. Para resolver este problema, abra uma nova janela do PowerShell e execute Sync-AksHciBilling. Deverá ver a operação de faturação continuar nos próximos 20 a 30 minutos.

• Motivo dois: a VM do cluster de gestão pode estar sem memória, o que faz com que o servidor de API seja inacessível e torna todos os comandos de Get-AksHciCluster, faturação e atualização excedido. Como solução, defina a VM do cluster de gestão para 32 GB no Hyper-V e reinicie-a.

• Motivo três: o Operador de Faturação do AksHci pode estar sem espaço de armazenamento, o que se deve a um erro nas definições de configuração do MICROSOFT SQL. A falta de espaço de armazenamento pode estar a fazer com que a atualização deixe de responder. Para resolver este problema, redimensione manualmente o pod pvc de faturação com os seguintes passos.

  1. Execute o seguinte comando para editar as definiçõ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 ficheiro YAML, edite a linha de armazenamento de 100Mi para 5Gi:

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

  3. Verifique o estado da implementação de faturação com o seguinte comando:

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

Quando atualiza clusters do AKS no Azure Stack HCI Atualização de fevereiro de 2022 para a Atualização de abril de 2022, a atualização pode estar bloqueada durante um período de tempo indefinido. Pode haver pods bloqueados no Terminating estado ou CrashLoopBackoff .

Poderá ver que alguns dos recursos do suplemento CSI do AksHci estão em falta. Estes pods de recursos implementados com o csi-akshcicsi-controller ou do csi-akshcicsi-node daemonset.

O suplemento CSI do AksHci na Atualização de fevereiro de 2022 continha uma alteração à especificação do controlador CSI que, por vezes, pode deixar os recursos do suplemento num estado sem resposta durante a atualização. O controlador .spec.fsGroupPolicy CSI foi definido para um novo valor, apesar de ser um campo imutável. Uma vez que o campo é imutável, a especificação do controlador não é atualizada. Uma consequência disto é que os outros recursos de suplementos CSI do AksHci podem não ser totalmente reconciliados. Todos os recursos csi seriam recriados.

Para resolver manualmente o problema, o controlador CSI pode ser eliminado manualmente. Depois de o remover, o operador da cloud reconcilia o suplemento CSI do AksHci dentro de 10 minutos e recria o controlador juntamente com os restantes recursos de suplemento em falta.

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

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

Atualize o browser para corrigir este problema.

A compilação de 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 de 1.0.1.10628 de junho para a versão de 1.0.2.10723 de julho foi melhorado para limpar os segredos adicionais 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 ocorrer este problema, execute os seguintes passos:

1. Guarde o script abaixo como um ficheiro com o nome 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 com o ficheiro fix_secret_leak.ps1 que guardou:

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

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

      Update-AksHci
   

Passos seguintes

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

Se continuar a deparar-se com problemas quando estiver a utilizar o AKS Arc, pode registar erros através do GitHub.