Résoudre les échecs « az aks command invoke »
Cet article explique comment résoudre les échecs d’appel de commande az aks dans Microsoft Azure CLI afin de pouvoir vous connecter à n’importe quel cluster Azure Kubernetes Service (AKS), en particulier à un cluster AKS privé.
D’autres méthodes de connexion doivent utiliser des composants de configuration supplémentaires, comme indiqué dans le tableau suivant.
| Méthodes de connexion | Composant de configuration supplémentaire |
|---|---|
| Réseau virtuel | le réseau privé virtuel (VPN, Virtual Private Network) ; |
| Réseau appairé | Azure ExpressRoute |
| Point de terminaison privé | Serveur de rebond (jumpbox) |
La az aks command invoke commande Azure CLI est une autre façon de se connecter à un cluster qui ne nécessite pas de composants de configuration supplémentaires.
Lorsque vous exécutez la az aks command invoke commande, Azure CLI crée automatiquement un command-<ID> pod dans l’espace aks-command de noms pour accéder au cluster AKS et récupérer les informations requises.
Prerequisites
Outil Kubernetes kubectl . Pour installer kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .
Symptômes
Le tableau suivant répertorie les messages d’erreur courants az aks command invoke . Chaque message d’erreur a un lien vers la section qui décrit pourquoi l’erreur se produit et comment la corriger.
| Message d’erreur | Lien |
|---|---|
| L’opération a retourné un état non valide « Introuvable » | Cause 1 : Le pod ne peut pas être créé en raison de contraintes de nœud ou de ressource |
| Échec de l’exécution de la commande dans un cluster managé en raison d’une défaillance kubernetes. détails : le webhook d’admission « validation.gatekeeper.sh » a refusé la demande : <message spécifique à la stratégie> | Cause 2 : Azure Policy n’autorise pas la création du pod |
| Erreur du serveur (Interdit) : les espaces de noms sont interdits : l’utilisateur «< ID> » ne peut pas répertorier la ressource «< ressource> » dans le groupe d’API « » dans l’étendue du cluster | Cause 3 : Les rôles requis ne sont pas accordés |
| Échec de la connexion à MSI. Vérifiez que MSI est correctement configuré. Demande d’obtention du jeton retournée : Réponse [400] ; |
Cause 4 : Il existe un problème Cloud Shell |
Cause 1 : Le pod ne peut pas être créé en raison de contraintes de nœud ou de ressource
L’opération retourne un Not Found état, car le command-<ID> pod ne peut pas atteindre un état réussi, tel que Running. (Dans de nombreux cas, le pod reste dans l’état Pending .) Dans ce cas, les nœuds ne peuvent pas planifier le pod. Ce scénario peut avoir différentes causes, telles que les causes suivantes :
- Contraintes de ressources
- Nœuds qui ont un ou
SchedulingDisabledunNotReadyétat - Nœuds qui ont des teintes que le pod ne peut pas tolérer
- Autres causes
Solution 1 : Modifier la configuration pour que vous puissiez planifier et exécuter le pod
Assurez-vous que le command-<ID> pod peut être planifié et exécuté en ajustant la configuration. Par exemple :
- Augmentez la taille du pool de nœuds et assurez-vous qu’il n’a pas de contraintes isolées de pod comme des teintes afin que le
command-<ID>pod puisse être déployé. - Ajustez les demandes de ressources et les limites dans les spécifications de votre pod.
Cause 2 : Azure Policy n’autorise pas la création du pod
Si vous avez des stratégies Azure spécifiques, la az aks command invoke commande peut échouer en raison d’une configuration non autorisée dans le command-<ID> pod. Par exemple, vous pouvez avoir une stratégie Azure qui nécessite un système de fichiers racine en lecture seule ou une autre configuration spécifique.
Solution 2 : Exemptez l’espace de noms pour les stratégies qui interdisent la création de pods
Nous vous recommandons d’exempter l’espace aks-command de noms pour les stratégies Azure associées qui n’autorisent pas la création du pod. Pour plus d’informations sur l’exemption, consultez Comprendre l’étendue dans Azure Policy
Pour exempter une stratégie Azure :
Dans le Portail Azure, recherchez et sélectionnez Stratégie.
Dans le volet de navigation de stratégie, recherchez la section Création , puis sélectionnez Affectations.
Dans la table des affectations, recherchez la ligne qui contient le nom de l’affectation que vous souhaitez modifier, puis sélectionnez le nom de l’affectation.
Dans la page d’attribution de stratégie de cette affectation, sélectionnez Modifier l’affectation.
Sélectionnez l’onglet Paramètres.
Désactivez l’option Afficher uniquement les paramètres qui ont besoin d’une entrée ou d’une option de révision .
Dans la zone Exclusions d’espaces de noms, ajoutez l’espace de noms aks-command à la liste des espaces de noms à exclure.
Sinon, si la stratégie n’est pas une stratégie intégrée, vous pouvez vérifier la configuration du command-<ID> pod et ajuster la stratégie si nécessaire. Pour explorer la configuration YAML du pod, exécutez la commande suivante :
kubectl get pods command-<ID> --namespace aks-command --output yaml
Vous pouvez exempter l’espace aks-command de noms des stratégies restrictives en exécutant la commande suivante :
az policy exemption create --name ExemptAksCommand --scope /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster} --policyAssignment /subscriptions/{subscription-id}/providers/Microsoft.Authorization/policyAssignments/{policy-assignment-id}
Cause 3 : Les rôles requis ne sont pas accordés
Pour utiliser la az aks command invoke commande, vous devez avoir accès aux rôles suivants sur le cluster :
Microsoft.ContainerService/managedClusters/runCommand/actionMicrosoft.ContainerService/managedClusters/commandResults/read
Si vous n’avez pas ces rôles, la az aks command invoke commande ne peut pas récupérer les informations requises.
Solution 3 : Ajouter les rôles requis
Pour résoudre ce problème, effectuez les étapes suivantes :
Ajoutez les rôles et
Microsoft.ContainerService/managedClusters/commandResults/readlesMicrosoft.ContainerService/managedClusters/runCommand/actionrôles.Attribuez les rôles nécessaires à l’utilisateur :
az role assignment create --assignee {user-principal-name} --role "Azure Kubernetes Service Cluster User Role" --scope /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster}
Cause 4 : Il existe un problème Cloud Shell
La az aks command invoke commande n’est pas traitée comme prévu lorsqu’elle est exécutée directement dans l’environnement Azure Cloud Shell . Il s’agit d’un problème connu dans Cloud Shell.
Solution 4a : Exécutez d’abord la commande az login
Dans Cloud Shell, exécutez la commande az login avant d’exécuter la az aks command invoke commande. Par exemple :
az login
az aks command invoke --resource-group {resource-group} --name {aks-cluster} --command "kubectl get pods"
Solution 4b : Exécuter la commande sur un ordinateur local ou une machine virtuelle
Exécutez la az aks command invoke commande sur un ordinateur local ou sur une machine virtuelle sur laquelle Azure CLI est installé.
Exclusion de responsabilité de tiers
Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.
Contactez-nous pour obtenir de l’aide
Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.