Résoudre les problèmes de mise en réseau du Cloud distribué de Google

Cette page explique comment résoudre les problèmes de réseau avec Google Distributed Cloud. Des informations et des conseils généraux de dépannage sont fournis, ainsi que des outils suggérés. Des informations sur le dépannage DNS et certains problèmes courants liés à MetalLB sont également inclus.

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

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

Déterminez d'abord l'ampleur du problème, puis essayez d'identifier les composants concernés. Le champ d'application d'un problème peut relever d'une catégorie parmi trois : l'objet (d'où), la cible (vers quoi) et la couche réseau.

Le champ d'application du sujet peut être l'un des 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 sur un ensemble de nœuds.
  • Tous les pods du même déploiement ou DaemonSet.
  • Client en dehors du cluster.

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

  • Toutes les autres adresses IP de pod du même cluster.
  • Toutes les autres adresses IP de pod 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.
  • Équilibreur de charge 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 (comme google.com).
  • Entités externes au cluster.
  • Entités sur Internet.

La couche réseau peut correspondre à un ou plusieurs des éléments suivants:

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

Comprendre l'ampleur d'un problème permet d'identifier les composants concernés et la couche à laquelle il se produit. Il est important de collecter des informations lorsque le problème se produit, car certains problèmes sont temporaires. Les instantanés pris après la récupération du système ne contiennent donc pas suffisamment d'informations pour l'analyse de la cause première.

Problèmes d&#Ingress

Si l'objet est un client extérieur au cluster et qu'il n'a pas pu 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 traverse la pile de gauche à droite, et le trafic de retour traverse la pile de droite à gauche.

Le trafic entrant passe de l'utilisateur à l'infrastructure physique, via un équilibreur de charge, à 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 :

Corrigez les problèmes d'entrée réseau en examinant chaque étape par laquelle un paquet circule dans votre environnement. Vérifiez si les actions et la connectivité appropriées existent tout au long du trajet.

Dans cet organigramme, les conseils de dépannage suivants vous aident à 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 oui, le paquet arrive-t-il au nœud LB et l'ARP est-il ensuite envoyé correctement ? Si ce n'est pas le cas, vous avez probablement un problème d'infrastructure réseau.
  • Utilisez-vous F5 BIG-IP ? Si oui, avez-vous vérifié s'il y avait des problèmes F5 ?
  • La traduction d'adresse réseau (NAT) est-elle effectuée correctement ? Si ce n'est pas le cas, vous rencontrez probablement un problème lié à 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 entre pods Dataplane v2.
  • Le paquet arrive-t-il au niveau du pod ? Si ce n'est pas le cas, vous rencontrez probablement un problème de transfert local Dataplane v2.

Les sections suivantes fournissent des étapes de dépannage pour chaque étape afin de 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 transite 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 voyez aucun trafic sortant, c'est la source du problème.

Le paquet arrive-t-il à 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 dessert l'adresse IP virtuelle du 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. En fonction de 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'équilibreur de charge, car MetalLB n'effectue pas de NAT avant de transférer le paquet aux nœuds.

    Si vous ne voyez aucun trafic entrant dans un nœud, c'est 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 F5 Service ne reçoit pas de trafic.

L'ARP est-il envoyé correctement ?

Le nœud d'équilibrage de charge pour MetalLB s'appuie sur ARP pour annoncer l'adresse IP virtuelle du service. Si la réponse ARP est correctement envoyée, mais que le trafic n'entre pas, cela indique un problème dans votre infrastructure de mise en réseau physique. Ce problème est souvent dû au fait que certaines fonctionnalités d'apprentissage avancées du 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 du VIP avec lequel vous rencontrez des problèmes.

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

Le NAT est-il effectué ?

Dataplane v2/kube-proxy effectue une traduction d'adresse réseau de destination (NAT de destination ou DNAT) 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 le VIP du service est correctement traduit :

    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, le paquet est encapsulé dans un tunnel. Lorsque le paquet est décapsulé, il sort d'une interface réseau nommée cilium_geneve.

