Risolvere i problemi durante l'aggiornamento di AKS Arc

Le versioni precedenti di PowerShell non vengono rimosse.

Per risolvere questo problema, è possibile eseguire questo script per disinstallare le versioni precedenti di PowerShell.

Dopo aver aggiornato o ridimensionato il cluster di destinazione, il pod di rinnovo del certificato è ora in stato di arresto anomalo. Si prevede un file di tatuaggio yaml certificato dal percorso /etc/Kubernetes/pki. Il file di configurazione è presente nelle macchine virtuali del nodo del piano di controllo, ma non nelle macchine virtuali del nodo di lavoro.

Per risolvere questo problema, copiare manualmente il file di tatuaggio del certificato dal nodo del piano di controllo a ognuno dei nodi di lavoro.

1. Copiare il file dalla macchina virtuale del piano di controllo nella directory corrente del computer 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. Copiare il file dal computer host alla macchina virtuale del nodo di lavoro.

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

3. Impostare le informazioni sul proprietario e sul gruppo su questo file alla radice se non è già impostato su radice.

   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. Ripetere i passaggi 2 e 3 per ognuno dei nodi di lavoro.

Quando un cluster non è stato aggiornato per più di 60 giorni, l'agente del nodo non viene avviato durante il riavvio dell'agente del nodo a causa della scadenza del token. Questo errore causa l'esecuzione degli agenti nella fase iniziale. I tentativi continui di partecipare al cloudagent possono esaurire la fornitura di porte nell'host. Lo stato per il comando seguente è Avvio.

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

Comportamento previsto: l'agente del nodo deve trovarsi nella fase iniziale, che tenta costantemente di aggiungere l'agente cloud, esaurendo le porte.

Per risolvere il problema, arrestare l'esecuzione di wssdagent. Poiché il servizio si trova nella fase iniziale, può impedire l'arresto del servizio. In tal caso, eliminare il processo prima di tentare di arrestare il servizio.

1. Verificare che wssdagent sia in fase iniziale.

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

2. Uccidere il processo.

   kill -Name wssdagent -Force
   

3. Consente di arrestare il servizio.

   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. Ripetere i passaggi 1, 2 e 3 in ogni nodo del cluster HCI con questo problema.

2. Dopo aver confermato che wssdagent non è in esecuzione, avviare il cloudagent se non è in esecuzione.

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

1. Verificare che il cloudagent sia attivo ed in esecuzione.

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

2. Eseguire il comando seguente per correggere wssdagent:

   Repair-Moc
   

3. Al termine di questo comando, l'oggetto wssdagent deve essere in esecuzione.

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

Quando AKS-HCI non riesce a eseguire l'aggiornamento dalla versione di maggio alla versione di giugno, l'aspettativa è che il servizio Azure Kubernetes-HCI dovrebbe tornare alla versione di maggio e continuare a funzionare. Ma lascia gli agenti MOC in uno stato arrestato e i tentativi manuali di avviare l'agente non li attivano.

Passaggi per riprodurre il bug

1. Installare il modulo PowerShell del servizio Azure Kubernetes-HCI versione 1.1.36.
2. Aggiornare AKS-HCI. Se l'aggiornamento ha esito negativo, il servizio Azure Kubernetes-HCI torna a maggio, ma gli agenti MOC sono inattivo.

Comportamento previsto

Se l'aggiornamento Aks-Hci ha esito negativo, l'aspettativa è che AksHci ripristina la versione precedente e continua a funzionare senza problemi.

Sintomi

Mancata corrispondenza tra versione Aks-Hci e versione moC

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

Mancata corrispondenza tra Get-MocVersion e wssdcloudagent.exe versione

Get-MocVersion indica che la build di giugno viene installata mentre la versione wssdcloudagent.exe indica che la build di maggio è installata.

Il percorso immagine dei servizi agente MOC ha il parametro ID distribuzione

Eseguire il comando seguente per visualizzare il percorso dell'immagine per l'agente cloud:

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

Output di esempio

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

Usare il comando seguente per visualizzare il percorso dell'immagine per l'agente del nodo: eseguire una query reg "HKLM\System\CurrentControlSet\Services\wssdagent"

