Partager via

Résoudre les erreurs lors du déploiement d’extensions de cluster AKS

  • Article

Cet article explique comment résoudre les erreurs qui se produisent lorsque vous déployez des extensions de cluster pour Microsoft Azure Kubernetes Service (AKS).

Erreurs de création d’extension

Erreur : Impossible d’obtenir une réponse de l’agent dans le temps

Cette erreur se produit si les services Azure ne reçoivent pas de réponse de l’agent d’extension de cluster. Cette situation peut se produire, car le cluster AKS ne peut pas établir de connexion avec Azure.

Cause 1 : Les pods de l’agent d’extension de cluster et du gestionnaire ne sont pas initialisés

L’agent d’extension de cluster et le gestionnaire sont des composants système essentiels qui sont responsables de la gestion du cycle de vie des applications Kubernetes. L’initialisation de l’agent d’extension de cluster et des pods de gestionnaire peut échouer en raison des problèmes suivants :

  • Limitations des ressources
  • Restrictions de stratégie
  • Teintes de nœud, telles que NoSchedule
Solution 1 : Vérifiez que l’agent d’extension de cluster et les pods de gestionnaire fonctionnent correctement

Pour résoudre ce problème, vérifiez que l’agent d’extension de cluster et les pods de gestionnaire sont correctement planifiés et peuvent démarrer. Si les pods sont bloqués dans un état non lu, vérifiez la description du pod en exécutant la commande suivante kubectl describe pod pour obtenir plus de détails sur les problèmes sous-jacents (par exemple, les teintes qui empêchent la planification, la mémoire insuffisante ou les restrictions de stratégie) :

kubectl describe pod -n kube-system extension-operator-{id}

Voici un exemple de sortie de commande :

kube-system         extension-agent-55d4f4795f-sqx7q             2/2     Running   0          2d19h
kube-system         extension-operator-56c8d5f96c-nvt7x          2/2     Running   0          2d19h

Pour les clusters connectés à ARC, exécutez la commande suivante pour vérifier la description du pod :

kubectl describe pod -n azure-arc extension-manager-{id}

Voici un exemple de sortie de commande :

NAMESPACE         NAME                                          READY   STATUS             RESTARTS        AGE
azure-arc         cluster-metadata-operator-744f8bfbd4-7pssr    0/2     ImagePullBackOff   0               6d19h
azure-arc         clusterconnect-agent-7557d99d5c-rtgqh         0/3     ImagePullBackOff   0               6d19h
azure-arc         clusteridentityoperator-9b8b88f97-nr8hf       0/2     ImagePullBackOff   0               6d19h
azure-arc         config-agent-6d5fd59b8b-khw2d                 0/2     ImagePullBackOff   0               6d19h
azure-arc         controller-manager-5bc97f7db6-rt2zs           0/2     ImagePullBackOff   0               6d19h
azure-arc         extension-events-collector-7596688867-sqzv2   0/2     ImagePullBackOff   0               6d19h
azure-arc         extension-manager-86bbb949-6s59q              0/3     ImagePullBackOff   0               6d19h
azure-arc         flux-logs-agent-5f55888db9-wnr4c              0/1     ImagePullBackOff   0               6d19h
azure-arc         kube-aad-proxy-646c475dcc-92b86               0/2     ImagePullBackOff   0               6d19h
azure-arc         logcollector-5cbc659bfb-9v96d                 0/1     ImagePullBackOff   0               6d19h
azure-arc         metrics-agent-5794866b46-j9949                0/2     ImagePullBackOff   0               6d19h
azure-arc         resource-sync-agent-6cf4cf7486-flgwc          0/2     ImagePullBackOff   0               6d19h

Lorsque l’agent d’extension de cluster et les pods de gestionnaire sont opérationnels et intègres, ils établissent une communication avec les services Azure pour installer et gérer des applications Kubernetes.

Cause 2 : Un problème affecte le bloc de sortie ou le pare-feu

Si l’agent d’extension de cluster et les pods de gestionnaire sont sains et que vous rencontrez toujours l’erreur « Impossible d’obtenir une réponse de l’agent en temps », un problème de blocage ou de pare-feu de sortie existe probablement. Ce problème peut empêcher l’agent d’extension de cluster et les pods de gestionnaire de communiquer avec Azure.

Solution 2 : Vérifiez que les conditions préalables réseau sont remplies