Étant donné que les backends de service normaux contiennent plusieurs pods sur différents nœuds, il peut être difficile de déterminer quel nœud est en cause. Une solution 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 calcul, cela indique un problème d'infrastructure réseau. Consultez l'équipe chargée de l'infrastructure de mise en 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 vos journaux de réseau défini par logiciel (SDN). Il arrive que le SDN supprime des paquets pour diverses raisons, comme la segmentation, une somme de contrôle incorrecte ou l'anti-spoofing.
  • Règles de pare-feu qui filtrent les paquets Geneve sur le port UDP 6081.

Si le paquet arrive à l'interface externe ou à l'interface de tunnel du nœud, il doit être transféré au pod de destination. Si le pod est un pod de mise en 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 nécessaire.

Chaque pod dispose de paires d'interfaces Ethernet virtuelles, qui fonctionnent comme des canaux. Un paquet envoyé à une extrémité de l'interface est reçu à 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 de l'hôte. Différentes CNI ont des schémas différents. Pour Dataplane V2, l'interface est normalement nommée lxcxxxx. Les noms comportent des numéros d'interface consécutifs, comme 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 pas au pod, vérifiez la table de routage comme suit :

ip route

Normalement, chaque pod doit disposer d'une entrée de routage qui route 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 première, vérifiez les journaux CNI DaemonSet.

Problèmes de sortie

Si le trafic peut entrer dans un pod, vous pouvez rencontrer un problème de trafic lorsqu'il sort du pod. Les schémas suivants montrent que dans un exemple fonctionnel, le trafic entrant traverse la pile de gauche à droite :

Le trafic de sortie passe du pod à l'interface externe de l'hôte, à l'infrastructure physique, puis au service externe.

  1. Pour vérifier que le paquet sortant est correctement masquée comme 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 vers l'adresse IP du nœud avec la traduction d'adresse réseau source (NAT source ou SNAT). 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 à l'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 comme 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 l'exécution de tcpdump, effectuez un ping à partir de 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 dans le cluster

En cas de problème de connectivité entre pods, essayez de limiter le problème 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 du nœud actuel à tous les autres nœuds du même cluster. Depuis le pod anetd, vérifiez l'état :

    cilium status --all-health

Problèmes liés à la 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 tel que "Un problème de connectivité d'une source vers une destination" n'est pas suffisamment informatif pour aider à résoudre le problème, qui peut être une erreur d'application, un problème de routage ou de DNS. Comprendre à quel niveau le problème se produit permet de corriger le bon composant.

Souvent, les messages d'erreur indiquent directement la couche concernée par le problème. Les exemples suivants peuvent vous aider à résoudre les questions concernant la couche réseau :

  • Les erreurs HTTP indiquent qu'il s'agit d'un problème de couche 7.
    • Les codes HTTP 40x, 50x ou les erreurs de handshake TLS signifient que tout fonctionne normalement au niveau de la couche 4.
  • Les erreurs "Connexion réinitialisée par l'homologue" indiquent 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 dû à une erreur dans le suivi des connexions ou dans NAT.
  • Les erreurs Aucune route vers l'hôte et Délai de connexion expiré sont généralement liées à un problème de couche 3 ou 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, commutateurs en haut du rack (ToR), routeurs de dorsale ou 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 s'agit d'un problème 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 3.

Toutefois, toutes les adresses IP ne sont pas pingables. 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. Le service ClusterIP est un exemple où le VIP peut ne pas renvoyer de réponse ping. Au niveau 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 fonctionnent tous au niveau de la couche 3. Vous pouvez utiliser la commande ping pour vérifier la connectivité. Bien que F5 soit différent, il est également compatible avec ICMP. Vous pouvez utiliser ping pour vérifier la connectivité à l'adresse IP virtuelle F5.

Recherche ARP

La recherche ARP est semblable au ping, sauf qu'elle fonctionne au niveau de la couche 2. Les problèmes de couche 2 et de couche 3 génèrent souvent des messages d'erreur similaires dans les applications. La recherche ARP 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 effectuer une recherche ARP sur la destination, il s'agit d'un problème de couche 2.

Si la commande arping <ip> réussit, l'adresse MAC de la destination est renvoyée. Au niveau 2, cette adresse indique souvent un problème d'infrastructure physique. Ce problème est souvent lié à un commutateur physique entre les nœuds.