Output di esempio

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

Per attenuare il problema, eseguire i cmdlet di PowerShell seguenti:

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'

Quando si esegue l'aggiornamento, è possibile perdere tutte le etichette, i ruoli e le etichette personalizzate aggiunte ai nodi di lavoro. Poiché il servizio Azure Kubernetes è un servizio gestito, l'aggiunta di taints, etichette e ruoli personalizzati quando vengono eseguiti all'esterno dei cmdlet di PowerShell forniti o Windows Admin Center non è supportato.

Per risolvere questo problema, eseguire il cmdlet New-AksHciNodePool per creare correttamente un pool di nodi con taints per i nodi di lavoro.

Se è stato creato un cluster di gestione, ma non è stato distribuito un cluster del carico di lavoro nei primi 60 giorni, verrà impedito di crearne uno, perché è ora out-of-policy. In questa situazione, quando si esegue Update-AksHci, il processo di aggiornamento viene bloccato con l'errore In attesa dell'operatore di fatturazione AksHci della distribuzione da preparare. Se si esegue Sync-AksHciBilling, restituisce l'output corretto. Tuttavia, se si esegue Get-AksHciBillingStatus, lo stato della connessione è OutofPolicy.

Se non è stato distribuito un cluster del carico di lavoro in 60 giorni, la fatturazione viene interrotta dai criteri.

L'unico modo per risolvere questo problema consiste nel ridistribuire con un'installazione pulita.

Se i nodi HCI di Azure Stack vengono riavviati uno dopo l'altro, alcune delle macchine virtuali perdono le macchine virtuali collegate. Questa perdita di vNIC causa la perdita della connettività di rete e il cluster rientra in uno stato non valido.

Riproduzione

1. Riavviare un nodo HCI di Azure Stack.
2. Attendere il completamento del riavvio del nodo. Il nodo deve essere contrassegnato Up nel cluster di failover.
3. Riavviare gli altri nodi.
4. Repeat

Comportamento previsto Lo stato del cluster deve essere integro. Tutte le macchine virtuali devono essere associate alle schede di interfaccia di rete.

Per risolvere il problema, usare i comandi MOC per aggiungere la scheda di interfaccia di rete virtuale alla macchina virtuale.

1. Ottenere il nome della scheda di interfaccia di rete virtuale per la macchina virtuale.

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

oppure

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

2. Connettere la scheda di rete virtuale alla macchina virtuale.

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

oppure

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

3. Se il comando di connessione della scheda di rete virtuale ha esito negativo, provare a disconnettersi e connettersi di nuovo. Di seguito è riportato il comando per la disconnessione della scheda di rete virtuale.

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

oppure

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

Pod bloccati in attesa di pod statici per avere una condizione pronta.

Per rilasciare i pod e risolvere questo problema, è necessario riavviare kubelet. Per visualizzare il nodo NotReady con i pod statici, eseguire il comando seguente:

kubectl get nodes -o wide

Per ottenere altre informazioni sul nodo di errore, eseguire il comando seguente:

kubectl describe node <IP of the node>

Usare SSH per accedere al nodo NotReady eseguendo il comando seguente:

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

Quindi, per riavviare kubelet, eseguire il comando seguente:

/etc/.../kubelet restart

Quando si esegue un aggiornamento in Windows Admin Center, si è verificato l'errore seguente:

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.

Questo messaggio di errore si verifica in genere quando il servizio Azure Kubernetes in Azure Stack HCI viene distribuito in un ambiente con un proxy configurato. Attualmente, Windows Admin Center non dispone del supporto per installare i moduli in un ambiente proxy.

Per risolvere questo errore, configurare il servizio Azure Kubernetes in Azure Stack HCI usando il comando proxy di PowerShell.

Quando si aggiornano i cluster Kubernetes con un OPA (Open Policy Agent), ad esempio OPA GateKeeper, il processo può essere bloccato e non è possibile completare. Questo problema può verificarsi perché l'agente dei criteri è configurato per impedire il pull delle immagini del contenitore da registri privati.

