Partager via

Problèmes de connectivité de Tunnel

  • Article

Microsoft Azure Kubernetes Service (AKS) utilise un composant spécifique pour la communication tunnelée et sécurisée entre les nœuds et le plan de contrôle. Le tunnel se compose d’un serveur côté plan de contrôle et d’un client côté nœuds de cluster. Cet article explique comment résoudre et résoudre les problèmes liés à la connectivité de tunnel dans AKS.

Diagramme du sous-réseau et du réseau virtuel Azure gérés par le client, ainsi que du tunnel de l’API vers le pod de tunnel.

Note

Auparavant, le composant tunnel AKS était tunnel-front. Il a maintenant été migré vers le service Konnectivity, un composant Kubernetes en amont. Pour plus d’informations sur cette migration, consultez les notes de publication et le journal des modifications AKS.

Prerequisites

Symptômes

Vous recevez un message d’erreur semblable aux exemples suivants sur le port 10250 :

Erreur du serveur : Obtenir « https:// aks-node-name> :10250/containerLogs/namespace>/<<pod-name/<container-name>> » : dial tcp <aks-node-ip> :10250 : délai d’expiration d’i/o<

Erreur du serveur : erreur de numérotation du serveur principal : composer tcp <aks-node-ip> :10250 : délai d’expiration d’e/s

Le serveur d’API Kubernetes utilise le port 10250 pour se connecter au kubelet d’un nœud pour récupérer les journaux. Si le port 10250 est bloqué, les journaux kubectl et d’autres fonctionnalités fonctionnent uniquement pour les pods qui s’exécutent sur les nœuds dans lesquels le composant tunnel est planifié. Pour plus d’informations, consultez les ports et protocoles Kubernetes : Nœuds Worker.

Étant donné que les composants de tunnel ou la connectivité entre le serveur et le client ne peuvent pas être établis, les fonctionnalités telles que les suivantes ne fonctionnent pas comme prévu :

  • Webhooks du contrôleur d’admission

  • Capacité de récupération des journaux (à l’aide de la commande kubectl logs )

  • Exécution d’une commande dans un conteneur ou obtention à l’intérieur d’un conteneur (à l’aide de la commande kubectl exec )

  • Transfert d’un ou de plusieurs ports locaux d’un pod (à l’aide de la commande kubectl port-forward )

Cause 1 : un groupe de sécurité réseau (NSG) bloque le port 10250

Note

Cette cause s’applique à tous les composants de tunnel que vous pouvez avoir dans votre cluster AKS.

Vous pouvez utiliser un groupe de sécurité réseau Azure (NSG) pour filtrer le trafic réseau vers et depuis des ressources Azure dans un réseau virtuel Azure. Un groupe de sécurité réseau contient des règles de sécurité qui autorisent ou refusent le trafic réseau entrant et sortant entre plusieurs types de ressources Azure. Pour chaque règle, vous pouvez spécifier la source et la destination, le port et le protocole. Pour plus d’informations, consultez l’article Façon dont les groupes de sécurité réseau filtrent le trafic.

Si le groupe de sécurité réseau bloque le port 10250 au niveau du réseau virtuel, les fonctionnalités de tunnel (telles que les journaux et l’exécution du code) fonctionnent uniquement pour les pods planifiés sur les nœuds où les pods de tunnel sont planifiés. Les autres pods ne fonctionneront pas, car leurs nœuds ne pourront pas atteindre le tunnel et le tunnel est planifié sur d’autres nœuds. Pour vérifier cet état, vous pouvez tester la connectivité à l’aide de commandes netcat (nc) ou telnet. Vous pouvez exécuter la commande az vmss run-command invoke pour effectuer le test de connectivité et vérifier si elle réussit, expire ou provoque un autre problème :

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
    --output tsv \
    --query 'value[0].message'

Solution 1 : Ajouter une règle de groupe de sécurité réseau pour autoriser l’accès au port 10250

Si vous utilisez un groupe de sécurité réseau et que vous avez des restrictions spécifiques, veillez à ajouter une règle de sécurité qui autorise le trafic pour le port 10250 au niveau du réseau virtuel. L’image de Portail Azure suivante montre un exemple de règle de sécurité :

Capture d’écran du volet Ajouter une règle de sécurité entrante dans le Portail Azure. La zone plages de ports de destination est définie sur 10250 pour la nouvelle règle de sécurité.

Si vous souhaitez être plus restrictif, vous pouvez autoriser l’accès au port 10250 uniquement au niveau du sous-réseau.