La recherche ARP 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 lorsqu'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'adresse MAC, cela indique qu'il existe un conflit d'adresses IP.

Après avoir obtenu l'adresse MAC via la recherche ARP, 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 tente d'utiliser la même adresse IP. Par exemple, VMware possède le bloc 00:50:56. Par conséquent, une adresse MAC 00:50:56:xx:yy:zz est une VM dans votre environnement vSphere.

iproute2

La CLI ip pour iproute2 comporte de nombreuses sous-commandes utiles, telles que les suivantes :

  • ip r : imprime la table de routage.
  • ip n : affiche le tableau des voisins pour le mappage de l'adresse IP à l'adresse MAC.
  • ip a : imprime toutes les interfaces de la machine.

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

Cilium/CLI Hubble pour Dataplane v2

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

  • cilium monitor --type=drop
    • Imprimez le journal de chaque paquet abandonné par anetd/Cilium.
  • hubble observe
    • Imprimez tous les paquets qui transitent 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 anetd vérifie l'état de tous les autres nœuds du cluster et peut aider à identifier les problèmes de connectivité entre les nœuds.

Iptables

Les iptables sont utilisés dans de nombreux composants et sous-systèmes Kubernetes. kube-proxy utilise des iptables pour mettre en œuvre 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, puis vérifiez si le nombre de paquets et d'octets augmente au fil du temps.

Tcpdump

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

Métriques

Google Distributed Cloud contient plusieurs métriques pour vous aider à suivre le comportement de votre réseau. Les métriques suivantes constituent un bon point de départ :

Catégorie Métrique Description
Paquets supprimés cilium_drop_bytes_total Nombre total d'octets supprimés, avec le motif de suppression et la direction d'entrée/sortie. Cette métrique est un bon point de départ pour examiner les pertes au niveau des octets.
cilium_drop_count_total Nombre total de paquets supprimés, tagués par motif de suppression et par sens d'entrée/sortie.
container_network_receive_packets_dropped_total Nombre cumulé de paquets perdus lors de la réception. Échantillonnage toutes les 60 secondes.
container_network_transmit_packets_dropped_total Nombre cumulé de paquets perdus lors de la transmission. Échantillonnage toutes les 60 secondes.
Paquets transférés cilium_forward_bytes_total Nombre total d'octets transférés, tagués par direction d'entrée/de sortie. Échantillonné toutes les 60 secondes. Cette métrique fournit des informations sur le transfert au niveau des octets.
cilium_forward_count_total Nombre total de paquets transférés, tagués par direction d'entrée/sortie. Échantillonné toutes les 60 secondes. Cette métrique indique le nombre de paquets pour le trafic transféré.
cilium_policy_l7_forwarded_total Nombre total de requêtes transférées de niveau 7.
Paquets reçus cilium_policy_l7_received_total Nombre total de requêtes/réponses de couche 7 reçues. Échantillonnage toutes les 60 secondes.
container_network_receive_bytes_total Nombre cumulé d'octets reçus. Échantillonné toutes les 60 secondes.
container_network_receive_packets_total Nombre cumulé de paquets reçus. Échantillonné toutes les 60 secondes.
container_network_receive_errors_total Nombre cumulé d'erreurs rencontrées lors de la réception. Échantillonnage toutes les 60 secondes.
cilium_kubernetes_events_received_total Nombre d'événements Kubernetes reçus, libellés par portée, action, données valides et égalité. Échantillonné toutes les 60 secondes.
BPF cilium_bpf_maps_virtual_memory_max_bytes Taille maximale de la mémoire du noyau utilisée par les cartes BPF, en octets.
cilium_bpf_progs_virtual_memory_max_bytes Taille maximale de la mémoire du noyau utilisée par les programmes BPF, en octets.
Conntrack node_nf_conntrack_entries Nombre d'entrées de flux actuellement allouées pour le suivi des connexions. Échantillonné toutes les 60 secondes.
node_nf_conntrack_entries_limit Taille maximale de la table de suivi des connexions. Échantillonné toutes les 60 secondes.
Connectivité cilium_node_connectivity_latency_seconds Latence observée la dernière fois entre l'agent Cilium actuel et les autres nœuds Cilium, en secondes. Échantillonné toutes les 60 secondes.
cilium_node_connectivity_status Dernier état observé de la connectivité ICMP et HTTP entre l'agent Cilium actuel et les autres nœuds Cilium. Échantillonné toutes les 60 secondes.
Opérateurs Cilium cilium_operator_process_cpu_seconds_total Temps CPU utilisateur et système total en secondes. Échantillonnage toutes les 60 secondes.
cilium_operator_process_max_fds Nombre maximal de descripteurs de fichiers ouverts. Échantillonné toutes les 60 secondes.
cilium_operator_process_open_fds Nombre de descripteurs de fichiers ouverts. Échantillonné toutes les 60 secondes.
cilium_operator_process_resident_memory_bytes Taille de la mémoire résidente en octets. Échantillonné toutes les 60 secondes.
cilium_operator_process_start_time_seconds Heure de début du processus depuis l'epoch Unix, en secondes. Échantillonnage toutes les 60 secondes.
cilium_operator_process_virtual_memory_bytes Taille de la mémoire virtuelle en octets. Échantillonné toutes les 60 secondes.
cilium_operator_process_virtual_memory_max_bytes Quantité maximale de mémoire virtuelle disponible en octets. Échantillonnage toutes les 60 secondes.
cilium_operator_identity_gc_entries Nombre d'identités actives et supprimées à la fin d'une exécution du collecteur de déchets. Échantillonné toutes les 60 secondes.
cilium_operator_identity_gc_runs Nombre de fois où le récupérateur de mémoire d'identité a été exécuté. Échantillonnage toutes les 60 secondes.