Per risolvere questo problema, se si aggiornano i cluster distribuiti con un'OPA, assicurarsi che i criteri consentano il pull di immagini da Registro Azure Container. Per un aggiornamento del servizio Azure Kubernetes in Azure Stack HCI, è necessario aggiungere l'endpoint seguente nell'elenco dei criteri: ecpacr.azurecr.io.

L'esecuzione di un aggiornamento del sistema operativo in un host con un servizio Azure Kubernetes nella distribuzione HCI di Azure Stack può causare l'immissione di uno stato non valido e l'esito negativo delle due operazioni del giorno. I servizi NodeAgent MOC potrebbero non essere avviati negli host aggiornati. Tutte le chiamate MOC ai nodi hanno esito negativo.

Per riprodurre: quando si aggiorna un cluster con una distribuzione del servizio Azure Kubernetes esistente da HCI a HCIv2, un'operazione New-AksHciCluster del servizio Azure Kubernetes potrebbe non riuscire. Il messaggio di errore indica che i nodi MOC sono OutOfCapacity. Ad esempio:

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]

Per risolvere questo problema, avviare il servizio Moc NodeAgent wssdagent nei nodi interessati. Questo risolverà il problema e restituirà la distribuzione a uno stato valido. Eseguire il comando seguente:

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

Dopo aver eseguito Update-AksHciCluster, il processo di aggiornamento si blocca.

Eseguire il comando seguente per verificare se è presente un computer con PHASE Eliminazione che esegue la versione precedente di Kubernetes da cui si esegue l'aggiornamento.

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

Se è presente un computer con PHASE Eliminazione e VERSION corrispondenza della versione precedente di Kubernetes, procedere con la procedura seguente.

Per risolvere questo problema, sono necessarie le informazioni seguenti:

1. Versione di Kubernetes a cui si sta aggiornando il cluster del carico di lavoro.
2. Indirizzo IP del nodo bloccato.

Per trovare queste informazioni, eseguire il cmdlet e il comando seguenti. Per impostazione predefinita, il cmdlet Get-AksHciCredential scrive kubeconfig in ~/.kube/config. Se si specifica una posizione diversa per il cluster del carico di lavoro kubeconfig quando si chiama Get-AksHciCredential, sarà necessario specificare tale posizione per kubectl come un altro argomento. Ad esempio: kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

Il nodo che deve essere risolto deve visualizzare STATUSReady,SchedulingDisabled. Se viene visualizzato un nodo con questo stato, usare il valore di questo nodo come valore dell'indirizzo INTERNAL-IP IP nel comando seguente. Usare la versione kubernetes che si sta aggiornando come valore della versione; deve corrispondere al VERSION valore del nodo con ROLEScontrol-plane,master. Assicurarsi di includere il valore completo per la versione kubernetes, incluso , vad esempio v1.22.6.

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

Dopo aver eseguito questo comando ssh, i nodi rimanenti con la versione precedente di Kubernetes devono essere eliminati e l'aggiornamento procederà.

L'esecuzione di un aggiornamento del sistema operativo in un host con un servizio Azure Kubernetes nella distribuzione HCI di Azure Stack può causare l'immissione di uno stato non valido, che esegue il rendering del server API del cluster di gestione non raggiungibile e non riesce le operazioni del giorno due. Il kube-vip pod non può applicare la configurazione VIP all'interfaccia e, di conseguenza, l'indirizzo VIP non è raggiungibile.

Per riprodurre: aggiornare un cluster con una distribuzione HCI del servizio Azure Kubernetes esistente da HCI a HCIv2. Provare quindi a eseguire i comandi che tentano di raggiungere il cluster di gestione, Get-AksHciClusterad esempio . Tutte le operazioni che tentano di raggiungere il cluster di gestione non riescono con errori, ad esempio:

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)]

Per risolvere questo problema: riavviare il contenitore per ripristinare lo kube-vip stato della distribuzione.

1. Ottenere l'ID kube-vip contenitore:

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

L'output dovrebbe essere simile al seguente, con l'ID contenitore che rappresenta il primo valore 4a49a5158a5f8. Ad esempio:

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

1. Riavviare il contenitore:

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

Questo messaggio di stato viene visualizzato quando si esegue il cmdlet Update-AksHci PowerShell.

