Résoudre les problèmes lors de la mise à niveau d’AKS Arc

Les versions antérieures de PowerShell ne sont pas supprimées.

Pour contourner ce problème, vous pouvez exécuter ce script pour désinstaller les anciennes versions de PowerShell.

Après la mise à niveau ou la mise à l’échelle du cluster cible, le pod de renouvellement de certificat est désormais dans un état de boucle de blocage. Il attend un fichier yaml de marquage de certificat à partir du chemin /etc/Kubernetes/pki. Le fichier de configuration est présent dans les machines virtuelles du nœud de plan de contrôle, mais pas sur les machines virtuelles de nœud Worker.

Pour résoudre ce problème, copiez manuellement le fichier de tatouage de certificat du nœud du plan de contrôle vers chacun des nœuds Worker.

1. Copiez le fichier de la machine virtuelle du plan de contrôle vers le répertoire actif de votre machine hôte.

   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. Copiez le fichier de la machine hôte vers la machine virtuelle du nœud Worker.

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

3. Restaurez les informations de propriétaire et de groupe de ce fichier sur la racine si elles ne sont pas encore définies sur la racine.

   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. Répétez les étapes 2 et 3 pour chacun de vos nœuds Worker.

Lorsqu’un cluster n’a pas été mis à niveau depuis plus de 60 jours, l’agent de nœud ne parvient pas à démarrer pendant le redémarrage d’un agent de nœud en raison de l’expiration du jeton. Cet échec entraîne l’exécution des agents dans la phase de démarrage. Les tentatives continues de jointure du cloudagent peuvent épuiser l’approvisionnement des ports sur l’hôte. L’état de la commande suivante est De démarrage.

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

Comportement attendu : l’agent de nœud doit être dans la phase de démarrage, qui tente constamment de joindre l’agent cloud, épuisant les ports.

Pour résoudre le problème, arrêtez l’exécution de wssdagent. Étant donné que le service est en phase de démarrage, il peut vous empêcher d’arrêter le service. Si c’est le cas, supprimez le processus avant de tenter d’arrêter le service.

1. Vérifiez que wssdagent est en phase de démarrage.

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

2. Tuez le processus.

   kill -Name wssdagent -Force
   

3. Arrête le service.

   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. Répétez les étapes 1, 2 et 3 sur chaque nœud du cluster HCI qui a ce problème.

2. Après avoir confirmé que wssdagent n’est pas en cours d’exécution, démarrez le cloudagent s’il n’est pas en cours d’exécution.

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

1. Vérifiez que le cloudagent est opérationnel.

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

2. Exécutez la commande suivante pour corriger wssdagent :

   Repair-Moc
   

3. Une fois cette commande exécutée, wssdagent doit être dans l’état En cours d’exécution.

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

Lorsque AKS-HCI ne parvient pas à effectuer la mise à niveau de la version de mai à la version de juin, l’attente est que AKS-HCI doit revenir à la version de mai et continuer à fonctionner. Mais il laisse les agents MOC dans un état arrêté et les tentatives manuelles de démarrage de l’agent ne les activent pas.

Opérations à reproduire

1. Installez le module PowerShell AKS-HCI version 1.1.36.
2. Mettez à niveau AKS-HCI. Si la mise à niveau échoue, AKS-HCI revient à mai, mais les agents MOC sont arrêtés.

Comportement attendu

Si la mise à niveau d’Aks-Hci échoue, l’attente est que AksHci revient à la version précédente et continue à fonctionner sans aucun problème.

Symptômes

Incompatibilité entre la version d’Aks-Hci et la version MOC

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

Incompatibilité entre Get-MocVersion et wssdcloudagent.exe version

Get-MocVersion indique que la build de juin est installée pendant que la version wssdcloudagent.exe indique que la build mai est installée.

Le chemin d’accès à l’image des services de l’agent MOC a un paramètre d’ID de déploiement

Exécutez la commande suivante pour afficher le chemin d’accès à l’image de l’agent cloud :

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

Exemple de sortie

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

Utilisez la commande suivante pour afficher le chemin d’accès de l’image pour l’agent de nœud : requête reg « HKLM\System\CurrentControlSet\Services\wssdagent »

Exemple de sortie

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