Pour recevoir des notifications lorsque l'une de ces métriques dépasse ou est inférieure à un certain seuil, créez des règles d'alerte. Pour en savoir plus, consultez Créer des règles d'alerte.

Pour en savoir plus sur ces métriques et consulter la liste complète, consultez Métriques Google Distributed Cloud.

Dépannage de DNS

Les problèmes de résolution DNS se répartissent en deux catégories principales :

  • les pods standards, qui utilisent les serveurs DNS du cluster ;
  • Pods ou nœuds du réseau hôte, qui n'utilisent pas les serveurs DNS 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.

Chaque cluster comporte au moins deux pods coredns et un autoscaler chargé de faire évoluer le nombre de pods DNS en fonction de la taille du cluster. Il existe également un service nommé kube-dns qui équilibre la charge des requêtes entre tous les pods coredns de backend.

La plupart des pods ont leur DNS en amont 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 dans le 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 au ou 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 montrent comment utiliser dig et nslookup pour vérifier s'il existe des problèmes de résolution DNS.

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

    dig google.com
nslookup google.com

  • Utilisez dig pour envoyer une requête 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 réguliers

La première étape pour déboguer un problème DNS consiste à déterminer si les requêtes sont transmises aux pods coredns ou non. Un problème de connectivité de cluster général se présente souvent sous la forme d'un problème DNS, car une requête DNS est le premier type de trafic qu'une charge de travail envoie.

Examinez les messages d'erreur de vos applications. Les erreurs telles que io timeout ou similaires indiquent qu'il n'y a pas de réponse et qu'il existe 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 le serveur 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 valider son inexistence. 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 où 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 schémas discernables, par exemple si la résolution DNS fonctionne pour les pods sur le même nœud que le pod coredns, mais pas sur les nœuds. Ce comportement peut indiquer un problème de connectivité dans le 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 host-network. 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 de noms.

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

Les pods et les nœuds du réseau hôte 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 de résolution de noms dans le réseau hôte, suivez les étapes de dépannage des sections précédentes pour tester 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 vous avez configuré différents serveurs de noms, 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 pas d'autres, vous verrez ce type d'échecs de résolution DNS incohérents.

Problèmes réseau courants

Les sections suivantes décrivent certains problèmes de réseau courants que vous pouvez rencontrer. Pour résoudre votre problème, suivez les instructions de dépannage appropriées. Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.

Dataplane v2 / Cilium

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

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

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

Erreur courante : Ebpf map size is full