Pour résoudre ce problème, veillez à suivre les prérequis réseau décrits dans les règles de réseau sortant et de nom de domaine complet pour les clusters Azure Kubernetes Service (AKS).

Cause 3 : Le trafic n’est pas autorisé

L’agent d’extension tente sans succès d’appeler des <region>.dp.kubernetesconfiguration.azure.com points de terminaison de service de plan de données. Cet échec génère une entrée « Errorcode : 403, Message This traffic is not authorized » dans les journaux des pods de l’agent d’extension.

kubectl logs -n kube-system extension-agent-<pod-guid>
{  "Message": "2024/02/07 06:04:43 \"Errorcode: 403, Message This traffic is not authorized., Target /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/provider/managedclusters/clusters/<cluster-name>/configurations/getPendingConfigs\"",  "LogType": "ConfigAgentTrace",  "LogLevel": "Information",  "Environment": "prod",  "Role": "ClusterConfigAgent",  "Location": "<region>,  "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>",  "CorrelationId": "",  "AgentName": "ConfigAgent",  "AgentVersion": "1.14.5",  "AgentTimestamp": "2024/02/07 06:04:43.672"  }
{  "Message": "2024/02/07 06:04:43 Failed to GET configurations with err : {\u003cnil\u003e}",  "LogType": "ConfigAgentTrace",  "LogLevel": "Information",  "Environment": "prod",  "Role": "ClusterConfigAgent",  "Location": "<region>",  "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>",  "CorrelationId": "",  "AgentName": "ConfigAgent",  "AgentVersion": "1.14.5",  "AgentTimestamp": "2024/02/07 06:04:43.672"  }

Cette erreur se produit si un PrivateLinkScope préexistant existe dans le plan de données d’une extension pour Kubernetes avec Azure Arc, et que le réseau virtuel (ou le serveur DNS privé) est partagé entre Kubernetes avec Azure Arc et le cluster géré par AKS. Cette configuration réseau entraîne le trafic sortant AKS à partir du plan de données d’extension pour acheminer également via la même adresse IP privée au lieu d’une adresse IP publique.

Exécutez la commande nslookup suivante dans votre cluster AKS pour récupérer l’adresse IP privée spécifique à laquelle le point de terminaison du plan de données est résolu :

PS D:\> kubectl exec -it -n kube-system extension-agent-<pod-guid> -- nslookup  <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
<region>.dp.kubernetesconfiguration.azure.com        canonical name = <region>.privatelink.dp.kubernetesconfiguration.azure.com
Name:   <region>.privatelink.dp.kubernetesconfiguration.azure.com
Address: 10.224.1.184

Lorsque vous recherchez l’adresse IP privée dans le Portail Azure, les résultats de la recherche pointent vers la ressource exacte : réseau virtuel, zone DNS privée, serveur DNS privé, et ainsi de suite. Cette ressource a un point de terminaison privé configuré pour le plan de données d’extension pour Kubernetes avec Azure Arc.

Pour résoudre ce problème, nous vous recommandons de créer des réseaux virtuels distincts pour les calculs Kubernetes et AKS avec Azure Arc.

Solution 3.2 : Créer un remplacement CoreDNS

Si la solution recommandée n’est pas possible dans votre situation, créez un remplacement CoreDNS pour le point de terminaison du plan de données d’extension pour passer sur le réseau public. Pour plus d’informations sur la personnalisation de CoreDNS, consultez la section « Plug-in Hosts » de « Personnaliser CoreDNS avec Azure Kubernetes Service ».

Pour créer un remplacement CoreDNS, procédez comme suit :

  1. Recherchez l’adresse IP publique du point de terminaison du plan de données d’extension en exécutant la nslookup commande. Veillez à modifier la région (par exemple) eastus2euapen fonction de l’emplacement de votre cluster AKS :

    nslookup <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
Name:    clusterconfig<region>.<region>.cloudapp.azure.com
Address:  20.39.12.229
Aliases:  <region>.dp.kubernetesconfiguration.azure.com
         <region>.privatelink.dp.kubernetesconfiguration.azure.com
         <region>.dp.kubernetesconfiguration.trafficmanager.net

  2. Créez une sauvegarde de la configuration coreDNS existante :

    kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yaml

  3. Remplacez le mappage du point de terminaison de plan de données régional (par exemple, eastus2euap) par l’adresse IP publique. Pour ce faire, créez un fichier YAML nommé corednsms.yaml, puis copiez l’exemple de configuration suivant dans le nouveau fichier. (Veillez à mettre à jour l’adresse et le nom d’hôte à l’aide des valeurs de votre environnement.)

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom      # This is the name of the configuration map that you can overwrite with your changes.
  namespace: kube-system
data:
  extensionsdp.override: |  # You can select any name here, but it must have the .override file name extension.
    hosts {
      20.39.12.229 <region>.dp.kubernetesconfiguration.azure.com
      fallthrough
    }

  4. Pour créer configMap, exécutez la kubectl apply commande, en spécifiant le nom de votre fichier manifeste YAML :

    kubectl apply -f corednsms.yaml

  5. Pour recharger configMap et activer Kubernetes Scheduler pour redémarrer CoreDNS sans temps d’arrêt, exécutez la commande kubectl rollout restart :

    kubectl -n kube-system rollout restart deployment coredns

  6. Réexécutez la nslookup commande pour vous assurer que le point de terminaison du plan de données est résolu sur l’adresse IP publique fournie :

    kubectl exec -it -n kube-system extension-agent-55d4f4795f-nld9q -- nslookup  [region].dp.kubernetesconfiguration.azure.com
Name:   <region>.dp.kubernetesconfiguration.azure.com
Address: 20.39.12.229

Les journaux des pods de l’agent d’extension ne doivent plus consigner les entrées d’erreur « Code d’erreur : 403, Message Ce trafic n’est pas autorisé ». Au lieu de cela, les journaux doivent contenir des codes de réponse « 200 ».

kubectl logs -n kube-system extension-agent-{id} 
{  "Message": "GET configurations returned response code {200}",  "LogType": "ConfigAgentTrace",  "LogLevel": "Information",  "Environment": "prod",  "Role": "ClusterConfigAgent",  "Location": "<region>",  "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>",  "CorrelationId": "",  "AgentName": "ConfigAgent",  "AgentVersion": "1.14.5"  }

Erreur : Les pods d’extension ne peuvent pas être planifiés si tous les pools de nœuds du cluster sont « CriticalAddonsOnly » teintes

Lorsque cette erreur se produit, l’entrée suivante est consignée dans le journal de l’agent d’extension :

Erreur du pod d’extension : 0/2 nœuds sont disponibles : 2 nœuds n’ont pas été tolérés {CriticalAddonsOnly : true}. préemption : 0/2 nœuds sont disponibles : 2 Préemption n’est pas utile pour la planification.

Cause

Cette erreur se produit lorsque vous essayez d’activer des extensions (telles que le runtime d’application distribué (DAPR) sur un cluster AKS qui a CriticalAddonsOnly des pools de nœuds contaminés. Dans ce cas, les pods d’extension ne sont pas planifiés sur un nœud, car aucune tolérance n’existe pour ces teintes.

Pour afficher la situation d’erreur, examinez les pods d’extension pour vérifier qu’ils sont bloqués dans un état en attente :

kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}

NAME                                   READY   STATUS    RESTARTS   AGE
{podname}                              0/2     Pending   0          2d6h

Décrivez les pods pour voir qu’ils ne peuvent pas être planifiés en raison d’une teinte non prise en charge :

kubectl describe po -n {namespace-name} {podname}

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  18s   default-scheduler  0/2 nodes are available: 2 node(s) had untolerated taint {CriticalAddonsOnly: true}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.

Note

  • Nous vous recommandons de ne pas installer d’extensions sur CriticalAddOnsOnly des pools de nœuds contaminés, sauf si cela est nécessaire pour les charges de travail d’application.

  • Nous vous recommandons de ne pas utiliser de CriticalAddOnsOnly teinte sur les clusters de pool à nœuds uniques. Si vous utilisez cette teinte dans un cluster qui n’a qu’un seul pool de nœuds, vous ne pouvez pas planifier les pods d’application dans le cluster. Assurez-vous qu’au moins un pool de nœuds dans le cluster n’a pas cette teinte. Pour plus d’informations sur l’utilisation de l’annotationCriticalAddonsOnly, consultez Gérer les pools de nœuds système dans Azure Kubernetes Service (AKS).

Solution 1 : Ajouter un pool de nœuds au cluster

Pour résoudre ce problème, ajoutez un autre pool de nœuds qui n’a pas de CriticalAddonsOnly teinte. Cette action entraîne la planification des pods d’extension sur le nouveau pool de nœuds.

Solution 2 : Supprimer la teinte « CriticalAddonsOnly »

S’il est possible et pratique, vous pouvez supprimer la CriticalAddonsOnly teinte pour installer l’extension sur le cluster.

Erreurs Helm

Vous pouvez rencontrer l’une des erreurs helm suivantes :

Erreur : Délai d’attente de la préparation des ressources

L’installation d’une application Kubernetes échoue et affiche les messages d’erreur suivants :

échec du travail : BackoffLimitExceeded

Délai d’attente de la ressource pour qu’elle arrive à un état prêt/terminé.

Cause

Ce problème a les causes courantes suivantes :

  • Contraintes de ressources : des ressources de mémoire ou d’UC insuffisantes au sein du cluster peuvent empêcher l’initialisation réussie de pods, de travaux ou d’autres ressources Kubernetes. Finalement, cette situation entraîne l’expiration de l’installation. Les contraintes de stratégie ou les teintes de nœud (par exemple NoSchedule) peuvent également bloquer l’initialisation des ressources.

  • Incompatibilités d’architecture : une tentative de planification d’une application Linux sur un nœud Windows (ou inversement) peut entraîner des défaillances dans l’initialisation des ressources Kubernetes.

  • Paramètres de configuration incorrects : les paramètres de configuration incorrects peuvent empêcher le démarrage des pods.

Solution

Pour résoudre ce problème, effectuez les opérations suivantes :

  1. Vérifiez les ressources : vérifiez que votre cluster Kubernetes dispose de ressources suffisantes et que la planification des pods est autorisée sur les nœuds (vous devez prendre en compte les teintes). Vérifiez que les ressources de mémoire et d’UC répondent aux exigences.

  2. Inspecter les événements : vérifiez les événements dans l’espace de noms Kubernetes pour identifier les problèmes potentiels susceptibles d’empêcher les pods, les travaux ou d’autres ressources Kubernetes d’atteindre un état prêt.

  3. Vérifiez les graphiques et configurations Helm : de nombreuses applications Kubernetes utilisent des graphiques Helm pour déployer des ressources sur le cluster. Certaines applications peuvent nécessiter une entrée utilisateur par le biais de paramètres de configuration. Assurez-vous que toutes les valeurs de configuration fournies sont précises et répondent aux exigences d’installation.

Erreur : Impossible de télécharger le graphique Helm à partir de l’URL du dépôt

Cette erreur est due à des problèmes de connectivité qui se produisent entre le cluster et le pare-feu en plus des problèmes de blocage de sortie. Pour résoudre ce problème, consultez les règles de réseau sortant et de nom de domaine complet pour les clusters Azure Kubernetes Service (AKS).

Erreur : Échec du rendu du graphique Helm avec des valeurs données

Cette erreur se produit si les applications Kubernetes s’appuient sur des graphiques Helm pour déployer des ressources au sein du cluster Kubernetes. Ces applications peuvent nécessiter une entrée utilisateur fournie par le biais de paramètres de configuration qui sont passés en tant que valeurs Helm pendant l’installation. Si l’un de ces paramètres de configuration crucial est manquant ou incorrect, le graphique Helm peut ne pas s’afficher.

Pour résoudre ce problème, consultez la documentation de l’extension ou de l’application pour déterminer si vous avez omis des valeurs obligatoires ou fourni des valeurs incorrectes pendant l’installation de l’application. Ces instructions peuvent vous aider à résoudre les problèmes de rendu de graphique Helm causés par des valeurs de configuration manquantes ou inexactes.

Erreur : La ressource existe déjà dans votre cluster

Cette erreur se produit si un conflit existe entre les ressources Kubernetes au sein de votre cluster et les ressources Kubernetes que l’application tente d’installer. Le message d’erreur spécifie généralement le nom de la ressource en conflit.

Si la ressource en conflit est essentielle et ne peut pas être remplacée, il se peut que vous ne puissiez pas installer l’application. Si la ressource n’est pas critique et peut être supprimée, supprimez la ressource en conflit, puis réessayez l’installation.

Erreur : l’opération est déjà en cours pour Helm

Cette erreur se produit si une opération est déjà en cours pour une version particulière. Pour résoudre ce problème, attendez 10 minutes, puis réessayez l’opération.

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.