Note

  • Le champ Priorité doit être ajusté en conséquence. Par exemple, si vous avez une règle qui refuse plusieurs ports (y compris le port 10250), la règle affichée dans l’image doit avoir un nombre de priorité inférieur (les nombres inférieurs ont une priorité plus élevée). Pour plus d’informations sur Priority, consultez Règles de sécurité.

  • Si vous ne voyez aucune modification comportementale après avoir appliqué cette solution, vous pouvez recréer les pods du composant tunnel. La suppression de ces pods entraîne la recréation de ces pods.

Cause 2 : l’outil PARE-feu non compliqué (UFW) bloque le port 10250

Note

Cette cause s’applique à tout composant de tunnel que vous avez dans votre cluster AKS.

Le pare-feu non compliqué (UFW) est un programme de ligne de commande pour la gestion d’un pare-feu netfilter. Les nœuds AKS utilisent Ubuntu. Par conséquent, UFW est installé sur les nœuds AKS par défaut, mais UFW est désactivé.

Par défaut, si UFW est activé, il bloque l’accès à tous les ports, y compris le port 10250. Dans ce cas, il est peu probable que vous puissiez utiliser Secure Shell (SSH) pour vous connecter aux nœuds de cluster AKS pour la résolution des problèmes. Cela est dû au fait que UFW peut également bloquer le port 22. Pour résoudre les problèmes, vous pouvez exécuter la commande az vmss run-command invoke pour appeler une commande ufw qui vérifie si UFW est activé :

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw status" \
    --output tsv \
    --query 'value[0].message'

Que se passe-t-il si les résultats indiquent que UFW est activé et qu’il n’autorise pas spécifiquement le port 10250 ? Dans ce cas, les fonctionnalités de tunnel (telles que les journaux et l’exécution du code) ne fonctionnent pas pour les pods planifiés sur les nœuds sur lesquels UFW est activé. Pour résoudre le problème, appliquez l’une des solutions suivantes sur UFW.

Important

Avant d’utiliser cet outil pour apporter des modifications, passez en revue la stratégie de prise en charge AKS (en particulier la maintenance et l’accès des nœuds) pour empêcher votre cluster d’entrer dans un scénario non pris en charge.

Note

Si vous ne voyez aucune modification comportementale après l’application d’une solution, vous pouvez recréer les pods du composant tunnel. La suppression de ces pods entraîne la recréation de ces pods.

Solution 2a : Désactiver le pare-feu non compliqué

Exécutez la commande suivante az vmss run-command invoke pour désactiver UFW :

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw disable" \
    --output tsv \
    --query 'value[0].message'

Solution 2b : Configurer un pare-feu non compliqué pour autoriser l’accès au port 10250

Pour forcer UFW à autoriser l’accès au port 10250, exécutez la commande suivante az vmss run-command invoke :

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw allow 10250" \
    --output tsv \
    --query 'value[0].message'

Cause 3 : l’outil iptables bloque le port 10250

Note

Cette cause s’applique à tout composant de tunnel que vous avez dans votre cluster AKS.

L’outil iptables permet à un administrateur système de configurer les règles de filtre de paquets IP d’un pare-feu Linux. Vous pouvez configurer les règles pour bloquer la iptables communication sur le port 10250.

Vous pouvez afficher les règles de vos nœuds pour vérifier si le port 10250 est bloqué ou si les paquets associés sont supprimés. Pour ce faire, exécutez la commande suivante iptables :

iptables --list --line-numbers

Dans la sortie, les données sont regroupées en plusieurs chaînes, y compris la INPUT chaîne. Chaque chaîne contient une table des règles sous les en-têtes de colonne suivants :

  • num (numéro de règle)
  • target
  • prot (protocole)
  • opt
  • source
  • destination

La INPUT chaîne contient-elle une règle dans laquelle la cible est DROP, le protocole est tcpet la destination est tcp dpt:10250? Si c’est le cas, iptables bloque l’accès au port de destination 10250.

Solution 3 : Supprimer la règle iptables qui bloque l’accès sur le port 10250

Exécutez l’une des commandes suivantes pour supprimer la iptables règle qui empêche l’accès au port 10250 :

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250

iptables --delete INPUT <input-rule-number>

Pour résoudre votre scénario exact ou potentiel, nous vous recommandons de vérifier le manuel iptables en exécutant la iptables --help commande.

Important

Avant d’utiliser cet outil pour apporter des modifications, passez en revue la stratégie de prise en charge AKS (en particulier la maintenance et l’accès des nœuds) pour empêcher votre cluster d’entrer dans un scénario non pris en charge.

Cause 4 : Le port de sortie 1194 ou 9000 n’est pas ouvert

Note

Cette cause s’applique uniquement aux pods et aks-link aux tunnel-front pods.

Existe-t-il des restrictions de trafic de sortie, comme à partir d’un pare-feu AKS ? S’il existe, le port 9000 est requis pour activer les fonctionnalités correctes du tunnel-front pod. De même, le port 1194 est requis pour le aks-link pod.