Pour atténuer le problème, exécutez les applets de commande PowerShell suivantes :

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'

Lors de la mise à niveau, vous risquez de perdre l'ensemble des aversions, rôles et étiquettes personnalisés que vous avez ajoutés à vos nœuds Worker. Étant donné qu’AKS est un service géré, l’ajout de teintes personnalisées, d’étiquettes et de rôles lorsqu’ils sont effectués en dehors des applets de commande PowerShell fournies ou windows Admin Center n’est pas pris en charge.

Pour contourner ce problème, exécutez la cmdlet New-AksHciNodePool pour créer correctement un pool de nœuds avec des aversions pour vos nœuds Worker.

Si vous avez créé un cluster de gestion mais que vous n’avez pas déployé de cluster de charge de travail au cours des 60 premiers jours, vous êtes bloqué de en créer un, car il est désormais hors stratégie. Dans ce cas, lorsque vous exécutez Update-AksHci, le processus de mise à jour est bloqué avec l'erreur En attente que le déploiement de l'« opérateur de facturation AksHci » soit prêt. Si vous exécutez Sync-AksHciBilling, elle retourne une sortie réussie. Toutefois, si vous exécutez Get-AksHciBillingStatus, l’état de connexion est OutofPolicy.

Si vous n’avez pas déployé de cluster de charges de travail dans les 60 jours, la facturation est hors stratégie.

La seule façon de résoudre ce problème est de procéder à un nouveau déploiement pour obtenir une installation propre.

Si les nœuds Azure Stack HCI sont redémarrés l’un après l’autre, certaines des machines virtuelles perdent les cartes réseau virtuelles attachées. Cette perte de cartes réseau virtuelles entraîne la perte de la connectivité réseau des machines virtuelles, et le cluster tombe dans un état incorrect.

Opérations à reproduire

1. Redémarrez un nœud Azure Stack HCI.
2. Attendez que le nœud termine le redémarrage. Le nœud doit être marqué Up dans le cluster de basculement.
3. Redémarrez les autres nœuds.
4. répétez.

Comportement attendu L’état du cluster doit être sain. Toutes les machines virtuelles doivent avoir des cartes réseau attachées.

Pour résoudre le problème, utilisez les commandes MOC pour ajouter la carte réseau virtuelle à la machine virtuelle.

1. Obtenez le nom de la carte réseau virtuelle pour la machine virtuelle.

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

or

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

2. Connectez la carte réseau virtuelle à la machine virtuelle.

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

or

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

3. Si la commande de connexion de carte réseau virtuelle échoue, essayez de vous déconnecter et de vous reconnecter. Voici la commande pour la déconnexion de la carte réseau virtuelle.

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

or

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

Les pods bloqués en attendant que les pods statiques aient une condition prête.

Pour libérer les pods et résoudre ce problème, vous devez redémarrer kubelet. Pour afficher le nœud NotReady avec les pods statiques, exécutez la commande suivante :

kubectl get nodes -o wide

Pour obtenir plus d’informations sur le nœud défectueux, exécutez la commande suivante :

kubectl describe node <IP of the node>

Utilisez SSH pour vous connecter au nœud NotReady en exécutant la commande suivante :

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

Ensuite, pour redémarrer kubelet, exécutez la commande suivante :

/etc/.../kubelet restart

Lors de l’exécution d’une mise à niveau dans Windows Admin Center, l’erreur suivante s’est produite :

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.

Ce message d’erreur se produit généralement lorsque AKS sur Azure Stack HCI est déployé dans un environnement pour lequel un proxy est configuré. Actuellement, Windows Admin Center ne prend pas en charge l’installation de modules dans un environnement proxy.

Pour résoudre cette erreur, configurez AKS sur Azure Stack HCI à l’aide de la commande PowerShell de proxy.

Lors de la mise à niveau de clusters Kubernetes avec un agent OPA (Open Policy Agent), tel que OPA GateKeeper, le processus peut se bloquer et ne peut pas être terminé. Ce problème peut se produire parce que l'agent de stratégie est configuré pour empêcher l'extraction d'images de conteneur à partir de registres privés.

