Résoudre les problèmes et les erreurs lors d’une installation d’AKS Arc

Ce message d’erreur s’affiche après l’exécution d’Install-AksHci.

Si vous n’utilisez pas Private Link, pour résoudre ce problème, procédez comme suit :

1. Ouvrez PowerShell et exécutez Uninstall-AksHci.
2. Ouvrez le portail Azure et accédez au groupe de ressources que vous avez utilisé lors de l’exécution de Install-AksHci.
3. Recherchez les ressources de cluster connectées qui s’affichent dans un état Déconnecté, et incluez un nom se présentant sous forme de GUID généré de manière aléatoire.
4. Supprimez ces ressources de cluster.
5. Fermez la session PowerShell et ouvrez une nouvelle session avant d’exécuter Install-AksHci de nouveau.

Cette erreur peut être due au processus d’installation qui tente de violer une stratégie Azure définie sur l’abonnement Azure ou le groupe de ressources fourni pendant le processus d’intégration d’Azure Arc. Cette erreur peut se produire pour les utilisateurs qui ont défini des stratégies Azure au niveau d’un abonnement ou d’un groupe de ressources, puis tenter d’installer AKS sur Azure Local qui enfreint une stratégie Azure.

Pour résoudre ce problème, lisez le message d’erreur pour comprendre quelle stratégie Azure définie par votre administrateur Azure a été violée, puis modifiez la stratégie Azure en faisant une exception à la stratégie Azure. Pour en savoir plus sur les exceptions de stratégie, consultez Structure d’exemption Azure Policy.

Une fonctionnalité précédemment installée reste en état d’échec et n’a pas été effacée. L'erreur suivante peut apparaître :

