Risolvere i problemi durante l'aggiornamento di Arc del servizio Azure Kubernetes

Le versioni precedenti di PowerShell non vengono rimosse.

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

Dopo l'aggiornamento o la scalabilità verticale del cluster di destinazione, il pod di rinnovo del certificato si trova ora in uno stato di ciclo di arresto anomalo del sistema. Si aspetta un file di tatuaggio yaml del 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 tatuaggio del certificato dal nodo del piano di controllo in 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 su root se non è già impostato su 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. 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 un riavvio dell'agente del nodo a causa della scadenza del token. Questo errore fa sì che gli agenti siano nella fase iniziale. I tentativi continui di join dell'agente cloud 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 essere 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 è in fase di avvio, potrebbe impedire l'arresto del servizio. In tal caso, terminare il processo prima di tentare di arrestare il servizio.

1. Verificare che wssdagent sia in fase di avvio.

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

2. Terminare il processo.

   kill -Name wssdagent -Force
   

3. 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 che presenta questo problema.

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

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

1. Verificare che cloudagent sia operativo.

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

2. Eseguire il comando seguente per correggere wssdagent:

   Repair-Moc
   

3. Al termine di questo comando, lo stato di wssdagent deve essere in esecuzione.

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

Quando il servizio Azure Kubernetes-HCI non riesce ad eseguire l'aggiornamento dalla versione di maggio alla versione di giugno, l'aspettativa è che il servizio Azure Kubernetes-HCI debba 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 AKS-HCI versione 1.1.36.
2. Aggiornare il servizio Azure Kubernetes-HCI. Se l'aggiornamento non riesce, il servizio Azure Kubernetes-HCI torna a maggio, ma gli agenti MOC sono inattivo.

Comportamento previsto

Se l'aggiornamento di Aks-Hci non riesce, si prevede che AksHci venga ripristinato alla versione precedente e continui a funzionare senza problemi.

Sintomi

Mancata corrispondenza tra la versione di Aks-Hci e la 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 è installata mentre la versione wssdcloudagent.exe indica che è installata la build di maggio.

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: reg query "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'

Durante l'aggiornamento, è possibile che tutti i contenitori, i ruoli e le etichette personalizzati aggiunti ai nodi di lavoro vadano persi. Poiché il servizio Azure Kubernetes è un servizio gestito, l'aggiunta di contenitori, 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 containts 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, non sarà possibile crearne uno perché è ora fuori criterio. In questo caso, quando si esegue Update-AksHci, il processo di aggiornamento viene bloccato con l'errore In attesa della distribuzione "Operatore di fatturazione AksHci" per essere pronti. Se si esegue Sync-AksHciBilling, viene restituito l'output riuscito. 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 esce dai criteri.

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

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

Riproduzione

1. Riavviare un nodo Azure Stack HCI.
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 . A tutte le macchine virtuali devono essere collegate 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

or

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

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

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

or

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

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

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

or

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

I pod sono bloccati in attesa che i pod statici abbiano 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 difettoso, 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 supporta l'installazione di moduli in un ambiente proxy.

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

Quando si aggiornano i cluster Kubernetes con un agente Open Policy (OPA), ad esempio OPA GateKeeper, il processo potrebbe bloccarsi e non essere in grado di completare. Questo problema può verificarsi perché l'agente 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 delle 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 di Azure Stack HCI può causare l'immissione di uno stato non valido e l'esito negativo delle due operazioni del giorno. L'avvio dei servizi NodeAgent MOC potrebbe non riuscire 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 NodeAgent wssdagent nei nodi interessati. In questo modo il problema verrà risolto e la distribuzione verrà restituita a uno stato valido. Esegui questo comando:

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 i passaggi seguenti.

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 mostrare STATUS Ready,SchedulingDisabled. Se viene visualizzato un nodo con questo stato, usare di INTERNAL-IP questo nodo come valore dell'indirizzo IP nel comando seguente. Usare la versione di Kubernetes a cui si sta eseguendo l'aggiornamento come valore della versione; deve corrispondere al VERSION valore del nodo con ROLES control-plane,master. Assicurarsi di includere il valore completo per la versione di Kubernetes, incluso v, ad 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'ingresso della distribuzione in uno stato non valido, che rende il server API del cluster di gestione non raggiungibile e non riesce al giorno due operazioni. 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 comandi che tentano di raggiungere il cluster di gestione, Get-AksHciClusterad esempio . Tutte le operazioni che tentano di raggiungere il cluster di gestione hanno esito negativo con errori quali:

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 kube-vip contenitore per riportare la distribuzione a uno stato valido.

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 come 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 di PowerShell Update-AksHci .

Esaminare le cause radice seguenti per risolvere il problema:

• Motivo uno: durante l'aggiornamento dell'operatore di fatturazione AksHci, l'operatore si è erroneamente contrassegnato come fuori criterio. Per risolvere questo problema, aprire una nuova finestra di PowerShell ed eseguire Sync-AksHciBilling. Si noterà che l'operazione di fatturazione continua entro i prossimi 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 rende tutti i comandi di 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, a causa di 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 seguendo questa procedura.

  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 il Blocco note o un altro editor viene aperto 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 della 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 aggiornamento di febbraio 2022 all'aggiornamento di aprile 2022, l'aggiornamento potrebbe essere bloccato per un periodo di tempo illimitato. Potrebbero esserci pod bloccati nello Terminating stato o CrashLoopBackoff .

Si noterà che alcune delle risorse addon CSI di AksHci sono mancanti. Questi pod di risorse distribuiti usando o csi-akshcicsi-controller dal csi-akshcicsi-node daemonset.

Il componente aggiuntivo AksHci CSI nell'aggiornamento di febbraio 2022 conteneva una modifica alla specifica del driver CSI che a volte può lasciare le risorse del componente aggiuntivo in uno stato non risponde 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, è possibile eliminare manualmente il driver CSI. Dopo averlo rimosso, l'operatore cloud riconcilia il componente aggiuntivo AksHci CSI entro 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 corretto, il dashboard di aggiornamento di Windows Admin Center mostra ancora la versione precedente.

Aggiornare il browser per risolvere il problema.

La build 1.0.1.10628 del servizio Azure Kubernetes in Azure Stack HCI crea un numero eccessivo di segreti di configurazione Kubernetes nel cluster. Il percorso di aggiornamento della versione 1.0.1.10628 della versione di giugno 1.0.2.10723 è stato migliorato per pulire i segreti Kubernetes aggiuntivi. Tuttavia, in alcuni casi durante l'aggiornamento, i segreti non sono stati ancora puliti e pertanto il processo di aggiornamento non riesce.

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 fix_secret_leak.ps1 salvato:

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

3. Usare infine il comando di PowerShell seguente per ripetere il processo di aggiornamento:

      Update-AksHci
   

Passaggi successivi

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

Se si continuano a verificarsi problemi quando si usa Il servizio Azure Kubernetes Arc, è possibile segnalare bug tramite GitHub.