Résoudre les problèmes liés au moteur AKS sur Azure Stack Hub

Article
10/30/2024

Vous pouvez rencontrer un problème lors du déploiement ou de l’utilisation du moteur AKS sur Azure Stack Hub. Cet article décrit les étapes à suivre pour résoudre les problèmes de déploiement du moteur AKS. Collectez des informations sur votre moteur AKS, collectez les journaux de Kubernetes et passez en revue les codes d’erreur d’extension de script personnalisé. Vous pouvez également ouvrir un problème GitHub pour le moteur AKS.

Notes

Pour AKSe version 0.75.3 et ultérieure, les aks-engine commandes ci-dessous commencent par aks-engine-azurestackaks-engine.

Résoudre les problèmes d’installation du moteur AKS

Si vos étapes d’installation précédentes ont échoué, vous pouvez installer le moteur AKS à l’aide du gestionnaire de package GoFish. GoFish se présente comme un Homebrew multiplateforme.

Vous trouverez des instructions sur l’utilisation de GoFish pour installer le moteur AKS ici.

Collecter les journaux des nœuds et des clusters

Vous trouverez des instructions sur la collecte des journaux des nœuds et des clusters dans Récupération des journaux des nœuds et des clusters.

Prérequis

Ce guide part du principe que vous avez déjà téléchargé Azure CLI et le moteur AKS.

Ce guide suppose également que vous avez déployé un cluster à l’aide du moteur AKS. Pour plus d’informations, consultez Déployer un cluster Kubernetes avec le moteur AKS sur Azure Stack Hub .

Récupération des journaux

La commande aks-engine get-logs peut être utile pour résoudre les problèmes liés à votre cluster. La commande génère, collecte et télécharge un ensemble de fichiers sur votre station de travail. Les fichiers incluent la configuration des nœuds, l’état et la configuration des clusters, et les fichiers journaux d’installation.

Voici dans les grandes lignes ce qui se passe : la commande fonctionne en établissant une session SSH dans chaque nœud, en exécutant un script de collecte de journaux qui collecte et compresse les fichiers appropriés, et en téléchargeant le fichier .ZIP sur votre ordinateur local.

Authentification SSH

Vous aurez besoin d’une clé privée SSH valide pour établir une session SSH sur les nœuds Linux du cluster. Les informations d’identification Windows sont stockées dans le modèle d’API et sont chargées à partir de là. Définissez windowsprofile.sshEnabled sur true pour activer SSH dans vos nœuds Windows.

Charger les journaux dans un conteneur de compte de stockage

Une fois les journaux de cluster correctement récupérés, le moteur AKS peut les enregistrer sur un conteneur de compte de stockage Azure si le paramètre facultatif --upload-sas-url est défini. Le moteur AKS s’attend à ce que le nom du conteneur fasse partie de l’URL SAP fournie. Le format attendu est https://{blob-service-uri}/{container-name}?{sas-token}.

Notes

Les comptes de stockage sur des clouds personnalisés utilisant le fournisseur d’identité AD FS ne sont pas encore pris en charge.

Nœuds échouant à se joindre au cluster

Par défaut, aks-engine get-logs collecte les journaux auprès des nœuds qui ont rejoint le cluster. Pour collecter les journaux des machines virtuelles qui n’ont pas été en mesure de joindre le cluster, définissez l’indicateur --vm-names :

--vm-name k8s-pool-01,k8s-pool-02

Utilisation pour aks-engine get-logs

En supposant que vous avez un cluster déployé et que le modèle d’API utilisé à l’origine pour déployer ce cluster est stocké dans _output/<dnsPrefix>/apimodel.json, vous pouvez collecter les journaux en exécutant une commande comme ceci :

aks-engine get-logs \
    --location <location> \
    --api-model _output/<dnsPrefix>/apimodel.json \
    --ssh-host <dnsPrefix>.<location>.cloudapp.azure.com \
    --linux-ssh-private-key ~/.ssh/id_rsa