Dataplane v2 stocke l'état dans une carte eBPF. L'état inclut le service, le suivi des connexions, l'identité du pod et les règles de stratégie réseau. Si une carte est pleine, l'agent ne peut pas insérer d'entrées, ce qui crée une différence entre le plan de contrôle et le plan de données. Par exemple, la carte de service est limitée à 64 000 entrées.

  1. Pour vérifier les entrées de la carte 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 remplir l'état dans la carte eBFP, redémarrez anetd.

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

Si le pod CNI n'est pas en cours d'exécution sur le nœud, un message d'erreur semblable à celui-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 l'installation du plug-in CNI (Container Network Interface). Le plug-in CNI doit être installé par anetd à l'aide d'un conteneur d'initialisation pour installer 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. Pour déterminer la cause du problème, suivez les étapes de dépannage ci-dessous :

    • 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 au pod, comme un volume.
    • Si le pod est à l'état Running, vérifiez les journaux et la configuration. Certaines implémentations CNI offrent 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é sur true, anetd n'installera pas son binaire CNI.

Nœud NON PRÊT en raison d'entrées ARP obsolètes

Parfois, des entrées ARP obsolètes dans les nœuds du plan de contrôle du cluster d'administrateur peuvent entraîner une incohérence dans les adresses MAC. Ce problème d'adresse peut entraîner des délais avant expiration de la connexion aux adresses IP virtuelles du plan de contrôle des clusters d'utilisateurs gérés. Les délais d'expiration de la connexion peuvent entraîner le marquage du nœud avec des entrées ARP obsolètes comme NOT READY. Les nœuds marqués comme NOT READY peuvent bloquer les installations et les mises à niveau de clusters.

Dans ce cas, le journal kubelet du nœud contenant des entrées ARP obsolètes contient une erreur de type délai d'expiration de la session TLS handshake, comme celle-ci :

failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout

Pour vérifier et résoudre le problème, procédez comme suit :

  1. Utilisez SSH pour vous connecter au nœud du plan de contrôle du cluster d'utilisateur.

  2. Vérifiez l'adresse MAC de l'interface à laquelle l'adresse IP virtuelle est liée :

    ip a | grep DEVICE_NAME: -A 6

    Remplacez DEVICE_NAME par le nom de l'interface réseau du nœud du plan de contrôle.

  3. Utilisez SSH pour vous connecter à un nœud du plan de contrôle du cluster d'administrateur.

  4. Vérifiez le cache ARP sur le plan de contrôle du cluster d'administrateur pour l'adresse IP virtuelle du plan de contrôle du cluster d'utilisateur :

    ip n | grep VIP_ADDRESS

    Remplacez VIP_ADDRESS par l'adresse IP de l'adresse IP virtuelle du plan de contrôle du cluster d'utilisateur (controlPlaneVIP).

    Si les deux commandes ip renvoient une adresse MAC différente, vous êtes concerné par ce problème.

  5. Pour résoudre le problème, videz le cache ARP sur le nœud de plan de contrôle du cluster d'administrateur :

    ip n flush all

Le service F5 ne reçoit pas de trafic

Si aucun trafic n'est transmis au service F5, suivez les étapes de dépannage ci-dessous :

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

  2. Vérifiez que les deux pods suivants sont en cours d'exécution. Tout pod qui n'est pas en cours d'exécution indique une erreur :

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

    Le Load-balancer-f5 appartient à GKE Enterprise et crée des ConfigMaps pour chaque service de type LoadBalancer. Le ConfigMap est finalement 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 contenir le VIP 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. Pour les problèmes qui se produisent dans l'instance BIG-IP, contactez l'assistance F5 pour diagnostiquer et résoudre les problèmes.

É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 NAT utilisée par Google Distributed Cloud 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 manque 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 32 767, vous commencez à voir des suppressions de paquets pour les connexions nécessitant la NAT.

Pour savoir 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 votre trafic vers d'autres nœuds.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care. Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris les suivantes :

  • Conditions requises pour ouvrir une demande d'assistance.
  • Des outils pour vous aider à résoudre les problèmes, comme la configuration de votre environnement, les journaux et les métriques.
  • Composants acceptés.