Pour résoudre ce problème, si vous mettez à niveau des clusters déployés avec un agent OPA, assurez-vous que vos stratégies autorisent l'extraction d'images à partir d'Azure Container Registry. Pour une mise à niveau d'AKS sur Azure Stack HCI, vous devez ajouter le point de terminaison suivant dans la liste de votre stratégie : ecpacr.azurecr.io.

L’exécution d’une mise à jour de système d’exploitation sur un hôte avec un déploiement AKS sur Azure Stack HCI peut mettre le déploiement dans un état incorrect et entraîner l’échec des opérations du jour 2. Les services MOC NodeAgent peuvent ne pas démarrer sur les hôtes mis à jour. Tous les appels MOC aux nœuds échouent.

Pour reproduire : lorsque vous mettez à jour un cluster avec un déploiement AKS existant de HCI vers HCIv2, une opération AKS telle que New-AksHciCluster peut échouer. Le message d’erreur indique que les nœuds MOC sont OutOfCapacity. Par exemple :

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]

Pour résoudre ce problème, démarrez le service MOC NodeAgent wssdagent sur les nœuds affectés. Cela permet de résoudre le problème et de ramener le déploiement à un état correct. Exécutez la commande suivante :

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

Après avoir exécuté Update-AksHciCluster, le processus de mise à niveau se bloque.

Exécutez la commande suivante pour vérifier s’il existe une machine avec PHASE suppression qui exécute la version de Kubernetes précédente à partir de laquelle vous effectuez la mise à niveau.

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

S’il existe une machine avec PHASE suppression et VERSION correspondance de la version de Kubernetes précédente, procédez comme suit.

Pour résoudre ce problème, vous avez besoin des informations suivantes :

1. Version de Kubernetes vers laquelle vous mettez à niveau votre cluster de charge de travail.
2. Adresse IP du nœud bloqué.

Pour trouver ces informations, exécutez l’applet de commande et la commande suivantes. Par défaut, l’applet de commande Get-AksHciCredential écrit le kubeconfig dans ~/.kube/config. Si vous spécifiez un autre emplacement pour votre cluster de charge de travail kubeconfig lors de l’appel Get-AksHciCredential, vous devez fournir cet emplacement à kubectl en tant qu’autre argument. Par exemple : kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

Le nœud qui doit être résolu doit afficher STATUS Ready,SchedulingDisabled. Si vous voyez un nœud avec cet état, utilisez le INTERNAL-IP nœud comme valeur d’adresse IP dans la commande suivante ci-dessous. Utilisez la version kubernetes vers laquelle vous effectuez une mise à niveau en tant que valeur de version ; cela doit correspondre à la VERSION valeur du nœud avec ROLES control-plane,master. Veillez à inclure la valeur complète de la version de Kubernetes, notamment le v, par exemple v1.22.6.

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

Après avoir exécuté cette commande ssh, les nœuds restants avec l’ancienne version de Kubernetes doivent être supprimés et la mise à niveau se poursuit.

L’exécution d’une mise à jour du système d’exploitation sur un hôte avec un déploiement AKS sur Azure Stack HCI peut entraîner le déploiement à entrer dans un état incorrect, ce qui rend le serveur d’API du cluster d’administration inaccessible et échoue les deux opérations du jour 2. Le kube-vip pod ne peut pas appliquer la configuration d’adresse IP virtuelle à l’interface, et par conséquent, l’adresse IP virtuelle est inaccessible.

Pour reproduire : Mettez à jour un cluster avec un déploiement AKS HCI existant de HCI vers HCIv2. Essayez ensuite d’exécuter des commandes qui tentent d’atteindre le cluster de gestion, par Get-AksHciClusterexemple . Toutes les opérations qui tentent d’atteindre le cluster de gestion échouent avec des erreurs telles que :

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

Pour résoudre ce problème : redémarrez le conteneur kube-vip pour ramener le déploiement à un état correct.

1. Obtenez l’ID de conteneur kube-vip :

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

La sortie doit ressembler à ceci, l’ID de conteneur étant la première valeur 4a49a5158a5f8. Par exemple :

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

1. Redémarrez le conteneur :

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

Ce message d’état s’affiche pendant l’exécution de l’applet de commande PowerShell Update-AksHci.

Passez en revue les causes racines suivantes pour résoudre le problème :