Paramètres

Paramètre	Obligatoire	Description
--location	Oui	Emplacement Azure du groupe de ressources du cluster.
--api-model	Oui	Chemin du modèle d’API généré pour le cluster.
--ssh-host	Oui	Nom de domaine complet (FQDN) ou adresse IP d’un écouteur SSH qui peut atteindre tous les nœuds du cluster.
--linux-ssh-private-key	Yes	Chemin d’une clé privée SSH qui peut être utilisée pour créer une session à distance sur les nœuds Linux du cluster.
--output-directory	Non	Répertoire de sortie, dérivé de `--api-model` s’il est manquant.
--control-plane-only	Non	Collecter les journaux seulement auprès des nœuds du plan de contrôle.
--vm-names	Non	Collecter les journaux seulement auprès des machines virtuelles spécifiées (noms séparés par une virgule).
--upload-sas-url	Non	URL SAP du compte de stockage Azure pour charger les journaux collectés.

Examiner les codes d’erreur d’extension de script personnalisé

Le moteur AKS génère un script pour chaque serveur Ubuntu en tant que ressource pour l’extension de script personnalisé (CSE) afin d’effectuer des tâches de déploiement. Si le script génère une erreur, il l’enregistre dans /var/log/azure/cluster-provision.log. Les erreurs sont répertoriées dans le portail. Le code d’erreur peut être utile pour déterminer la cause du problème. Pour plus d’informations sur les codes de sortie de l’extension de script personnalisé, consultez cse_helpers.sh.

Fournir des journaux Kubernetes à un ingénieur du support Microsoft

Si après avoir collecté et examiné les journaux, vous ne parvenez toujours pas à résoudre le problème, vous avez la possibilité de créer un ticket de support et de fournir les journaux que vous avez collectés.

Votre opérateur peut combiner les journaux que vous avez produits avec d’autres journaux système qui peuvent être nécessaires au support technique de Microsoft. L’opérateur peut les mettre à la disposition de Microsoft.

Vous pouvez fournir les journaux Kubernetes de plusieurs façons :

Vous pouvez contacter votre opérateur Azure Stack Hub. Votre opérateur utilise les informations des journaux stockés dans le fichier .ZIP pour créer le cas de support.
Si vous disposez de l’URL SAP pour un compte de stockage où vous pouvez charger vos journaux Kubernetes, vous pouvez inclure la commande et l’indicateur suivants avec l’URL SAS pour enregistrer les journaux dans le compte de stockage :
```
aks-engine get-logs -upload-sas-url <SAS-URL>
```
Pour obtenir des instructions, consultez Charger des journaux dans un conteneur de compte de stockage.
Si vous êtes opérateur cloud, vous pouvez :
- Utiliser le panneau Aide + support dans le portail d’administration Azure Stack Hub pour charger les journaux. Pour obtenir des instructions, consultez Envoyer des journaux maintenant en utilisant le portail administrateur.
- Utiliser l’applet de commande PowerShell Get-AzureStackLog en utilisant le point de terminaison privilégié (PEP). Pour obtenir des instructions, consultez Envoyer des journaux maintenant avec PowerShell.

Ouvrir des problèmes GitHub

Si vous ne parvenez pas à corriger votre erreur de déploiement, vous pouvez ouvrir un problème GitHub.

Ouvrez un problème GitHub dans le référentiel du moteur AKS.
Ajoutez un titre en utilisant le format suivant : Erreur CSE : exit code <INSERT_YOUR_EXIT_CODE>.
Incluez les informations suivantes dans le problème :
- Fichier de configuration de cluster, apimodel.json, utilisé pour déployer le cluster. Supprimez tous les secrets et toutes les clés avant de poster le problème sur GitHub.
- Sortie de la commande kubectl suivante get nodes.
- Le contenu de /var/log/azure/cluster-provision.log provenant d’un nœud défectueux.

Étapes suivantes

En savoir plus sur le Moteur AKS sur Azure Stack Hub.

Partager via