Konnectivity s’appuie sur le port 443. Par défaut, ce port est ouvert. Par conséquent, vous n’avez pas à vous soucier des problèmes de connectivité sur ce port.

Solution 4 : Ouvrir le port 9000

Bien qu’il tunnel-front ait été déplacé vers le service Konnectivity, certains clusters AKS utilisent tunnel-fronttoujours , qui s’appuie sur le port 9000. Assurez-vous que l’appliance virtuelle ou tout appareil réseau ou logiciel autorise l’accès au port 9000. Pour plus d’informations sur les règles et dépendances requises, consultez Les règles réseau requises d’Azure Global.

Cause 5 : Épuisement du port SNAT (Source Network Address Translation)

Note

Cette cause s’applique à tout composant de tunnel que vous avez dans votre cluster AKS. Toutefois, elle ne s’applique pas aux clusters AKS privés. L’épuisement des ports de traduction d’adresses réseau source (SNAT) peut se produire uniquement pour la communication publique. Pour les clusters AKS privés, le serveur d’API se trouve à l’intérieur du réseau virtuel ou du sous-réseau AKS.

Si l’épuisement des ports SNAT se produit (ports SNAT ayant échoué), les nœuds ne peuvent pas se connecter au serveur d’API. Le conteneur de tunnel se trouve côté serveur d’API. Par conséquent, la connectivité de tunnel n’est pas établie.

Si les ressources de port SNAT sont épuisées, les flux sortants échouent jusqu’à ce que les flux existants libèrent certains ports SNAT. Azure Load Balancer récupère les ports SNAT lorsque le flux se ferme. Il utilise un délai d’inactivité de quatre minutes pour récupérer les ports SNAT des flux inactifs.

Vous pouvez afficher les ports SNAT à partir des métriques de l’équilibreur de charge AKS ou des diagnostics de service, comme décrit dans les sections suivantes. Pour plus d’informations sur la façon d’afficher les ports SNAT, consultez Comment faire vérifier mes statistiques de connexion sortante ?.

Métriques de l’équilibreur de charge AKS

Pour utiliser les métriques d’équilibreur de charge AKS pour afficher les ports SNAT, procédez comme suit :

  1. Dans le Portail Azure, recherchez et sélectionnez services Kubernetes.

  2. Dans la liste des services Kubernetes, sélectionnez le nom de votre cluster.

  3. Dans le volet de menu du cluster, recherchez le titre Paramètres , puis sélectionnez Propriétés.

  4. Sélectionnez le nom répertorié sous groupe de ressources d’infrastructure.

  5. Sélectionnez l’équilibreur de charge Kubernetes .

  6. Dans le volet de menu de l’équilibreur de charge, recherchez le titre Surveillance , puis sélectionnez Métriques.

  7. Pour le type de métrique, sélectionnez Nombre de connexions SNAT.

  8. Sélectionnez Appliquer le fractionnement.

  9. Définissez Fractionner par état de connexion.

Diagnostics de service

Pour utiliser les diagnostics de service pour afficher les ports SNAT, procédez comme suit :

  1. Dans le Portail Azure, recherchez et sélectionnez services Kubernetes.

  2. Dans la liste des services Kubernetes, sélectionnez le nom de votre cluster.

  3. Dans le volet de menu du cluster, sélectionnez Diagnostiquer et résoudre les problèmes.

  4. Sélectionnez Problèmes de connectivité.

  5. Sous Connexion SNAT et Allocation de port, sélectionnez Afficher les détails.

  6. Si nécessaire, utilisez le bouton Intervalle de temps pour personnaliser l’intervalle de temps.

Solution 5a : Vérifiez que l’application utilise le regroupement de connexions

Ce comportement peut se produire car une application ne réutilisant pas les connexions existantes. Nous vous recommandons de ne pas créer une connexion sortante par demande. Une telle configuration peut entraîner l’épuisement de la connexion. Vérifiez si le code de l’application suit les bonnes pratiques et l’utilisation du regroupement de connexions. La plupart des bibliothèques prennent en charge le regroupement de connexions. Par conséquent, vous ne devez pas avoir à créer une connexion sortante par requête.

Solution 5b : Ajuster les ports sortants alloués

Si tout est ok dans l’application, vous devez ajuster les ports sortants alloués. Pour plus d’informations sur l’allocation de ports sortants, consultez Configurer les ports sortants alloués.

Solution 5c : Utiliser une passerelle NAT (Managed Network Address Translation) lorsque vous créez un cluster

Vous pouvez configurer un nouveau cluster pour utiliser une passerelle NAT (Managed Network Address Translation) pour les connexions sortantes. Pour plus d’informations, consultez Créer un cluster AKS avec une passerelle NAT managée.

Exclusion de responsabilité sur les coordonnées externes

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent changer sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.

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.