• Motif 1 : Lors de la mise à jour de l’opérateur de facturation AksHci, l’opérateur s’est correctement marqué comme hors stratégie. Pour résoudre ce problème, ouvrez une nouvelle fenêtre PowerShell et exécutez Sync-AksHciBilling. L’opération de facturation devrait se poursuivre dans les 20-30 prochaines minutes.

• Raison 2 : la machine virtuelle du cluster de gestion peut être hors mémoire, ce qui entraîne l’indisponibilité du serveur d’API et rend toutes les commandes à partir de Get-AksHciCluster, de facturation et de mise à jour, d’expiration du délai d’attente. Pour contourner ce problème, définissez la machine virtuelle du cluster de gestion sur 32 Go dans Hyper-V et redémarrez-la.

• Raison Trois : l’opérateur de facturation AksHci a peut-être un espace de stockage insuffisant, lié à un bogue dans les paramètres de configuration Microsoft SQL. Le manque d’espace de stockage peut être à l’origine de l’absence de réponse de la mise à niveau. Pour contourner ce problème, redimensionnez manuellement le pod de facturation pvc en procédant comme suit.

  1. Exécutez la commande suivante pour modifier les paramètres du pod :

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

  2. Une fois que le fichier YAML s’est ouvet dans le Bloc-notes ou un autre éditeur, modifiez la ligne relative au stockage en faisant passer sa valeur de 100Mi à 5Gi :

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

  3. Vérifiez l’état du déploiement de la facturation à l’aide de la commande suivante :

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

Lorsque vous mettez à niveau des clusters à partir de la mise à jour AKS sur Azure Stack HCI février 2022 vers la mise à jour d’avril 2022, la mise à jour peut être bloquée pendant une période indéfinie. Il peut y avoir des pods bloqués dans l’état ou CrashLoopBackoff dans l’étatTerminating.

Vous pouvez voir que certaines des ressources du module complémentaire CSI AksHci sont manquantes. Ces pods de ressources déployés à l’aide csi-akshcicsi-node du csi-akshcicsi-controller ou du daemonset.

Le module complémentaire CSI AksHci dans la mise à jour de février 2022 contenait une modification de la spécification du pilote CSI qui peut parfois laisser les ressources du module complémentaire dans un état de non réponse pendant la mise à niveau. Le pilote CSI a été défini sur une nouvelle valeur, même s’il s’agit d’un .spec.fsGroupPolicy champ immuable. Étant donné que le champ est immuable, la spécification du pilote ne se met pas à jour. En conséquence, les autres ressources du module complémentaire CSI AksHci risquent de ne pas être entièrement réconciliées. Toutes les ressources CSI sont recréées.

Pour résoudre manuellement le problème, le pilote CSI peut être supprimé manuellement. Une fois que vous l’avez supprimé, l’opérateur cloud rapproche le module complémentaire CSI AksHci dans les 10 minutes et recrée le pilote avec le reste des ressources de complément manquantes.

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

Une fois la mise à niveau réussie, le tableau de bord de mise à jour de Windows Admin Center affiche toujours la version précédente.

Actualisez le navigateur pour résoudre ce problème.

La build 1.0.1.10628 de juin de AKS sur Azure Stack HCI crée un nombre excessif de secrets de configuration Kubernetes dans le cluster. Le chemin de mise à niveau de la version 1.0.1.10628 de juin vers la version 1.0.2.10723 de juillet a été amélioré de façon à nettoyer les secrets Kubernetes en trop. Cependant, dans certains cas lors de la mise à niveau, les secrets n’ont néanmoins toujours pas été nettoyés et par conséquent, le processus de mise à niveau échoue.

Si vous rencontrez ce problème, effectuez les étapes suivantes :

1. Enregistrez le script ci-dessous dans un fichier nommé 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. Ensuite, exécutez la commande suivante en utilisant le fichier fix_secret_leak.ps1 que vous avez enregistré :

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

3. Enfin, utilisez la commande PowerShell suivante pour répéter le processus de mise à niveau :

      Update-AksHci
   

Étapes suivantes

• Vue d’ensemble de la résolution des problèmes
• Problèmes et erreurs d’installation
• Problèmes connus dans Windows Admin Center

Si vous continuez à rencontrer des problèmes lorsque vous utilisez AKS Arc, vous pouvez enregistrer des bogues via GitHub.