Exception [An error occurred while creating resource 'MOC Cloud Agent Service' for the clustered role 'ca-3f72bdeb-xxxx-4ae9-a721-3aa902a998f0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2987
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[The object already exists]

Vous pouvez aussi voir le message suivant :

Install-Moc failed.
Exception [Unable to save property changes for 'IPv4 Address xxx.168.18.0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2971
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[A matching cluster network for the specified IP address could not be found]

Pour résoudre ce problème, nettoyez manuellement le rôle de cluster. Vous pouvez supprimer la ressource du gestionnaire du cluster de basculement en exécutant l’applet de commande PowerShell suivante : Remove-ClusterResource -name <resource name>.

L’applet Install-AksHci de commande échoue avec « Erreur GetRelease retournée par l’appel d’API : Erreur de téléchargement de fichier : incompatibilité de hachage ».

1. Ouvrez une fenêtre PowerShell et exécutez Uninstall-AksHci.
2. Réessayez une installation.
3. Si le problème persiste, utilisez le -concurrentDownloads paramètre avec Set-AksHciConfig et définissez-le sur un nombre inférieur au 10 par défaut avant de réessayer d’installer. La réduction du nombre de téléchargements simultanés peut aider les réseaux sensibles à effectuer correctement les téléchargements de fichiers volumineux. Ce paramètre est une fonctionnalité en préversion.

Après le déploiement, lors du redémarrage des nœuds locaux Azure, le rapport AKS a montré un état d’échec de facturation.

Pour résoudre ce problème, suivez les instructions pour faire pivoter le jeton manuellement et redémarrer le plug-in KMS.

Après l’exécution de Install-AksHci, l’installation s’arrête et le message d’erreur suivant s’affiche :

\kubectl.exe --kubeconfig=C:\AksHci\0.9.7.3\kubeconfig-clustergroup-management 
get akshciclusters -o json returned a non zero exit code 1 
[Unable to connect to the server: dial tcp 192.168.0.150:6443: 
connectex: A connection attempt failed because the connected party 
did not properly respond after a period of time, or established connection 
failed because connected host has failed to respond.]

Plusieurs raisons peuvent expliquer l’échec d’une installation avec l’erreur waiting for API server.

La section suivante présente les causes et solutions possibles pour cette erreur.

Raison 1 : Configuration incorrecte de la passerelle IP Si vous utilisez des adresses IP statiques et que vous avez reçu le message d’erreur suivant, vérifiez que la configuration de l’adresse IP et de la passerelle est correcte.

Install-AksHci 
C:\AksHci\kvactl.exe create --configfile C:\AksHci\yaml\appliance.yaml  --outfile C:\AksHci\kubeconfig-clustergroup-management returned a non-zero exit code 1 [ ]

Pour vérifier si vous disposez de la configuration appropriée pour votre adresse IP et votre passerelle, exécutez la commande suivante :

ipconfig /all

Dans les paramètres de configuration affichés, vérifiez la configuration. Vous pouvez également effectuer un test ping sur la passerelle IP et le serveur DNS.

ping <DNS server>

Si ces méthodes ne fonctionnent pas, utilisez New-AksHciNetworkSetting pour modifier la configuration.

Raison 2 : Serveur DNS incorrect Si vous utilisez des adresses IP statiques, vérifiez que le serveur DNS est correctement configuré. Pour vérifier l’adresse du serveur DNS de l’hôte, utilisez la commande suivante :

Get-NetIPConfiguration.DNSServer | ?{ $_.AddressFamily -ne 23} ).ServerAddresses

Vérifiez que l’adresse du serveur DNS est celle utilisée lors de l’exécution de la commande New-AksHciNetworkSetting en exécutant la commande suivante :

Get-MocConfig

Si le serveur DNS a été configuré de manière incorrecte, réinstallez AKS sur Azure Local avec le serveur DNS approprié. Pour plus d’informations, consultez Redémarrer, supprimer ou réinstaller Azure Kubernetes Service sur Azure Local .

Le problème a été résolu après suppression de la configuration et redémarrage de la machine virtuelle avec une nouvelle configuration.

Échec de Install-AksHci avec retour de cette erreur, car un autre processus accède à mocstack.cab.

Pour résoudre ce problème, fermez toutes les fenêtres PowerShell ouvertes, puis rouvrez une nouvelle fenêtre PowerShell.

Impossible d’accéder au fichier, car il est utilisé par un autre processus.

Pour résoudre ce problème, redémarrez votre session PowerShell. Fermez la fenêtre PowerShell et réessayez Install-AksHci.

Install-AksHci Échec de cette erreur, car les plages de pool d’adresses IP fournies dans la configuration akS sur Azure Local étaient désactivées par 1 dans le CIDR et peuvent provoquer un blocage de CloudAgent. Par exemple, si le sous-réseau 10.0.0.0/21 utilise la plage d’adresses 10.0.0.0-10.0.7.255, puis que vous utilisez l’adresse de début 10.0.0.1 ou l’adresse de fin 10.0.7.254, cela entraîne le blocage de CloudAgent.

Pour contourner ce problème, exécutez New-AksHciNetworkSetting et utilisez toute autre plage d’adresses IP valide pour votre pool d’adresses IP virtuelles et votre pool de nœuds Kubernetes. Assurez-vous que les valeurs que vous utilisez ne sont pas désactivées par 1 au début ou à la fin de la plage d’adresses.

Quand j’exécute Install-AksHci sur une configuration mononœud, l’installation fonctionne, mais quand je configure le cluster de basculement, l’installation échoue avec un message d’erreur. Pourtant, un test ping effectué sur l’agent cloud montre que CloudAgent est accessible.

Pour vérifier que tous les nœuds peuvent résoudre le DNS de CloudAgent, exécutez la commande suivante sur chaque nœud :

Resolve-DnsName <FQDN of cloudagent>

Quand l’étape ci-dessus réussit sur les nœuds, veillez à ce qu’ils peuvent atteindre le port de CloudAgent pour vérifier qu’un proxy ne tente pas de bloquer cette connexion et que le port est ouvert. Pour ce faire, exécutez la commande suivante sur chaque nœud :

Test-NetConnection  <FQDN of cloudagent> -Port <Cloudagent port - default 65000>

L’erreur provient d’une erreur avec téléchargement.

Si vous obtenez cette erreur, vous devez utiliser la dernière version de Microsoft Edge ou Google Chrome, puis réessayer.

Cette erreur s’affiche après l’exécution de Set-AksHciRegistration dans une installation AKS sur Azure Local. Cette erreur indique que les fournisseurs de ressources Kubernetes ne sont pas inscrits pour le locataire actuellement connecté.

Pour résoudre ce problème, exécutez les étapes Azure CLI ou PowerShell ci-dessous :

az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration

Register-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Register-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

L’installation prend environ 10 minutes. Pour superviser le processus d’inscription, utilisez les commandes suivantes.

az provider show -n Microsoft.Kubernetes -o table
az provider show -n Microsoft.KubernetesConfiguration -o table

Get-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Get-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Install-AksHci se bloque à l’étape Waiting for azure-arc-onboarding to complete avant l’expiration du délai d’attente les cas suivants :

• Un principal de service est utilisé dans AKS sur l’inscription locale Azure (Set-AksHciRegistration).
• Des modules PowerShell Az.Accounts version (2.7.x) installés.

Az.Accounts 2.7.x les versions suppriment l’intégration ServicePrincipalSecret CertificatePassword PSAzureRmAccountd’AKS sur Azure Local pour Azure Arc.

Opérations à reproduire :

1. Installez des modules PowerShell Az.Accounts version >= 2.7.0.
2. Set-AksHciRegistration à l’aide d’un principal du service.
3. Install-AksHci.

Comportement attendu :

1. L’installation d’AKS sur Azure Local se bloque sur Waiting for azure-arc-onboarding to complete.
2. Les pods Azure-arc-onboarding entrent dans une boucle de plantage.
3. Erreur de pods Azure-arc-onboarding avec le message suivant :
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Pour résoudre ce problème :

Désinstallez les modules Az.Accounts avec les versions 2.7.x. Exécutez l’applet de commande suivante :

Uninstall-Module -Name Az.Accounts -RequiredVersion 2.7.0 -Force

Cette erreur se produit quand Azure Local est hors stratégie. L’état de la connexion sur le cluster peut indiquer qu’il est connecté, mais le journal des événements affiche un message d’avertissement indiquant : Azure Local's subscription is expired, run Sync-AzureStackHCI to renew the subscription.

Pour résoudre cette erreur, vérifiez que le cluster est inscrit auprès d’Azure à l’aide de l’applet de commande PowerShell Get-AzureStackHCI disponible sur votre ordinateur. Le tableau de bord Windows Admin Center affiche également des informations d’état sur l’inscription auprès d’Azure du cluster.

Si le cluster est déjà inscrit, vous devez voir le champ LastConnected dans la sortie de Get-AzureStackHCI. Si le champ indique que plus de 30 jours se sont écoulés, vous devez tenter de résoudre le problème à l’aide de l’applet de commande Sync-AzureStackHCI.

Vous pouvez également vérifier si chaque nœud de votre cluster dispose de la licence requise à l’aide de l’applet de commande suivante :

Get-ClusterNode | % { Get-AzureStackHCISubscriptionStatus -ComputerName $_ }

Computer Name Subscription Name           Status   Valid To
------------- -----------------           ------   --------
MS-HCIv2-01   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-01   Windows Server Subscription Inactive

MS-HCIv2-02   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-02   Windows Server Subscription Inactive

MS-HCIv2-03   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-03   Windows Server Subscription Inactive

Si le problème n’est pas résolu après l’exécution de l’applet de commande Sync-AzureStackHCI, contactez le support Microsoft.

Ce problème se produit car l’échec d’une installation peut entraîner des fuites de ressources qui doivent être nettoyées avant de pouvoir être réinstallées.

Si votre installation échoue en utilisant Install-AksHci, vous devez exécuter Uninstall-AksHci avant de réexécuter Install-AksHci.

Vous pouvez déclencher ces erreurs lorsque vous exécutez Install-AksHci sans exécuter Set-AksHciConfig en premier.

Pour résoudre l’erreur, exécutez uninstall-akshci et fermez toutes les fenêtres PowerShell. Ouvrez une nouvelle session PowerShell et redémarrez votre processus d’installation AKS sur Azure Local en suivant l’installation d’AKS sur Azure Local à l’aide de PowerShell.

L’applet Set-AksHciConfig de commande PowerShell échoue avec l’erreur :

GetCatalog error returned by API call: ... proxyconnect tcp: tls: first record does not look like a TLS Handshake

Si vous utilisez AKS avec un serveur proxy, vous avez peut-être utilisé l’URL incorrecte lors de la définition de la valeur d’URL de proxy HTTPS requise. L’URL du proxy HTTP et les valeurs d’URL du proxy HTTPS sont requises lors de la configuration d’AKS avec un serveur proxy, mais il est courant que les deux valeurs partagent la même URL avec préfixe HTTP.

Si cela peut être le cas dans votre environnement, essayez les étapes d’atténuation suivantes :

1. Fermez la fenêtre PowerShell et ouvrez-en une nouvelle.
2. Réexécutez les New-AksHciNetworkSetting applets de commande et New-AksHciProxySetting les applets de commande. Lors de l’exécution New-AksHciProxySetting, définissez le -https paramètre avec la même valeur d’URL avec préfixe HTTP que pour laquelle vous avez défini -http.
3. Exécutez et poursuivez Set-AksHciConfig .

Lorsque vous déployez AKS sur Azure Local, le déploiement peut expirer à différents points du processus en fonction de l’emplacement où la configuration est incorrecte. Vous devez examiner le message d’erreur pour déterminer la cause et l’endroit où celle-ci s’est produite.

Par exemple, dans l’erreur suivante, l’erreur de configuration s’est produite au niveau de Get-DownloadSdkRelease -Name "mocstack-stable" :

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

Cela indique que le nœud local Azure physique peut résoudre le nom de l’URL de téléchargement, msk8s.api.cdp.microsoft.commais que le nœud ne peut pas se connecter au serveur cible.

Pour résoudre ce problème, vous devez déterminer où la rupture s’est produite dans le processus de connexion. Voici quelques étapes à suivre pour tenter de résoudre le problème à partir du nœud de cluster physique :

1. Effectuez un test ping sur le nom DNS de destination : ping msk8s.api.cdp.microsoft.com.
2. Si vous recevez une réponse et que vous n’avez pas dépassé le délai d’attente, cela signifie que le chemin réseau de base fonctionne.
3. Si la connexion expire, il peut y avoir une rupture dans le chemin des données. Pour plus d’informations, consultez Vérifier les paramètres de proxy. Il est également possible qu’il y ait une rupture dans le chemin de retour. Vous devez donc vérifier les règles de pare-feu.

Lors de l’exécution de la commande Set-AksHciConfig, vous pouvez rencontrer l’erreur suivante :

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

Cette erreur résulte d’un changement du jeton de sécurité de l’utilisateur (lié à un changement de l’appartenance au groupe), d’un changement de mot de passe ou de l’expiration d’un mot de passe. Dans la plupart des cas, vous pouvez corriger le problème en vous déconnectant de l’ordinateur, puis en vous reconnectant. En cas d’échec, vous pouvez déposer un problème sur GitHub AKS Azure Local issues.

Les agents MOC sont censés conserver uniquement les 100 derniers journaux des agents. Ils sont supposés supprimer les anciens journaux. Toutefois, la rotation des journaux ne se produit pas et les journaux continuent à s’accumuler, ce qui consomme de l’espace disque.

Opérations à reproduire : Install AksHci et gardez un cluster opérationnel jusqu’à ce que le nombre de journaux des agents dépasse 100. Au moment de la création du nième journal, les agents sont censés supprimer le n-100ème journal, le cas échéant.

Pour résoudre le problème :

1. Modifiez les fichiers logconfig de l’agent cloud et des agents de nœud. Le fichier logconfig de l’agent cloud se trouve à l’emplacement suivant :
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   Le fichier logconfig des agents de nœud se trouve à l’emplacement suivant :
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Remplacez la valeur de Limit par 100 et celle de Slots par 100, puis enregistrez les fichiers de configuration.

3. Redémarrez l’agent cloud et les agents de nœud pour enregistrer ces modifications.

Ces étapes démarrent la rotation des journaux uniquement après la génération de 100 nouveaux journaux à partir du redémarrage des agents. S’il existe déjà n journaux d’agent au moment du redémarrage, la rotation des journaux commence uniquement après la génération de n+ 100 journaux.

Quand vous utilisez Set-AksHciConfig pour spécifier des paramètres -imageDir, -workingDir, -cloudConfigLocation ou -nodeConfigLocation avec un nom de chemin contenant un espace (par exemple D:\Cloud Share\AKS HCI), le service de cluster de l’agent cloud ne parvient pas à démarrer et produit le message d’erreur suivant (ou similaire) :

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

Pour contourner ce problème, utilisez un chemin sans espaces, par exemple, C:\CloudShare\AKS-HCI.

Cette erreur peut se produire en cas de configuration incorrecte d’une infrastructure.

Pour résoudre cette erreur, procédez comme suit :

1. Vérifiez les paramètres de la passerelle et de configuration du serveur DNS de l’hôte :

   1. Vérifiez que le serveur DNS est correctement configuré. Pour vérifier l’adresse du serveur DNS de l’hôte, exécutez la commande suivante :

      ((Get-NetIPConfiguration).DNSServer | ?{ $_.AddressFamily -ne 23}).ServerAddresses
      

   2. Pour vérifier si votre adresse IP et votre configuration de passerelle sont correctes, exécutez la commande ipconfig/all.
   3. Essayez d’exécuter une commande ping sur la passerelle IP et le serveur DNS.

2. Vérifiez le service CloudAgent pour vous assurer qu’il est en cours d’exécution :

   1. Exécutez une commande ping sur le service CloudAgent pour vous assurer qu’il est accessible.
   2. Vérifiez que tous les nœuds peuvent résoudre le DNS de CloudAgent en exécutant la commande suivante sur chaque nœud :

      Resolve-DnsName <FQDN of cloudagent>
      

   3. Quand l’étape précédente réussit sur les nœuds, assurez-vous qu’ils peuvent atteindre le port de CloudAgent pour vérifier qu’un proxy ne tente pas de bloquer cette connexion et que le port est ouvert. Pour cela, exécutez la commande suivante sur chaque nœud :

      Test-NetConnection <FQDN of cloudagent> -Port <Cloudagent port - default 65000>
      

   4. Pour vérifier si le service de cluster s’exécute pour un cluster de basculement, vous pouvez également exécuter la commande suivante :

      Get-ClusterGroup -Name (Get-AksHciConfig).Moc['clusterRoleName']
      

Cela indique généralement que l’objet CNO (Cluster Name Object) représentant votre cluster de basculement sous-jacent dans services de domaine Active Directory (AD DS) n’a pas les autorisations nécessaires pour créer un objet d’ordinateur virtuel (VCO) dans l’unité d’organisation (UO) ou dans le conteneur où réside le cluster.

Si vous n’êtes pas administrateur de domaine, vous pouvez demander à un administrateur de domaine d’accorder les autorisations CNO à l’unité d’organisation ou de préparer un VCO pour le service de cluster générique de l’agent cloud.

Si vous êtes administrateur de domaine, il est toujours possible que votre unité d’organisation ou conteneur ne dispose pas des autorisations requises. Par exemple, le mode Application, introduit dans KB5008383, peut être activé dans Active Directory. Essayez ce qui suit avant d’essayer une réinstallation.

1. Accédez à Utilisateurs et ordinateurs Active Directory.
2. Cliquez avec le bouton droit sur l’unité d’organisation ou le conteneur où réside le cluster.
3. Sélectionnez Déléguer le contrôle... pour ouvrir l’Assistant Délégation de contrôle.
4. Cliquez sur Ajouter>... pour ouvrir la fenêtre Sélectionner des utilisateurs, des ordinateurs ou des groupes.
5. Sélectionnez votre choix de groupe ou d’utilisateurs auxquels vous souhaitez déléguer le contrôle > Cliquez sur OK.
6. Sélectionnez Créer une tâche personnalisée pour déléguer> Cliquez sur Suivant pour accéder à la page Type d’objet Active Directory.
7. Sélectionnez uniquement les objets suivants dans le dossier> Sélectionner les objets Ordinateur Sélectionner les objets> sélectionnés dans ce dossier et supprimer les objets sélectionnés dans ce dossier> Cliquez sur Suivant pour accéder à la page Autorisations.
8. Sélectionnez Créer tous les objets enfants et supprimer tous les objets enfants dans la liste des autorisations > Cliquez sur Terminer suivant>

En cas d’échec d’une réinstallation, réessayez les étapes ci-dessus avec les modifications suivantes apportées aux étapes 7 et 8 :

• Étape 7 : Sélectionnez ce dossier, les objets existants dans ce dossier et la création de nouveaux objets dans ce dossier> Cliquez sur Suivant.
• Étape 8 : Sélectionnez Lecture, Écriture, Créer tous les objets enfants et supprimer tous les objets enfants dans la liste des autorisations > Cliquez sur Terminer le clic suivant.>

Vous pouvez recevoir cette erreur lors de l’exécution d’Install-AksHci.

Vous pouvez obtenir plus d’informations en exécutant $error = Install-AksHci , puis $error[0].Exception.InnerException.

Les commandes PowerShell Aks-Hci ne valident pas la mémoire disponible sur le serveur hôte avant de créer des nœuds Kubernetes. Ce problème peut entraîner un épuisement de la mémoire et empêcher le démarrage des machines virtuelles. Cette défaillance n’étant actuellement pas gérée correctement, le déploiement cessera de répondre sans retourner de message d’erreur explicite.

Si le déploiement cesse de répondre, ouvrez Observateur d'événements et recherchez un message d’erreur relatif à Hyper-V, indiquant que la mémoire est insuffisante pour démarrer la machine virtuelle.

Cette erreur peut se produire quand vous avez plusieurs locataires sur votre compte Azure.

Utilisez $tenantId = (Get-AzContext).Tenant.Id pour définir le locataire approprié. Ensuite, incluez ce locataire en tant que paramètre lors de l’exécution de Set-AksHciRegistration.

Lors de la tentative de déploiement d’un cluster AKS sur une machine virtuelle Azure, l’installation a été bloquée, Waiting for pod 'Cloud Operator' to be ready...puis a échoué et expiré après deux heures. Les tentatives de dépannage via la vérification de la passerelle et du serveur DNS ont montré qu’elles fonctionnaient correctement. Les vérifications des conflits d’adresses IP ou MAC n’ont pas été trouvés. Les journaux d’activité n’ont pas affiché le pool d’adresses IP virtuelles. Il y a eu une restriction sur l’extraction de l’image de conteneur à l’aide de sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 qui a renvoyé un délai de sécurité TLS (Transport Layer Security) au lieu de non autorisé.

Pour résoudre ce problème, procédez comme suit :

1. Commencez à déployer votre cluster.
2. Une fois le cluster déployé, connectez-vous à votre machine virtuelle de cluster de gestion via SSH, comme indiqué ci-dessous :

ssh -i (Get-MocConfig)['sshPrivateKey'] clouduser@<IP Address>

3. Modifiez le paramètre MTU (unité de transmission maximale). N’hésitez pas à apporter la modification ; si vous apportez la modification trop tard, le déploiement échoue. La modification du paramètre MTU permet de débloquer l’extraction de l’image conteneur.

sudo ifconfig eth0 mtu 1300

4. Pour visualiser l’état de vos conteneurs, exécutez la commande suivante :

sudo docker ps -a

Une fois ces étapes effectuées, l’extraction de l’image conteneur doit être déblocée.

Cette erreur indique que l’adresse IP du service cloud ne fait pas partie du réseau de cluster et ne correspond à aucun des réseaux de cluster pour lesquels le rôle client and cluster communication est activé.

Pour résoudre ce problème, exécutez Get-ClusterNetwork où Role a la valeur ClusterAndClient. Ensuite, sur l’un des nœuds du cluster, sélectionnez le nom, l’adresse et le masque d’adresse pour vérifier que l’adresse IP fournie pour le paramètre -cloudServiceIP de New-AksHciNetworkSetting correspond à l’un des réseaux affichés.

Enable-AksHciArcConnection peut connecter un cluster AKS à Azure, mais il affiche l’avertissement suivant lorsque le client utilise un principal de service pour l’authentification :

WARNING: Error occurred while executing GetServicePrincipals
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
RequestId: <removed>
DateTimeStamp: <removed>
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
WARNING: Custom locations has not been enabled on the AKS on Azure Local cluster. To enable custom locations manually, visit aka.ms/enable-custom-location

Le comportement actuel de l’intégration d’Arc consiste à activer les emplacements personnalisés par défaut. Pour activer des emplacements personnalisés, l’action GetServicePrincipals est effectuée dans le contexte de l’utilisateur Azure connecté. Si l’utilisateur (ou SPN) ne dispose pas des autorisations suffisantes pour pouvoir le faire, la commande émet un avertissement indiquant que ces autorisations n’existent pas, et par conséquent, la fonctionnalité Emplacements personnalisés n’est pas activée.

Si vous ne souhaitez pas que les emplacements personnalisés soient activés, vous pouvez ignorer cet avertissement en toute sécurité, car cela n’affecte pas l’intégration du cluster à Arc. En revanche, si vous avez besoin d’emplacements personnalisés pour être activés, vous devez accorder les autorisations nécessaires à l’utilisateur (ou SPN).

Étapes suivantes

• Vue d’ensemble de la résolution des problèmes
• Problèmes connus dans Windows Admin Center
• Résolution des problèmes liés aux clusters Kubernetes

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