Résoudre les problèmes de plateforme pour les clusters Kubernetes compatibles avec Azure Arc
Ce document fournit des guides de dépannage pour les problèmes liés à la connectivité, aux autorisations et aux agents Kubernetes avec Azure Arc. Il fournit également des guides de dépannage pour Azure GitOps, qui peuvent être utilisés dans les clusters Kubernetes avec Azure Arc ou Azure Kubernetes Service (AKS).
Pour résoudre les problèmes liés aux extensions, telles que GitOps (Flux v2), Azure Monitor Container Insights ou Open Service Mesh, consultez Résoudre les problèmes d’extension pour les clusters Kubernetes avec Azure Arc.
Azure CLI
Avant d’utiliser les commandes CLI az connectedk8s ou az k8s-configuration, assurez-vous qu’Azure CLI est configuré pour fonctionner avec l’abonnement Azure approprié.
az account set --subscription 'subscriptionId'
az account show
Si vous voyez une erreur telle que cli.azext_connectedk8s.custom: Failed to download and install kubectl, exécutez az aks install-cli --install-location ~/.azure/kubectl-client/kubectl avant d’essayer de réexécuter az connectedk8s connect. Cette commande installe le client kubectl requis pour que la commande fonctionne.
Agents Azure Arc
Tous les agents pour Kubernetes avec Azure Arc sont déployés en tant que pods dans l’espace de noms azure-arc. Tous les pods doivent être en cours d’exécution et réussir leurs contrôles d’intégrité.
Tout d’abord, vérifiez la version de Azure Arc Helm Chart :
$ helm --namespace default status azure-arc
NAME: azure-arc
LAST DEPLOYED: Fri Apr 3 11:13:10 2020
NAMESPACE: default
STATUS: deployed
REVISION: 5
TEST SUITE: None
Si la version de Helm Chart est introuvable ou manquante, essayez de reconnecter le cluster à Azure Arc.
Si la version de Helm Chart est présente avec STATUS: deployed, vérifiez l’état des agents à l’aide de kubectl :
$ kubectl -n azure-arc get deployments,pods
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/cluster-metadata-operator 1/1 1 1 3d19h
deployment.apps/clusterconnect-agent 1/1 1 1 3d19h
deployment.apps/clusteridentityoperator 1/1 1 1 3d19h
deployment.apps/config-agent 1/1 1 1 3d19h
deployment.apps/controller-manager 1/1 1 1 3d19h
deployment.apps/extension-events-collector 1/1 1 1 3d19h
deployment.apps/extension-manager 1/1 1 1 3d19h
deployment.apps/flux-logs-agent 1/1 1 1 3d19h
deployment.apps/kube-aad-proxy 1/1 1 1 3d19h
deployment.apps/metrics-agent 1/1 1 1 3d19h
deployment.apps/resource-sync-agent 1/1 1 1 3d19h
NAME READY STATUS RESTARTS AGE
pod/cluster-metadata-operator-74747b975-9phtz 2/2 Running 0 3d19h
pod/clusterconnect-agent-cf4c7849c-88fmf 3/3 Running 0 3d19h
pod/clusteridentityoperator-79bdfd945f-pt2rv 2/2 Running 0 3d19h
pod/config-agent-67bcb94b7c-d67t8 1/2 Running 0 3d19h
pod/controller-manager-559dd48b64-v6rmk 2/2 Running 0 3d19h
pod/extension-events-collector-85f4fbff69-55zmt 2/2 Running 0 3d19h
pod/extension-manager-7c7668446b-69gps 3/3 Running 0 3d19h
pod/flux-logs-agent-fc7c6c959-vgqvm 1/1 Running 0 3d19h
pod/kube-aad-proxy-84d668c44b-j457m 2/2 Running 0 3d19h
pod/metrics-agent-58fb8554df-5ll67 2/2 Running 0 3d19h
pod/resource-sync-agent-dbf5db848-c9lg8 2/2 Running 0 3d19h
Tous les pods doivent indiquer que le STATUS est Running avec 3/3 ou 2/2 sous la colonne READY. Récupérez les journaux et décrivez les pods qui retournent Error ou CrashLoopBackOff. Si des pods sont bloqués à l’état Pending, cela est peut-être dû à un manque de ressources sur les nœuds de cluster. Effectuez un scale-up de votre cluster pour permettre à ces pods de passer à l’état Running.
Erreur d’expiration du délai d’attente du service/échec de l’approvisionnement des ressources
Si vous voyez ces erreurs, vérifiez l’État d’Azure pour voir s’il existe des événements actifs ayant un impact sur l’état du service Kubernetes compatible avec Azure Arc. Si c’est le cas, attendez que l’événement de service soit résolu, puis retentez l’intégration après la suppression de la ressource de cluster connectée existante. S’il n’existe aucun événement de service et que vous continuez à rencontrer des problèmes lors de l’intégration, ouvrez une demande de support afin que nous puissions examiner le problème.
Erreur de revendications de dépassement
Si vous recevez une revendication de dépassement, assurez-vous que votre principal de service ne fait pas partie de plus de 200 groupes Microsoft Entra. Si c’est le cas, vous devez créer et utiliser un autre principal de service qui n’est pas membre de plus de 200 groupes, ou supprimer le principal de service d’origine de certains de ses groupes et réessayer.
Une revendication de dépassement peut également se produire si vous avez configuré un environnement proxy sortant sans autoriser le point de terminaison https://<region>.obo.arc.azure.com:8084/ pour le trafic sortant.
Si aucun de ces cas ne s’applique, créez une demande de support afin que nous puissions examiner le problème.
Problèmes lors de la connexion de clusters Kubernetes à Azure Arc
La connexion de clusters à Azure Arc nécessite l’accès à un abonnement Azure et l’accès de cluster-admin à un cluster cible. Si vous ne pouvez pas joindre le cluster ou si vous disposez d’autorisations insuffisantes, la connexion du cluster à Azure Arc ne pourra pas s’effectuer. Assurez-vous que vous avez satisfait à toutes les conditions préalables pour connecter un cluster.
Conseil
Pour obtenir un guide visuel sur la résolution de problèmes de connexion, consultez Diagnostiquer les problèmes de connexion pour les clusters Kubernetes avec Arc.
Problèmes de résolution du DNS
Pour obtenir de l’aide sur les problèmes liés à la résolution DNS sur votre cluster, consultez Débogage de la résolution DNS.
Problèmes de connectivité réseau sortante
Des problèmes de connectivité réseau sortante sur le cluster peuvent survenir pour différentes raisons. Tout d’abord, vérifiez que toutes les exigences réseau ont été respectées.
Si vous rencontrez des problèmes de connectivité et que votre cluster se trouve derrière un serveur proxy sortant, vérifiez que vous avez transmis les paramètres de proxy pendant l’intégration de votre cluster et que le proxy est correctement configuré. Pour plus d’informations, consultez Se connecter à l’aide d’un serveur proxy sortant.
Vous pourriez voir une erreur similaire à ceci :
An exception has occurred while trying to execute the cluster diagnostic checks in the cluster. Exception: Unable to pull cluster-diagnostic-checks helm chart from the registry 'mcr.microsoft.com/azurearck8s/helmchart/stable/clusterdiagnosticchecks:0.1.2': Error: failed to do request: Head "https://mcr.microsoft.com/v2/azurearck8s/helmchart/stable/clusterdiagnosticchecks/manifests/0.1.2": dial tcp xx.xx.xx.219:443: i/o timeout
Cette erreur se produit lorsque le point de terminaison https://k8connecthelm.azureedge.net est bloqué. Assurez-vous que votre réseau autorise la connectivité à ce point de terminaison et répond à toutes les autres exigences de mise en réseau.
Impossible de récupérer le certificat MSI
Les problèmes de récupération du certificat MSI sont généralement dus à des problèmes réseau. Vérifiez que toutes les exigences réseau ont été respectées, puis réessayez.
Autorisations du cluster insuffisantes
Si le fichier kubeconfig fourni ne dispose pas des autorisations suffisantes pour installer les agents Azure Arc, la commande Azure CLI renvoie une erreur : Error: list: failed to list: secrets is forbidden: User "myuser" cannot list resource "secrets" in API group "" at the cluster scope
Pour résoudre ce problème, vérifiez que l’utilisateur qui connecte le cluster à Azure Arc a le rôle cluster-admin attribué.
Impossible de connecter le cluster OpenShift à Azure Arc
Si az connectedk8s connect arrive à expiration et échoue lors de la connexion d’un cluster OpenShift à Azure Arc :
Assurez-vous que le cluster OpenShift respecte les conditions préalables de version : 4.5.41+, 4.6.35+ ou 4.7.18+.
Avant d’exécuter
az connectedk8s connnect, exécutez cette commande sur le cluster :oc adm policy add-scc-to-user privileged system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa
Délai d’installation
La connexion d’un cluster Kubernetes à Kubernetes avec Azure Arc nécessite l’installation d’agents Azure Arc sur le cluster. Si le cluster s’exécute sur une connexion Internet lente, l’extraction de l’image conteneur pour les agents peut dépasser le délai d’expiration d’Azure CLI.
Erreur de délai d’attente Helm
Le message d’erreur Unable to install helm release: Error: UPGRADE Failed: time out waiting for the condition peut s’afficher. Pour résoudre ce problème, procédez comme suit :
Exécutez la commande suivante :
kubectl get pods -n azure-arcVérifiez si les pods
clusterconnect-agentouconfig-agentaffichentcrashloopbackoff, ou si tous les conteneurs ne sont pas en cours d’exécution :NAME READY STATUS RESTARTS AGE cluster-metadata-operator-664bc5f4d-chgkl 2/2 Running 0 4m14s clusterconnect-agent-7cb8b565c7-wklsh 2/3 CrashLoopBackOff 0 1m15s clusteridentityoperator-76d645d8bf-5qx5c 2/2 Running 0 4m15s config-agent-65d5df564f-lffqm 1/2 CrashLoopBackOff 0 1m14sSi l’
azure-identity-certificaten’est pas présent, l’identité managée affectée par le système n’a pas été installée.kubectl get secret -n azure-arc -o yaml | grep name:name: azure-identity-certificatePour résoudre ce problème, essayez de supprimer le déploiement Arc en exécutant la commande
az connectedk8s deleteet en le réinstallant. Si le problème persiste, il peut s’agir d’un problème avec vos paramètres proxy. Dans ce cas, essayez de connecter votre cluster à Azure Arc via un proxy pour connecter votre cluster à Arc via un proxy. Vérifiez également que tous les prérequis réseau sont satisfaits.Si les pods
clusterconnect-agentetconfig-agentsont en cours d’exécution, mais que le podkube-aad-proxyest manquant, vérifiez vos stratégies de sécurité des pods. Ce pod utilise le compte de serviceazure-arc-kube-aad-proxy-sa, qui ne dispose pas d’autorisations d’administrateur, mais qui nécessite l’autorisation de monter le chemin d’hôte.Si le pod
kube-aad-proxyest bloqué à l’étatContainerCreating, vérifiez si le certificat kube-aad-proxy a été téléchargé sur le cluster.kubectl get secret -n azure-arc -o yaml | grep name:name: kube-aad-proxy-certificateSi le certificat est manquant, supprimez le déploiement et essayez à nouveau de l’intégrer en utilisant un autre nom pour le cluster. Si le problème persiste, créez une demande de support.
Erreur du module CryptoHash
Lorsque vous tentez d’intégrer des clusters Kubernetes à la plateforme Azure Arc, l’environnement local (par exemple, votre console cliente) peut retourner le message d’erreur suivant :
Cannot load native module 'Crypto.Hash._MD5'
Parfois, les modules dépendants ne peuvent pas être téléchargés correctement lors de l’ajout des extensions connectedk8s et k8s-configuration via Azure CLI ou Azure PowerShell. Pour résoudre ce problème, supprimez manuellement les extensions, puis ajoutez-les dans l’environnement local.
Pour supprimer les extensions, utilisez :
az extension remove --name connectedk8s
az extension remove --name k8s-configuration
Pour ajouter les extensions, utilisez :
az extension add --name connectedk8s
az extension add --name k8s-configuration
Problèmes de connexion au cluster
Si votre cluster se trouve derrière un proxy ou un pare-feu sortants, vérifiez que les connexions websocket sont activées pour *.servicebus.windows.net, ce qui est requis spécifiquement pour la fonctionnalité Connexion de cluster. En outre, vérifiez que vous utilisez la dernière version de l’extension Azure CLI connectedk8s si vous rencontrez des problèmes lors de la connexion au cluster.
Si les pods clusterconnect-agent et kube-aad-proxy sont manquants, la fonctionnalité de connexion au cluster est probablement désactivée sur le cluster. Si c’est le cas, az connectedk8s proxy ne parvient pas à établir de session avec le cluster et une erreur Cannot connect to the hybrid connection because no agent is connected in the target arc resource. peut survenir
Pour résoudre cette erreur, activez la fonctionnalité Connexion de cluster sur votre cluster :
az connectedk8s enable-features --features cluster-connect -n $CLUSTER_NAME -g $RESOURCE_GROUP
Pour plus d’informations, consultez Utiliser la connexion au cluster pour se connecter en toute sécurité aux clusters Kubernetes compatibles avec Azure Arc.
Activer les emplacements personnalisés à l’aide du principal de service
Lorsque vous connectez votre cluster à Azure Arc ou que vous activez des emplacements personnalisés sur un cluster existant, vous pouvez voir l'avertissement suivant :
Unable to fetch oid of 'custom-locations' app. Proceeding without enabling the feature. Insufficient privileges to complete the operation.
Cet avertissement se produit lorsque vous utilisez un principal de service pour vous connecter à Azure alors qu’il n’a pas les autorisations nécessaires. Pour éviter cette erreur, procédez comme suit :
Connectez-vous à Azure CLI à l’aide de votre compte d’utilisateur. Récupérez l’ID d’objet de l’application Microsoft Entra utilisée par le service Azure Arc :
az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query objectId -o tsvConnectez-vous à Azure CLI à l’aide du principal de service. Utilisez la valeur
<objectId>de l’étape précédente pour activer les emplacements personnalisés sur le cluster :- Pour activer des emplacements personnalisés lors de la connexion du cluster à Arc, exécutez
az connectedk8s connect -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId> - Pour activer les emplacements personnalisés sur un cluster Kubernetes avec Azure Arc existant, exécutez
az connectedk8s enable-features -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId> --features cluster-connect custom-locations
- Pour activer des emplacements personnalisés lors de la connexion du cluster à Arc, exécutez
Étapes suivantes
- Apprenez comment diagnostiquer les problèmes de connexion grâce à une procédure visuelle pas à pas.
- Consultez les conseils de résolution des problèmes liés aux extensions de cluster.