Esaminare le cause radice seguenti per risolvere il problema:

• Motivo uno: durante l'aggiornamento dell'operatore di fatturazione AksHci, l'operatore si è contrassegnato in modo errato come fuori criterio. Per risolvere questo problema, aprire una nuova finestra di PowerShell ed eseguire Sync-AksHciBilling. Verrà visualizzata l'operazione di fatturazione entro i successivi 20-30 minuti.

• Motivo due: la macchina virtuale del cluster di gestione potrebbe non essere in memoria, che causa l'impossibilità del server API e effettua tutti i comandi da Get-AksHciCluster, fatturazione e aggiornamento, timeout. Come soluzione alternativa, impostare la macchina virtuale del cluster di gestione su 32 GB in Hyper-V e riavviarla.

• Motivo tre: l'operatore di fatturazione AksHci potrebbe non essere disponibile nello spazio di archiviazione, che è dovuto a un bug nelle impostazioni di configurazione di Microsoft SQL. La mancanza di spazio di archiviazione potrebbe causare l'arresto dell'aggiornamento. Per risolvere questo problema, ridimensionare manualmente il pod pvc di fatturazione usando la procedura seguente.

  1. Eseguire il comando seguente per modificare le impostazioni del pod:

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

  2. Quando si apre Il Blocco note o un altro editor con un file YAML, modificare la riga per l'archiviazione da 100Mi a 5Gi:

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

  3. Controllare lo stato della distribuzione di fatturazione usando il comando seguente:

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

Quando si aggiornano i cluster dal servizio Azure Kubernetes in Azure Stack HCI febbraio 2022 Update all'aggiornamento di aprile 2022, l'aggiornamento potrebbe essere bloccato per un periodo di tempo indefinito. Potrebbero esserci pod bloccati nello Terminating stato o CrashLoopBackoff .

È possibile notare che alcune delle risorse addon di AksHci CSI sono mancanti. Questi pod di risorse distribuiti usando o csi-akshcicsi-controller dal csi-akshcicsi-node daemonset.

L'addon AksHci CSI nell'aggiornamento di febbraio 2022 contiene una modifica alla specifica del driver CSI che a volte può lasciare le risorse dell'addon in uno stato non rispondente durante l'aggiornamento. Il driver .spec.fsGroupPolicy CSI è stato impostato su un nuovo valore anche se è un campo non modificabile. Poiché il campo non è modificabile, la specifica del driver non viene aggiornata. Una conseguenza di questo è che le altre risorse AksHci CSI addon potrebbero non essere completamente riconciliate. Tutte le risorse CSI verranno ricreate.

Per risolvere manualmente il problema, il driver CSI può essere eliminato manualmente. Dopo averlo rimosso, l'operatore cloud riconcilia l'addon AksHci CSI entro i 10 minuti e ricreare il driver insieme al resto delle risorse di addon mancanti.

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

Dopo un aggiornamento riuscito, il dashboard di aggiornamento Windows Admin Center mostra ancora la versione precedente.

Aggiornare il browser per risolvere questo problema.

La build del servizio Azure Kubernetes di giugno 1.10628 crea un numero eccessivo di segreti di configurazione Kubernetes nel cluster. Il percorso di aggiornamento dalla versione di giugno 1.0.1.10628 alla versione 1.0.2.10723 è stata migliorata per pulire i segreti kubernetes aggiuntivi. Tuttavia, in alcuni casi durante l'aggiornamento, i segreti non sono ancora stati puliti e quindi il processo di aggiornamento ha esito negativo.

Se si verifica questo problema, eseguire la procedura seguente:

1. Salvare lo script seguente come file denominato 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. Eseguire quindi il comando seguente usando il file difix_secret_leak.ps1 salvato:

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

3. Infine, usare il comando powerShell seguente per ripetere il processo di aggiornamento:

      Update-AksHci
   

Passaggi successivi

• Panoramica della risoluzione dei problemi
• Problemi di installazione e errori
• Windows Admin Center problemi noti

Se si continuano a verificarsi problemi quando si usa AKS Arc, è possibile segnalare bug tramite GitHub.