Problèmes de connectivité de tunnel

Microsoft Azure Kubernetes Service (AKS) utilise un composant spécifique pour la communication sécurisée et tunnelné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 les problèmes liés à la connectivité de tunnel dans AKS.

Remarque

Par défaut, et selon la région, le composant de tunnel était tunnel-front. Lors de la mise à jour vers la fonctionnalité tunnel-front contrat de niveau de service (SLA), a été remplacé par le aks-link composant de tunnel qui utilisait OpenVPN. AKS migre vers Konnectivity. Il s’agit d’un composant Kubernetes amont qui remplace et tunnel-frontaks-link. Pour plus d’informations sur la migration vers Konnectivity en tant que composant de tunnel, consultez les notes de publication aks et le journal des modifications.

Conditions préalables

• Azure CLI

Symptômes

Vous recevez un message d’erreur qui ressemble aux exemples suivants concernant le port 10250 :

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

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

Le serveur d’API Kubernetes utilise le port 10250 pour se connecter au kubelet d’un nœud afin de 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 de tunnel est planifié. Pour plus d’informations, consultez 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, des fonctionnalités telles que les suivantes ne fonctionnent pas comme prévu :

• Webhooks contrôleurs d’admission

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

• Exécution d’une commande dans un conteneur ou accès à 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 bloque le port 10250

Remarque

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

Vous pouvez utiliser un groupe de sécurité réseau ( NSG) Azure pour filtrer le trafic réseau à destination et en provenance 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 Comment les groupes de sécurité réseau filtrent le trafic réseau.

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 des 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 s’il 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 Portail Azure suivante montre un exemple de 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.

Remarque

• 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 numéro de priorité inférieur (les nombres inférieurs ont une priorité plus élevée). Pour plus d’informations sur la priorité, consultez Règles de sécurité.

• Si vous ne voyez aucun changement de comportement après avoir appliqué cette solution, vous pouvez recréer les pods de composant de tunnel. La suppression de ces pods entraîne leur recréation.

Cause 2 : L’outil UNCOMPLICATED Firewall (UFW) bloque le port 10250

Remarque

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

Uncomplicated Firewall (UFW) est un programme en 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 à des nœuds de cluster AKS à des fins de 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 de code) ne fonctionnent pas pour les pods planifiés sur les nœuds pour lesquels UFW est activé. Pour résoudre le problème, appliquez l’une des solutions suivantes sur UFW.

Importante

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

Remarque

Si vous ne voyez aucun changement de comportement après avoir appliqué une solution, vous pouvez recréer les pods du composant de tunnel. La suppression de ces pods entraîne leur recréation.

Solution 2a : Désactiver un pare-feu simple

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 simple 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

Remarque

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 pour que vos nœuds case activée 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 de règles sous les en-têtes de colonne suivants :

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

INPUT La 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 règle qui empêche l’accès iptables au port 10250 :

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

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

Pour répondre à votre scénario exact ou potentiel, nous vous recommandons d’case activée le manuel iptables en exécutant la iptables --help commande .

Importante

Avant d’utiliser cet outil pour apporter des modifications, passez en revue la stratégie de prise en charge AKS (en particulier la maintenance des nœuds et l’accès) 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

Remarque

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

Existe-t-il des restrictions de trafic de sortie, par exemple à partir d’un pare-feu AKS ? Si tel est le cas, 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 1194 ou 9000

Assurez-vous que le Appliance virtuel autorise l’accès au port 1194 ou 9000. Pour plus d’informations sur les règles et les dépendances requises, consultez Règles de réseau azure globales requises.

Cause 5 : Épuisement des ports SNAT (Source Network Address Translation)

Remarque

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 SNAT (Source Network Address Translation) peut se produire uniquement pour la communication publique. Pour les clusters AKS privés, le serveur d’API se trouve à l’intérieur du sous-réseau ou du réseau virtuel 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é du 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 à la fermeture du flux. 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 du service diagnostics, comme décrit dans les sections suivantes. Pour plus d’informations sur l’affichage des ports SNAT, consultez Comment faire case activée mes statistiques de connexion sortante ?.

Métriques de l’équilibreur de charge AKS

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

1. Dans la 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 l’en-tête 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 sur État de connexion.

Diagnostics de service

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

1. Dans la 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 ports, sélectionnez Afficher les détails.

6. Si nécessaire, utilisez le bouton Intervalle de temps pour personnaliser la période.

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

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

Solution 5b : Ajuster les ports sortants alloués

Si tout est correct 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 être modifiées 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.