Modifier

Partager via


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

S’applique à : AKS sur Azure Stack HCI, AKS sur Windows Server Cet article décrit les problèmes connus et les erreurs que vous pouvez rencontrer lors de l’installation d’AKS Arc. Vous pouvez également examiner les problèmes connus lors de la mise à niveau d’AKS Arc et lors de l’utilisation de Windows Admin Center.

Erreur « Échec de l’attente de l’intégration de l’arc de module complémentaire »

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

Remarque

L’erreur peut être due à l’activation de Private Link sur l’installation. Actuellement, il n’existe aucune solution de contournement pour ce scénario. AKS sur HCI ne fonctionne pas avec Private Link.

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.

Erreur : « Échec de l’installation d’AksHci, le service a retourné une erreur. Status=403 Code="RequestDisallowedByPolicy"' lors de l’installation d’AKS-HCI

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 qui tentent d’installer AKS sur Azure Stack HCI 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.

Erreur : Échec de l’installation-AksHci avec erreur : [L’objet existe déjà] Une erreur s’est produite lors de la création de la ressource « IPv4 Address xxx.xx.xx.xx.xx » pour le rôle cluster ' xx-xxxxxxxx-xxxx-xxxx-xxxxxxxxx'

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

Erreur : « Erreur GetRelease retournée par l’appel d’API : Erreur de téléchargement de fichier : incompatibilité de hachage »

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 d’AKS sur Azure Stack HCI 21H2, le redémarrage des nœuds a montré un état d’échec de facturation

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

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

Install-AksHci a expiré avec l’erreur « »

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 n’a pas été correctement configuré, réinstallez AKS sur Azure Stack HCI avec le serveur DNS correct. Pour plus d’informations, consultez Redémarrer, supprimer ou réinstaller Azure Kubernetes Service sur Azure Stack HCI.

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

Erreur : « Le processus ne peut pas accéder au fichier « mocstack.cab », car il est utilisé par un autre processus »

É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.

Erreur : Install-AksHci échoue avec « Install-MOC a échoué avec l’erreur - le processus ne peut pas accéder au fichier \<path> car il est utilisé par un autre processus. »

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.

Erreur : « Une connexion existante a été fermée de force par l’hôte distant »

Install-AksHci Échec de cette erreur, car les plages de pool IP fournies dans la configuration AKS sur Azure Stack HCI é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.

Échec de l’installation d’AksHci sur une installation à plusieurs nœuds avec l’erreur « Les nœuds n’ont pas atteint l’état actif »

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>

Le package de téléchargement AKS sur Azure Stack HCI échoue avec l’erreur : « msft.sme.aks n’a pas pu charger »

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.

Lors de l’exécution de Set-AksHciRegistration, une erreur « Impossible de vérifier les fournisseurs de ressources inscrits » s’affiche

Cette erreur apparaît après l’exécution de SetAksHciRegistration dans une installation d’AKS sur Azure Stack HCI. 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 dans l’étape « Attente de l’intégration d’azure-arc à terminer » avant d’expirer

Remarque

Ce problème est résolu dans la version de mai 2022 et ultérieure.

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 l’inscription AKS sur Azure Stack HCI (Set-AksHciRegistration).
  • Des modules PowerShell Az.Accounts version (2.7.x) installés.

Les versions Az.Accounts 2.7.x suppriment ServicePrincipalSecret et CertificatePassword dans PSAzureRmAccount, qui est utilisé par AKS sur Azure Stack HCI pour l’intégration 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 Stack HCI se bloque à l’étape 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

Pendant l’installation, cette erreur s’affiche : « Impossible de créer une machine virtuelle d’appliance : impossible de créer une machine virtuelle : erreur rpc = inconnu desc = Exception survenue. (Échec générique)]'

Cette erreur se produit quand Azure Stack HCI 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 Stack HCI'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 Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-01   Windows Server Subscription Inactive

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

MS-HCIv2-03   Azure Stack HCI             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.

Après une installation ayant échoué, l’exécution d’Install-AksHci ne fonctionne pas

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.

Erreur : « Impossible de rapprocher le réseau virtuel » ou « Erreur : Échec de l’installation-Moc avec erreur - Exception [[Moc] Cette machine ne semble pas être configurée pour le déploiement] »

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, puis redémarrez le processus d’installation AKS-HCI en installant AKS-HCI à l’aide de PowerShell.

Set-AksHciConfig échoue avec l’erreur « Erreur GetCatalog retournée par l’appel d’API : ... proxyconnect tcp : tls : le premier enregistrement ne ressemble pas à une négociation TLS »

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 Stack HCI avec un réseau mal configuré, le déploiement expire à différents points

Lorsque vous déployez AKS sur Azure Stack HCI, 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 Azure Stack HCI peut résoudre le nom de l’URL de téléchargement (msk8s.api.cdp.microsoft.com), mais 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.

Set-AksHciConfig échoue avec des erreurs WinRM, mais affiche que WinRM est configuré correctement

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 HCI.

Échec de la rotation du journal de l’agent Moc

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.

L’agent cloud peut ne pas démarrer correctement lors de l’utilisation des noms de chemins d’accès avec des espaces dans ceux-ci

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.

Erreur : « Install-Moc a échoué avec l’erreur - Exception [CloudAgent n’est pas accessible. MOC CloudAgent peut être inaccessible pour les raisons suivantes]

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

Erreur : « Install-Moc a échoué. Exception [Cela indique généralement qu’un problème s’est produit lors de l’inscription du nom de ressource en tant qu’objet ordinateur auprès du contrôleur de domaine et/ou du serveur DNS. Vérifiez si l’objet ordinateur de cluster dispose des autorisations nécessaires pour créer un objet ordinateur dans le contrôleur de domaine. Vérifiez le contrôleur de domaine et les journaux DNS pour les messages d’erreur associés.

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 > Click 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.>

Erreur : Install-AksHci échoue avec « Install-Moc a échoué. Les journaux sont disponibles C :\Users\xxx\AppData\Local\Temp\v0eoltcc.a10'

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.

Le déploiement PowerShell ne vérifie pas la mémoire disponible avant de créer un cluster de charge de travail

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.

Une erreur « Impossible d’acquérir un jeton » s’affiche lors de l’exécution de Set-AksHciRegistration

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.

Erreur : « Attendre que le pod « Opérateur cloud » soit prêt »

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>
  1. 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
  1. 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.

Erreur : « Échec de l’installation-Moc avec erreur - Exception [Impossible de créer le rôle générique du cluster de basculement.] »

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-ClusterNetworkRole 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.

L’applet de commande Enable-AksHciArcConnection génère un avertissement indiquant que GetServicePrincipals dispose de privilèges insuffisants pour activer les emplacements personnalisé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-HCI 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

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