Résoudre les problèmes de mise en réseau de GKE sur une solution Bare Metal

Cette page explique comment résoudre les problèmes de mise en réseau avec Google Distributed Cloud Virtual pour Bare Metal. Des conseils et des informations de dépannage générales sont fournis, ainsi que des suggestions d'outils. Des informations de dépannage DNS et certains problèmes courants liés à MetalLB sont également inclus.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Résoudre les problèmes de connectivité réseau

La mise en réseau de GKE Enterprise repose sur votre infrastructure réseau physique. Par exemple, MetalLB repose sur vos commutateurs qui respectent l'ARP gratuit, l'équilibrage de charge groupé avec Border Gateway Protocol (BGP) repose sur vos routeurs, et tous les nœuds doivent pouvoir communiquer entre eux. Lorsque vous rencontrez un problème de mise en réseau dans vos clusters GKE, vous devez déterminer s'il se situe au niveau des composants de GKE Enterprise ou de votre propre infrastructure.

Déterminez d'abord l'étendue du problème, puis essayez d'identifier les composants concernés. La portée d'un problème peut correspondre à l'une des trois catégories suivantes: l'objet (à partir d'où), la cible (vers laquelle) et la couche réseau.

Le champ d'application du sujet peut correspondre à l'un des éléments suivants:

  • Tous les nœuds (ou le pod hostNetwork) à l'échelle du cluster
  • Tous les pods à l'échelle du cluster.
  • Tous les pods sur un seul nœud ou un ensemble de nœuds.
  • Tous les pods du même déploiement ou DaemonSet.
  • un client externe au cluster.

Le champ d'application de la cible peut correspondre à un ou plusieurs des éléments suivants:

  • Toutes les autres adresses IP de pods du même cluster
  • Toutes les autres adresses IP de pods du même nœud.
  • Adresse IP virtuelle du service ClusterIP du même cluster.
  • Adresse IP virtuelle du service LoadBalancer du même cluster.
  • LoadBalancer d'entrée de couche 7 (Istio).
  • Les autres nœuds du même cluster
  • Nom DNS interne (par exemple, *.svc.cluster.local).
  • Nom DNS externe (par exemple, google.com).
  • Entités extérieures au cluster
  • Entités sur Internet

La couche réseau peut être une ou plusieurs des éléments suivants:

  • Problèmes de couche de liaison de couche 2 tels que système voisin, ARP ou NDP.
  • Problèmes de routage d'adresses IP de couche 3.
  • Problèmes de point de terminaison TCP ou UDP de couche 4.
  • Problèmes HTTP ou HTTPS de couche 7.
  • Problèmes de résolution DNS.

Comprendre la portée d'un problème permet d'identifier les composants impliqués et à quel niveau se situe le problème. Il est important de collecter des informations lorsque le problème survient, car certains problèmes sont temporaires. Par conséquent, les instantanés après la récupération du système n'incluent pas suffisamment d'informations pour l'analyse de l'origine du problème.

Problèmes d&#Ingress

Si le sujet est un client extérieur au cluster et qu'il n'a pas réussi à se connecter à un service LoadBalancer, il s'agit d'un problème de connectivité Nord-Sud. Le schéma suivant montre que, dans un exemple fonctionnel, le trafic entrant transite par la pile de gauche à droite et que le trafic retour remonte dans la pile de droite à gauche.

Le trafic Ingress est transmis de l'utilisateur à l'infrastructure physique, via un équilibreur de charge, jusqu'à anetd / kube-proxy, puis au backend.

En cas de problème avec ce flux de trafic, utilisez l'organigramme de dépannage suivant pour identifier l'origine du problème:

résoudre les problèmes d'entrée réseau en examinant chaque étape suivie par un paquet lors de son déplacement dans votre environnement. Vérifiez si les actions appropriées et la connectivité sont disponibles tout au long du processus.

Dans cet organigramme, les conseils de dépannage suivants permettent de déterminer l'origine du problème:

  • Le paquet quitte-t-il le client ? Si ce n'est pas le cas, vous rencontrez probablement un problème d'infrastructure réseau.
  • Utilisez-vous MetalLB ? Si tel est le cas, le paquet arrive-t-il au nœud LB, et l'ARP est-il envoyé correctement ? Si ce n'est pas le cas, vous avez probablement un problème d'infrastructure réseau.
  • Utilisez-vous F5 BIG-IP et, si oui, avez-vous vérifié la présence de problèmes avec F5 ?
  • La traduction d'adresse réseau (NAT) s'effectue-t-elle correctement ? Si ce n'est pas le cas, vous rencontrez probablement un problème avec kube-proxy / Dataplane V2.
  • Le paquet arrive-t-il au nœud de calcul ? Si ce n'est pas le cas, vous rencontrez probablement un problème lié à Dataplane v2 entre pods.
  • Le paquet arrive-t-il au pod ? Si ce n'est pas le cas, vous rencontrez probablement un problème de transfert local Dataplane v2.

Les sections suivantes décrivent les étapes à suivre pour dépanner chaque étape et déterminer si le trafic circule correctement ou non.

Le paquet quitte-t-il le client ?

Vérifiez si le paquet quitte correctement le client et passe par le routeur configuré dans votre infrastructure réseau physique.

  1. Utilisez tcpdump pour vérifier le paquet lorsqu'il quitte le client pour le service de destination:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Si vous ne constatez aucun trafic sortant, c'est bien la cause du problème.

Le paquet arrive-t-il sur un nœud LoadBalancer ?

Si vous utilisez MetalLB comme équilibreur de charge:

  1. Consultez le journal metallb-controller pour déterminer quel nœud d'équilibreur de charge diffuse l'adresse IP virtuelle de service:

    kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP

  2. Connectez-vous au nœud à l'aide de SSH.

  3. Pour un nœud MetalLB, utilisez tcpdump pour examiner le trafic:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Pour ManualLB, le trafic peut arriver sur n'importe quel nœud. Selon la configuration de l'équilibreur de charge, vous pouvez choisir un ou plusieurs nœuds. Utilisez tcpdump pour examiner le trafic:

    tcpdump -ni any host NODE_IP and port NODE_PORT

    La commande diffère selon les types d'équilibreurs de charge, car MetalLB n'utilise pas le NAT avant le transfert du paquet aux nœuds.

    Si aucun trafic n'entre dans un nœud, il s'agit de la source du problème.

Y a-t-il un problème avec F5 BIG-IP ?

Pour résoudre les problèmes liés à F5 BIG-IP, consultez l'une des sections suivantes sur Le service F5 ne reçoit pas de trafic.

L'ARP est-il correctement envoyé ?

Le nœud d'équilibreur de charge de MetalLB s'appuie sur l'ARP pour annoncer l'adresse IP virtuelle du service. Si la réponse ARP est correctement envoyée, mais que le trafic n'arrive pas, c'est un signal de problème dans votre infrastructure de mise en réseau physique. Une cause fréquente de ce problème est que certaines fonctionnalités avancées d'apprentissage en plan de données ignorent la réponse ARP dans les solutions de réseau défini par logiciel (SDN).

  1. Utilisez tcpdump pour détecter les réponses ARP:

    tcpdump -ni any arp

    Essayez de trouver le message qui fait la promotion de l'adresse IP virtuelle avec laquelle vous rencontrez des problèmes.

  2. Pour MetalLB, il n'envoie pas d'ARP gratuit. La fréquence à laquelle vous voyez une réponse dépend du moment où un autre appareil, tel qu'un commutateur Top of rack (ToR), envoie une requête ARP.

La fonctionnalité NAT est-elle exécutée ?

Dataplane v2 / kube-proxy effectue la traduction de l'adresse réseau de destination (NAT ou DNAT de destination) pour traduire l'adresse IP virtuelle de destination en adresse IP de pod de backend. Si vous savez quel nœud est le backend de l'équilibreur de charge, connectez-vous au nœud à l'aide de SSH.

  1. Utilisez tcpdump pour vérifier si l'adresse IP virtuelle de service est correctement traduite:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. Pour Dataplane v2, vous pouvez également vous connecter aux pods anetd et utiliser les outils de débogage Cilium intégrés:

    cilium monitor --type=drop

Pour en savoir plus, consultez l'une des sections suivantes sur les problèmes liés à Dataplane v2 / Cilium.

Le paquet arrive-t-il sur un nœud de calcul ?

Sur les nœuds de calcul, le paquet arrive sur l'interface externe, puis est distribué aux pods.

  1. Vérifiez si le paquet arrive à l'interface externe, généralement nommée eth0 ou ens192, à l'aide de tcpdump:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
Pour Google Distributed Cloud Virtual pour Bare Metal, le paquet est encapsulé dans un tunnel. Une fois le paquet décapsulé, il provient d'une interface réseau nommée cilium_geneve.

Étant donné que les backends de services normaux contiennent plusieurs pods sur différents nœuds, il peut être difficile de déterminer quel nœud est en cause. Une solution de contournement courante consiste à capturer le problème suffisamment longtemps pour qu'un paquet finisse par arriver, ou à limiter le nombre de backends à un.

Si le paquet n'arrive jamais au nœud de travail, cela indique un problème d'infrastructure réseau. Vérifiez auprès de l'équipe chargée de l'infrastructure réseau pour savoir pourquoi le paquet est supprimé entre les nœuds LoadBalancer et les nœuds de calcul. Voici quelques problèmes courants:

  • Vérifiez les journaux de votre réseau défini par logiciel (SDN). Parfois, le SDN peut supprimer des paquets pour diverses raisons, telles que la segmentation, une somme de contrôle erronée ou l'anti-spoofing.
  • Règles de pare-feu qui filtrent les paquets générés par le port UDP 6081

Si le paquet arrive à l'interface externe du nœud ou à l'interface de tunnel, il doit être transféré au pod de destination. Si le pod est un pod de réseau hôte, cette étape n'est pas nécessaire, car le pod partage l'espace de noms réseau avec le nœud. Sinon, un transfert de paquets supplémentaire est requis.

Chaque pod possède des paires d'interfaces Ethernet virtuelles, qui fonctionnent comme des tuyaux. Un paquet envoyé à une extrémité de l'interface est reçu de l'autre extrémité de l'interface. L'une des interfaces est déplacée vers l'espace de noms réseau du pod et renommée eth0. L'autre interface est conservée dans l'espace de noms hôte. Différents CNN ont un schéma différent. Pour Dataplane v2, l'interface est normalement nommée lxcxxxx. Les noms ont des numéros d'interface consécutifs, tels que lxc17 et lxc18. Vous pouvez vérifier si le paquet arrive au pod à l'aide de tcpdump, ou vous pouvez également spécifier l'interface:

  tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Si le paquet arrive au nœud, mais ne parvient pas au pod, vérifiez la table de routage comme suit:

  ip route

Normalement, chaque pod doit avoir une entrée de routage pour acheminer l'adresse IP du pod vers l'interface lxc. Si l'entrée est manquante, cela signifie généralement que le chemin de données CNI comporte une erreur. Pour déterminer la cause du problème, consultez les journaux du DaemonSet CNI.

Problèmes de sortie

Si du trafic peut entrer dans un pod, il se peut que vous rencontriez un problème avec le trafic sortant du pod. Les schémas suivants montrent que, dans un exemple fonctionnel, le trafic entrant transite par la pile de gauche à droite:

Le trafic de sortie transite du pod via l'interface externe de l'hôte vers l'infrastructure physique, puis vers le service externe.

  1. Pour vérifier que le paquet sortant se fait correctement passer pour l'adresse IP du nœud, vérifiez le service externe (couche 4).

    L'adresse IP source du paquet doit être mappée de l'adresse IP du pod à l'adresse IP du nœud avec traduction de l'adresse réseau source (NAT ou SNAT source). Dans Dataplane v2, ce processus est réalisé par ebpf chargé sur une interface externe.

    Utilisez tcpdump pour vérifier si l'adresse IP source est correctement traduite de l'adresse IP du pod en adresse IP du nœud:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    Si tcpdump indique que les paquets sont correctement masqués, mais que le service distant ne répond pas, vérifiez la connexion au service externe dans votre infrastructure.

  2. Si les paquets sortants sont correctement masqués en tant qu'adresse IP du nœud, vérifiez la connectivité de l'hôte externe (couche 3) à l'aide de tcpdump:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    En même temps que vous exécutez tcpdump, pinguez l'un des pods:

    kubectl exec POD_NAME ping EXTERNAL_IP

    Si vous ne voyez pas de réponses ping, vérifiez la connexion au service externe dans votre infrastructure.

Problèmes au sein du cluster

Pour les problèmes de connectivité entre pods, essayez de les limiter aux nœuds. Souvent, un groupe de nœuds ne peut pas communiquer avec un autre groupe de nœuds.

  1. Dans Dataplane v2, vérifiez la connectivité des nœuds entre le nœud actuel et tous les autres nœuds du même cluster. Depuis l'intérieur du pod anetd, vérifiez l'état de fonctionnement:

    cilium status --all-health

Problèmes de couche réseau

Il est important d'identifier la couche réseau dans laquelle le problème de connectivité se produit. Un message d'erreur du type Un problème de connectivité d'une source à une destination n'est pas suffisamment informatif pour aider à résoudre le problème. Il peut s'agir d'une erreur d'application, d'un problème de routage ou d'un problème DNS. Comprendre à quelle couche le problème se produit permet de corriger le bon composant.

Souvent, les messages d'erreur indiquent directement la couche à l'origine du problème. Les exemples suivants peuvent vous aider à résoudre les problèmes liés à la couche réseau:

  • Les erreurs HTTP indiquent qu'il s'agit d'un problème de couche 7.
    • Les erreurs de handshake HTTP 40x, 50x ou TLS signifient que tout fonctionne normalement au niveau de la couche 4.
  • Le message d'erreur Connexion réinitialisée par l'homologue indique qu'il s'agit d'un problème de couche 4.
    • Souvent, le socket distant ne peut pas s'accorder avec l'état actuel d'une connexion et envoie donc un paquet RESET. Ce comportement peut être une erreur de suivi des connexions, ou NAT.
  • Les erreurs "No route to host" (Aucune route vers l'hôte) et "ConnectionTimeout" (Expiration du délai de connexion) sont généralement des problèmes de couche 3 ou de couche 2.
    • Ces erreurs indiquent que le paquet ne peut pas être correctement acheminé vers la destination.

Outils de dépannage utiles

Les DaemonSets liés au réseau s'exécutent sur vos nœuds et peuvent être à l'origine de problèmes de connectivité. Toutefois, une mauvaise configuration de vos nœuds, des commutateurs ToR (top of rack), des routeurs principaux ou des pare-feu peut également entraîner des problèmes. Vous pouvez utiliser les outils suivants pour déterminer le champ d'application ou la couche du problème et déterminer s'il est lié à vos nœuds GKE Enterprise ou à votre infrastructure physique.

Ping

La commande Ping fonctionne au niveau de la couche 3 (couche IP) et vérifie la route entre une source et une destination. Si le ping ne parvient pas à atteindre une destination, cela signifie souvent que le problème se situe au niveau de la couche 3.

Cependant, les adresses IP ne peuvent pas toutes être pinguées. Par exemple, certaines adresses IP virtuelles d'équilibreur de charge ne peuvent pas être pinguées s'il s'agit d'un équilibreur de charge de couche 4 pur. Dans le cas du service ClusterIP, l'adresse IP virtuelle peut ne pas renvoyer de réponse ping. Au niveau de la couche 4, ce service ne renvoie une réponse ping que lorsque vous spécifiez un numéro de port, tel que VIP:port.

Les équilibreurs de charge BGPLB et MetalLB de Google Distributed Cloud Virtual pour Bare Metal fonctionnent tous au niveau de la couche 3. Vous pouvez utiliser ping pour vérifier la connectivité. Bien que F5 soit différent, il est également compatible avec ICMP. Vous pouvez utiliser une commande ping pour vérifier la connectivité à l'adresse IP virtuelle F5.

Arping

La commande Arping est semblable à la commande ping, sauf qu'elle fonctionne au niveau de la couche 2. Les problèmes de couche 2 et de couche 3 présentent souvent des messages d'erreur similaires de la part des applications. Arping et ping peuvent aider à différencier le problème. Par exemple, si la source et la destination se trouvent dans le même sous-réseau, mais que vous ne pouvez pas indiquer la destination, il s'agit d'un problème de couche 2.

Une commande arping <ip> réussie renvoie l'adresse MAC de la destination. Au niveau de la couche 2, cette adresse indique souvent un problème d'infrastructure physique. Ce problème est souvent lié à un basculement physique entre les nœuds.

Arping peut également détecter les conflits d'adresses IP. Un conflit d'adresses IP se produit lorsque deux machines sont configurées pour utiliser la même adresse IP sur le même sous-réseau ou qu'une adresse IP virtuelle est utilisée par une autre machine physique. Les conflits d'adresses IP peuvent créer des problèmes intermittents difficiles à résoudre. Si arping <ip> renvoie plusieurs entrées d'adresses MAC, cela signifie qu'il y a un conflit d'adresses IP.

Une fois que vous avez obtenu l'adresse MAC à partir d'arping, vous pouvez utiliser https://maclookup.app/ pour rechercher le fabricant de l'adresse MAC. Chaque fabricant possède un préfixe MAC. Vous pouvez donc utiliser ces informations pour déterminer quel appareil essaie d'utiliser la même adresse IP. Par exemple, VMware est propriétaire du bloc 00:50:56. Une adresse MAC 00:50:56:xx:yy:zz correspond donc à une VM de votre environnement vSphere.

iproute2

La CLI ip pour iproute2 comporte de nombreuses sous-commandes utiles, par exemple:

  • ip r: imprimer la table de routage
  • ip n: afficher la table voisine pour le mappage des adresses IP et des adresses MAC.
  • ip a: afficher toutes les interfaces de la machine.

Une route ou une entrée manquante dans la table voisine peuvent entraîner des problèmes de connectivité du nœud. Anetd gère la table de routage et la table voisine. Une mauvaise configuration dans ces tables peut entraîner des problèmes de connectivité.

CLI Cilium / Hubble pour Dataplane v2

Chaque pod anetd dispose de plusieurs outils de débogage utiles pour résoudre les problèmes de connectivité:

  • cilium monitor --type=drop
    • Imprimez le journal de chaque paquet supprimé par anetd / Cilium.
  • hubble observe
    • Affichez tous les paquets passant par la pile ebpf d'anetd.
  • cilium status --all-health
    • Affichez l'état de Cilium, y compris l'état de la connectivité de nœud à nœud. Chaque pod entrant vérifie l'état de tous les autres nœuds du cluster et peut vous aider à identifier les problèmes de connectivité nœud à nœud.

Iptables

Les tables iptables sont utilisées dans de nombreux composants et sous-systèmes de Kubernetes. kube-proxy utilise iptables pour implémenter la résolution de service.

  1. Pour résoudre les problèmes de réseau au niveau des iptables, utilisez la commande suivante:

    iptables -L -v | grep DROP

    Examinez les règles de suppression, et vérifiez le nombre de paquets et d'octets pour voir s'ils augmentent au fil du temps.

tcpdump

tcpdump est un puissant outil de capture de paquets qui génère de nombreuses données de trafic réseau. Une pratique courante consiste à exécuter tcpdump à la fois à partir de la source et de la destination. Si un paquet est capturé lorsqu'il quitte le nœud source, mais n'est jamais capturé sur le nœud de destination, cela signifie qu'un élément situé entre les deux abandonne le paquet. Ce comportement indique généralement qu'un élément de votre infrastructure physique supprime par erreur le paquet.

Dépannage DNS

Les problèmes de résolution DNS appartiennent à deux catégories principales:

  • Les pods standards, qui utilisent les serveurs DNS intégrés au cluster.
  • Pods ou nœuds du réseau hôte, qui n'utilisent pas de serveurs DNS au sein du cluster

Les sections suivantes fournissent des informations sur l'architecture DNS du cluster et des conseils utiles avant de commencer à résoudre les problèmes liés à l'une de ces catégories.

Architecture DNS du cluster

Un service DNS de cluster résout les requêtes DNS pour les pods du cluster. CoreDNS fournit ce service pour toutes les versions de Google Distributed Cloud Virtual pour Bare Metal.

Chaque cluster comporte deux pods coredns ou plus, ainsi qu'un autoscaler chargé de faire évoluer le nombre de pods DNS par rapport à la taille du cluster. Il existe également un service nommé kube-dns qui équilibre la charge des requêtes entre tous les pods coredns du backend.

Le DNS en amont de la plupart des pods est configuré sur l'adresse IP du service kube-dns, et les pods envoient des requêtes DNS à l'un des pods coredns. Les requêtes DNS peuvent être regroupées dans l'une des destinations suivantes:

  • Si la requête concerne un domaine cluster.local, il s'agit d'un nom DNS interne au cluster qui fait référence à un service ou à un pod du cluster.
    • CoreDNS surveille api-server pour tous les services et pods du cluster, et répond aux requêtes pour les domaines cluster.local valides.
  • Si la requête ne concerne pas un domaine cluster.local, elle concerne un domaine externe.
    • CoreDNS transfère la requête aux serveurs de noms en amont. Par défaut, CoreDNS utilise les serveurs de noms en amont configurés sur le nœud sur lequel il s'exécute.

Pour en savoir plus, consultez la présentation du fonctionnement et de la configuration du DNS dans Kubernetes.

Conseils de dépannage DNS

Pour résoudre les problèmes DNS, vous pouvez utiliser les outils dig et nslookup. Ces outils vous permettent d'envoyer des requêtes DNS pour vérifier si la résolution DNS fonctionne correctement. Les exemples suivants vous montrent comment utiliser dig et nslookup pour rechercher des problèmes de résolution DNS.

  • Utilisez dig ou nslookup afin d'envoyer une requête pour google.com:

    dig google.com
nslookup google.com

  • Utilisez dig pour envoyer une requête pour kubernetes.default.svc.cluster.local au serveur 192.168.0.10:

    dig @192.168.0.10 kubernetes.default.svc.cluster.local

  • Vous pouvez également utiliser nslookup pour effectuer la même résolution DNS que la commande dig précédente:

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    Examinez le résultat des commandes dig ou nslookup. Si vous recevez une réponse incorrecte ou aucune réponse, cela indique un problème de résolution DNS.

Pods standards

La première étape pour déboguer un problème DNS consiste à déterminer si les requêtes parviennent aux pods coredns ou non. Souvent, un problème général de connectivité de cluster apparaît sous la forme de problèmes DNS, car une requête DNS est le premier type de trafic envoyé par une charge de travail.

Examinez les messages d'erreur de vos applications. Des erreurs telles que io timeout ou des erreurs similaires indiquent qu'il n'y a pas de réponse et qu'il s'agit d'un problème général de connectivité réseau.

Les messages d'erreur qui incluent un code d'erreur DNS tel que NXDOMAIN ou SERVFAIL indiquent qu'il existe une connectivité au serveur DNS du cluster, mais que celui-ci n'a pas réussi à résoudre le nom de domaine:

  • Les erreurs NXDOMAIN indiquent que le serveur DNS signale que le domaine n'existe pas. Vérifiez que le nom de domaine demandé par votre application est valide.
  • Les erreurs SERVFAIL ou REFUSED indiquent que le serveur DNS a renvoyé une réponse, mais qu'il n'a pas pu résoudre le domaine ni confirmer qu'il n'existe pas. Pour en savoir plus, consultez les journaux des pods coredns.

Vous pouvez trouver l'adresse IP du service kube-dns à l'aide de la commande suivante:

kubectl -n kube-system get svc kube-dns

À partir d'un pod dans lequel le DNS ne fonctionne pas, essayez d'envoyer une requête DNS à cette adresse IP à l'aide de dig ou nslookup, comme indiqué dans une section précédente:

  • Si ces requêtes ne fonctionnent pas, essayez d'envoyer des requêtes à l'adresse IP de chaque pod coredns.
  • Si certains pods fonctionnent, mais pas d'autres, vérifiez s'il existe des modèles identifiables, tels que la résolution DNS pour les pods situés sur le même nœud que le pod coredns, mais pas sur plusieurs nœuds. Ce comportement peut indiquer un problème de connectivité au sein du cluster.

Si CoreDNS ne parvient pas à résoudre les noms de domaine externes, consultez la section suivante pour résoudre les problèmes liés aux pods du réseau hôte. CoreDNS se comporte comme un pod de réseau hôte et utilise les serveurs DNS en amont du nœud pour la résolution des noms.

Pods ou nœuds du réseau hôte

Les pods du réseau hôte et les nœuds utilisent les serveurs de noms configurés sur le nœud pour la résolution DNS, et non le service DNS du cluster. Selon l'OS, ce serveur de noms est configuré dans /etc/resolv.conf ou /run/systemd/resolve/resolv.conf. Cette configuration signifie qu'ils ne peuvent pas résoudre les noms de domaine cluster.local.

Si vous rencontrez des problèmes avec la résolution des noms du réseau hôte, suivez les étapes de dépannage des sections précédentes pour vérifier si le DNS fonctionne correctement pour vos serveurs de noms en amont.

Vérifiez que tous les nœuds ont le même ensemble de serveurs configurés. Si différents serveurs de noms sont configurés, vous pouvez constater des incohérences dans la résolution DNS sur différents nœuds. Vérifiez que chaque serveur de noms fonctionne individuellement en envoyant une requête à chacun d'eux à l'aide de dig ou nslookup. Si certains serveurs de noms fonctionnent, mais que d'autres ne fonctionnent pas, vous constatez ce type d'échecs de résolution DNS incohérents.

Problèmes de réseau courants

Les sections suivantes détaillent certains problèmes de mise en réseau courants que vous pourriez rencontrer. Pour vous aider à résoudre votre problème, suivez les conseils de dépannage appropriés. Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Dataplane v2 / Cilium

Erreur courante:[PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

Cette erreur signifie que l'événement de création du pod a été rejeté par l'agent Cilium en raison d'une limite de débit. Pour chaque nœud, Cilium impose une limite de quatre requêtes simultanées au point de terminaison PUT. Ce comportement est normal en cas de rafales de requêtes adressées à un nœud. L'agent Cilium doit rattraper les requêtes retardées.

Dans GKE Enterprise 1.14 et versions ultérieures, la limite de débit s'ajuste automatiquement en fonction de la capacité des nœuds. Le limiteur de débit peut converger vers un nombre plus raisonnable, avec des limites de débit plus élevées pour des nœuds plus puissants.

Erreur courante:Ebpf map size is full

Dataplane v2 stocke l'état dans une carte eBFP. L'état inclut les règles de service, de suivi des connexions, d'identité de pod et de règles de réseau. Si une carte est pleine, l'agent ne peut pas insérer d'entrées, ce qui crée un écart entre le plan de contrôle et le plan de données. Par exemple, le mappage de service comporte une limite d'entrées de 64 000.

  1. Pour vérifier les entrées de mappage eBFP et leur taille actuelle, utilisez bpftool. L'exemple suivant vérifie les mappages de l'équilibreur de charge:

    bpftool map dump pinned \
/sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1

bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1

  2. Si la carte approche de la limite de 64 000, nettoyez-la. L'exemple suivant nettoie les mappages de l'équilibreur de charge:

    bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key

  3. Pour renseigner l'état dans la carte eBFP, redémarrez anetd.

Nœud non prêt en raison d'erreurs NetworkPluginNotReady

Si le pod CNI ne s'exécute pas sur le nœud, une erreur semblable à celle-ci peut s'afficher:

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Le nœud peut également être dans un état non prêt, avec une erreur semblable à l'exemple suivant:

  "Network plugin not installed"

Lorsqu'un nœud est initialisé, kubelet attend que plusieurs événements se produisent avant de le marquer comme Ready. L'un des événements vérifiés par kubelet est que le plug-in CNI (Container Network Interface) est installé. Le plug-in CNI doit être installé par anetd à l'aide d'un conteneur init pour installer à la fois le binaire CNI et la configuration CNI dans les répertoires hôtes requis.

Pour résoudre ce problème, vérifiez pourquoi ces pods ne s'exécutent pas sur le nœud. En général, l'erreur n'est pas due à des problèmes de réseau. Ces pods s'exécutent sur le réseau hôte, il n'y a donc aucune dépendance réseau.

  1. Vérifiez l'état du pod anetd. Consultez les étapes de dépannage suivantes pour déterminer la cause du problème:

    • Si le pod est à l'état Crashlooping, consultez les journaux pour savoir pourquoi il ne peut pas s'exécuter correctement.
    • Si le pod est à l'état Pending, utilisez kubectl describe et examinez les événements du pod. Par exemple, il peut manquer une ressource telle qu'un volume au pod.
    • Si le pod est à l'état Running, vérifiez les journaux et la configuration. Certaines implémentations CNI fournissent des options permettant de désactiver l'installation de CNI, comme dans Cilium.
    • Il existe une option de configuration dans Anetd appelée custom-cni-conf. Si ce paramètre est configuré en tant que true, anetd n'installera pas son binaire CNI.

Le service F5 ne reçoit pas de trafic

Si aucun trafic n'est transmis au service F5, consultez les étapes de dépannage suivantes:

  1. Vérifiez que chaque partition dans F5 BIG-IP est configurée dans un cluster, qu'il s'agisse de clusters d'administrateur ou d'utilisateur. Si une partition est partagée par plusieurs clusters différents, la connexion se produit par intermittence. Ce comportement est dû au fait que deux clusters tentent de prendre le contrôle de la même partition et suppriment les services d'autres clusters.

  2. Vérifiez que les deux pods suivants sont en cours d'exécution. Tous les pods non en cours d'exécution indiquent une erreur:

    Load-balancer-f5
K8s-bigip-ctlr-deployment-577d57985d-vk9wj

    Le Load-balancer-f5, appartenant à GKE Enterprise, crée des ConfigMaps pour chaque service de type LoadBalancer. Le ConfigMap est à terme consommé par le contrôleur bigip.

  3. Assurez-vous que le ConfigMap existe pour chaque port de chaque service. Par exemple, avec les ports suivants:

    Kube-server-443-tcp     2   31h
Kube-server-8132-tcp        2   31h

    Le service kube-server doit ressembler à l'exemple suivant:

    Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h

    La section de données du ConfigMap doit comporter l'adresse IP virtuelle et le port d'interface, comme illustré dans l'exemple suivant:

    data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
  schema: f5schemadb://bigip-virtual-server_v0.1.7.json

  4. Vérifiez les journaux et les métriques de votre instance BIG-IP. Si le ConfigMap est correctement configuré, mais que l'instance BIG-IP ne respecte pas la configuration, il peut s'agir d'un problème F5. En cas de problème survenant dans l'instance BIG-IP, contactez l'assistance F5 pour les diagnostiquer et les résoudre.

Échec NAT avec trop de connexions parallèles

Pour un nœud donné de votre cluster, l'adresse IP du nœud fournit une traduction d'adresse réseau (NAT) pour les paquets acheminés vers une adresse en dehors du cluster. De même, lorsque les paquets entrants entrent dans un nœud d'équilibrage de charge configuré pour utiliser l'équilibrage de charge groupé (spec.loadBalancer.mode: bundled), la traduction d'adresse réseau source (SNAT) achemine les paquets vers l'adresse IP du nœud avant qu'ils ne soient transférés vers un pod backend.

La plage de ports pour la NAT utilisée par GDCV pour Bare Metal est 32768-65535. Cette plage limite le nombre de connexions parallèles à 32 767 par protocole sur ce nœud. Chaque connexion nécessite une entrée dans la table conntrack. Si vous avez trop de connexions de courte durée, la table conntrack n'a plus de ports pour la NAT. Un récupérateur de mémoire nettoie les entrées obsolètes, mais le nettoyage n'est pas immédiat.

Lorsque le nombre de connexions sur votre nœud approche de 32 767, vous commencez à voir des pertes de paquets pour les connexions nécessitant la NAT.

Pour déterminer si vous êtes concerné par ce problème:

  1. Exécutez la commande suivante sur le pod anetd sur le nœud problématique:

    kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

    Les erreurs doivent s'afficher sous la forme suivante :

    No mapping for NAT masquerade DROPPED

Pour contourner ce problème, redistribuez le trafic vers d'autres nœuds.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.