Résoudre les problèmes d'observabilité du réseau GKE

Autopilot Standard

Ce document fournit des instructions et des procédures de diagnostic pour identifier les problèmes de mise en réseau dans les clusters Google Kubernetes Engine (GKE) à l'aide de l'observabilité GKE Dataplane V2, de Hubble et de Cloud Monitoring.

Pour obtenir une présentation de l'architecture et des bonnes pratiques conceptuelles, consultez Bonnes pratiques pour l'observabilité du réseau.

Arbre de décision pour le dépannage et concepts fondamentaux

Avant de passer en revue les procédures, utilisez la matrice de décision suivante pour identifier le niveau de la pile réseau GKE qui est susceptible de causer votre problème, puis accédez à la section correspondante.

Symptôme ou question de diagnostic	Niveau suspecté	Procédure recommandée
Les pods ne parviennent pas à résoudre les domaines externes ou les services Kubernetes internes (délais d'expiration DNS, NXDOMAIN, SERVFAIL).	Niveau 1 : Pod et Service (DNS)	Diagnostiquer les échecs de résolution DNS
Les services ne peuvent pas communiquer ; des délais avant expiration de la connexion ou des pertes de paquets entre les pods se produisent.	Niveau 1 : pod et service (abandons de règles ou de paquets)	Diagnostiquer les pertes de paquets et les blocages de NetworkPolicy
Les instances répliquées de la charge de travail ont une charge de trafic inégale, ou les pods enregistrent des taux élevés de réinitialisations TCP (RST).	Niveau 1 : pod et service (équilibrage de charge ou transport)	Diagnostiquer un déséquilibre du trafic et des réinitialisations TCP
Latence générale, délais d'expiration intermittents ou redémarrages de CNI sur les nœuds.	Niveau 2 : Nœud et CNI (noyau)	Triage de la latence au niveau du nœud et des goulots d'étranglement CNI
Les pods ne peuvent pas accéder aux ressources en dehors de GKE (Cloud SQL, API externes ou autres VPC).	Niveau 3 : VPC et routage	Isoler les problèmes de connectivité GKE par rapport aux problèmes de connectivité VPC ou externe
Vous avez besoin d'une simulation de chemin automatisée pour vérifier si les règles de pare-feu, les routes ou les NetworkPolicies bloquent le trafic.	Niveau 3 : VPC et routage (simulation)	Diagnostiquer la connectivité à l'aide de Tests de connectivité
Vous devez identifier les charges de travail qui envoient du trafic vers Internet et qui sont soumises à la NAT.	Niveau 4 : Passerelle externe et coût	Identifier le trafic NAT (sortie vers Internet)
Coûts élevés de transfert de données interzones ou besoin de visualiser les principaux émetteurs sans écrire de requêtes SQL.	Niveau 4 : Passerelle externe et coût	Analyser les coûts et les performances du trafic du cluster à l'aide de Flow Analyzer

Concepts fondamentaux de la mise en réseau

Si vous débutez avec Kubernetes ou la mise en réseau Google Cloud , gardez à l'esprit les concepts de base suivants :

• eBPF (Extended Berkeley Packet Filter) : technologie de système d'exploitation qui permet d'exécuter des programmes de surveillance et de routage sécurisés directement dans le noyau Linux. GKE Dataplane V2 utilise eBPF pour acheminer les paquets et appliquer les NetworkPolicies avec une surcharge de performances minimale.
• IP masquerading (SNAT) : processus de réécriture de l'adresse IP source d'un paquet. Lorsqu'un pod GKE (qui possède une adresse IP privée) communique avec Internet ou des ressources VPC externes, GKE masque (réécrit) l'adresse IP du pod en adresse IP du nœud afin que les systèmes externes sachent comment acheminer la réponse.
• Suivi des connexions (Conntrack) : fonctionnalité du noyau qui suit toutes les connexions réseau actives. Dans les clusters GKE Dataplane V2, ce suivi est réparti entre deux tables : la table conntrack standard du noyau Linux (utilisée par ip-masq-agent) et une table conntrack gérée par Cilium et GKE Dataplane V2, stockée dans une carte eBPF. Si un nœud gère trop de connexions simultanées, l'une de ces tables de suivi peut se remplir (épuisement de conntrack), ce qui entraîne la suppression silencieuse des nouveaux paquets par le nœud.
• Hubble : moteur d'observabilité pour GKE Dataplane V2. Il s'exécute sur eBPF et offre une visibilité en temps réel sur les flux de trafic, les pertes de paquets et l'évaluation des NetworkPolicies.

Niveau 1 : Observabilité des pods et des services (application)

Le niveau Pod et Service couvre la communication réseau entre les pods, les services et le DNS du cluster. Les problèmes à ce niveau se manifestent généralement par des délais avant expiration de la connexion de l'application, des échecs de résolution de noms ou une répartition inégale de la charge.

Diagnostiquer les échecs de résolution DNS

Avant de résoudre les problèmes DNS, examinez le champ d'application du diagnostic et les conditions préalables :

• Domaine d'intérêt : communication entre les pods et CoreDNS ou NodeLocal DNSCache, latence DNS, délais avant expiration de la résolution DNS en amont et validation de la règle de réseau FQDN.
• Prérequis : métriques GKE Dataplane V2 activées ; accès à kubectl.
• Compatibilité CNI : GKE Dataplane V2 (Advanced Datapath) et GKE CNI standard.
• Symptôme : les pods enregistrent dial tcp: lookup <domain>: i/o timeout, NXDOMAIN ou une latence intermittente sur les appels d'API sortants.
• Objectif : déterminer si l'échec DNS provient de l'intérieur du cluster (saturation de kube-dns ou de NodeLocal DNSCache), d'une NetworkPolicy bloquant le port UDP ou TCP 53, ou d'une dégradation du réseau en amont.

Étape 1 : Vérification de base de l'accessibilité

Avant de résoudre les problèmes liés aux couches DNS, vérifiez si la destination est accessible directement en utilisant son adresse IP depuis le pod concerné :

# 1. Test raw IP reachability (bypasses DNS entirely)
kubectl exec -it my-pod -n default -- curl -v --connect-timeout 5 http://10.240.0.10:8080

# 2. Test domain resolution
kubectl exec -it my-pod -n default -- curl -v --connect-timeout 5 http://my-service.default.svc.cluster.local:8080

• Si la connexion IP réussit, mais que la connexion au domaine échoue : le problème est isolé au niveau de la couche de résolution DNS. Passez à l'étape 2.
• Si les deux échouent : le problème est lié au routage au niveau du réseau ou à l'application des règles. Passez à Diagnostiquer les pertes de paquets et les blocages NetworkPolicy.

Vérifier le préremplissage DNS de la règle de réseau FQDN

Si votre cluster utilise des NetworkPolicies basées sur un FQDN (FQDNNetworkPolicy), vérifiez que le nom de domaine est explicitement autorisé. Si un pod interroge un domaine externe qui n'est pas prérempli dans le cache du proxy DNS GKE Dataplane V2 ou autorisé par une règle, GKE Dataplane V2 bloque le trafic de sortie vers l'adresse IP résolue :

# Verify whether UDP or TCP port 53 egress is permitted in the Pod's namespace
kubectl get networkpolicy -n default -o yaml | grep -A 5 -B 2 "port: 53"

Étape 2 : Vérifier les métriques DNS dans Cloud Monitoring

GKE expose les métriques DNS intégrées dans Cloud Monitoring sous le préfixe kubernetes.io/networking/dns/.

Important : Si votre cluster utilise Cloud DNS pour GKE, les requêtes DNS ne passent pas par les pods kube-dns ou NodeLocal DNSCache. Ces métriques kube-dns restent stables. Consultez la documentation Cloud DNS pour résoudre les problèmes de requêtes DNS dans ce mode.

Pour vérifier les métriques DNS dans Cloud Monitoring, procédez comme suit :

1. Dans la console Google Cloud , accédez à Cloud Monitoring > Tableaux de bord.
2. Sélectionnez le tableau de bord prédéfini GKE DNS Observability - Cluster View (ou accédez à l'explorateur de métriques et filtrez par kubernetes.io/networking/dns/).
3. Évaluez les signaux principaux suivants (pour NodeLocal DNSCache, remplacez kubedns par node_local_dns dans le chemin d'accès de la métrique) :

Nom de la métrique	Seuil d'avertissement	Cause principale
kubernetes.io/networking/dns/kubedns/max_concurrent_rejected_request_count	> 0	Limite de requêtes simultanées atteinte. kube-dns ou NodeLocal DNSCache supprime des requêtes.
kubernetes.io/networking/dns/kubedns/dns_request_latencies	p99 > 100 ms	Latence élevée de la résolution DNS de bout en bout sur kube-dns ou NodeLocal DNSCache.
kubernetes.io/networking/dns/kubedns/forwarding_request_latencies	p99 > 100 ms	Latence ou saturation du serveur DNS en amont.

Séquence de tri des performances et des délais d'expiration DNS

Suivez cette séquence de tri pour diagnostiquer la latence DNS, les échecs de cache et les délais d'expiration en amont :

1. Vérifier le taux d'accès au cache : requête kubernetes.io/networking/dns/kubedns/dns_cache_request_count (ou node_local_dns/dns_cache_request_count) regroupée par l'étiquette cache_status. Si cache_status="hit" est faible et cache_status="miss" est élevé, les applications peuvent émettre des requêtes non-FQDN (telles que my-service au lieu de my-service.default.svc.cluster.local), ce qui entraîne un parcours du chemin de recherche sur toutes les entrées de /etc/resolv.conf.
2. Évaluez la latence en amont : une valeur forwarding_request_latencies élevée indique des problèmes avec le serveur DNS en amont (par exemple, un DNS d'entreprise sur site atteint via Cloud Interconnect ou Cloud VPN, ou des limites Cloud DNS).

3. Auditer les remplacements DNS personnalisés : inspectez les ConfigMaps kube-dns personnalisés pour détecter les simulations ou les transferts en amont mal configurés :

   kubectl get configmap kube-dns -n kube-system -o yaml
   

Étape 3 : Diffusez le trafic DNS en direct avec la CLI Hubble

Utilisez l'alias d'assistance de la CLI Hubble pour inspecter les requêtes et réponses DNS en direct diffusées depuis le noyau du nœud :

# 1. Ensure the helper alias is set in your terminal session
alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

# 2. Observe live DNS (Port 53) traffic for a specific Pod
gke-hubble observe --pod default/my-pod --port 53

Remarque : La CLI Hubble analyse les en-têtes DNS au niveau de la couche d'application (couche 7 du modèle OSI). Dans le résultat du flux, recherchez les champs DNS Query et DNS Answer. Si la requête affiche RCODE: NXDOMAIN ou RCODE: SERVFAIL, le serveur DNS rejette l'enregistrement ou ne peut pas le résoudre.

Étape 4 : Validez le correctif

Si des rejets de requêtes simultanées se sont produits, appliquez NodeLocal DNSCache pour absorber les résolutions DNS à haute fréquence directement sur le nœud sans atteindre les limites kube-dns à l'échelle du cluster :

# Verify NodeLocal DNSCache DaemonSet is running
kubectl get daemonset node-local-dns -n kube-system

---

Diagnostiquer les pertes de paquets et les blocages de NetworkPolicy

Examinez le champ d'application du diagnostic et les conditions préalables avant d'examiner les pertes de paquets et les refus de règles :

• Domaine d'intérêt : pertes de trafic entre les objets Pod ou entre les objets Pod et Service, application de NetworkPolicy, raisons de la perte d'eBPF du noyau.
• Prérequis : l'observabilité des flux GKE Dataplane V2 doit être activée et la journalisation NetworkPolicy doit être configurée.
• Compatibilité CNI : GKE Dataplane V2 uniquement.
• Symptôme : les tentatives de connexion de l'application échouent avec Connection timed out ou Connection reset by peer.
• Objectif : identifier la raison exacte liée à NetworkPolicy ou eBPF pour laquelle des paquets sont supprimés, sans avoir à modifier les règles de sécurité par tâtonnement.

Étape 1 : Surveillez les métriques de suppression de Hubble

Lorsque GKE Dataplane V2 supprime un paquet, il émet la métrique hubble_drop_total, qui est taguée avec la raison de la suppression, ainsi que les métadonnées de la source et de la destination. Pour surveiller les métriques de suppression Hubble, procédez comme suit :

1. Si ce n'est pas déjà fait, déployez une ressource PodMonitoring Google Cloud Managed Service pour Prometheus afin de récupérer les métriques Hubble :

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: hubble-metrics
     namespace: gke-managed-dpv2-observability
   spec:
     selector:
       matchLabels:
         k8s-app: cilium
     endpoints:
     - port: hubble-metrics
       interval: 30s
   

2. Exécutez la requête suivante dans Cloud Monitoring > Explorateur de métriques pour afficher les suppressions par motif :

   sum by (reason) (rate(hubble_drop_total[5m])) > 0
   

3. Interprétez les codes reason courants :

   • Policy denied : une ressource NetworkPolicy Kubernetes bloque explicitement ou implicitement la connexion.
   • CT: Map insertion failed : la table de suivi des connexions (conntrack) est épuisée.
   • Unsupported L3 protocol : paquet non IPv4 ou IPv6, ou en-tête corrompu.

Étape 2 : Vérifier les journaux NetworkPolicy dans Cloud Logging

La journalisation NetworkPolicy exporte des journaux JSON structurés pour toutes les décisions liées aux règles. Pour interroger les journaux NetworkPolicy dans Cloud Logging, procédez comme suit :

1. Dans la console Google Cloud , accédez à Cloud Logging > Explorateur de journaux.

2. Exécutez la requête suivante :

   resource.type="k8s_node"
   log_name:"projects/PROJECT_ID/logs/events"
   jsonPayload.connection.verdict="DENY"
   jsonPayload.src.pod_name="my-source-pod"
   

3. Inspectez la charge utile JSON :

   • jsonPayload.drop_reason : indique pourquoi le paquet a été supprimé.
   • jsonPayload.policies : liste les objets NetworkPolicy qui ont été évalués. Si une liste vide est renvoyée avec un verdict DENY, l'espace de noms fonctionne en mode de refus par défaut et aucune règle n'a autorisé le trafic.

Si aucun journal NetworkPolicy n'apparaît, vérifiez que la journalisation est activée dans la ressource personnalisée NetworkLogging du cluster. Par exemple, vérifiez que le champ spec.cluster.deny.log est défini sur true :

kubectl get networklogging default -o yaml

Étape 3 : Suivez les pertes de paquets en direct avec la CLI Hubble

Diffusez les pertes en direct en utilisant la CLI Hubble pour inspecter les paquets en temps réel :

gke-hubble observe --verdict DROPPED --namespace default --follow

Exemple de résultat :

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:14:22.102          default/frontend     default/backend:80   to-stack DROPPED (Policy denied by NetworkPolicy: backend-deny-all)

Le résultat indique la NetworkPolicy exacte qui bloque le trafic (backend-deny-all).

Étape 4 : Vérifier l'épuisement de conntrack

Si le motif de la suppression indique CT: Map insertion failed :

1. Inspectez le journal de l'agent GKE Dataplane V2 pour détecter une saturation de la table conntrack :

   kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=100 | grep "Conntrack table full"
   

2. Vérifiez la taille maximale de la table conntrack sur le nœud concerné :

   kubectl exec -it -n kube-system daemonset/anetd -c cilium-agent -- cilium status --all-controllers | grep -i conntrack
   

   Si la table conntrack est pleine, effectuer un scaling horizontal de vos charges de travail sur davantage de nœuds ou réduisez le taux de connexion des pods clients.

---

Diagnostiquer un déséquilibre du trafic et des réinitialisations TCP

Examinez le champ d'application du diagnostic et les conditions préalables avant de résoudre les problèmes de déséquilibre du trafic et de réinitialisation de la connexion :

• Domaine d'intérêt : irrégularité de l'équilibrage de charge, échecs de handshake TCP, interruption soudaine de la connexion.
• Prérequis : les métriques GKE Dataplane V2 doivent être activées.
• Compatibilité CNI : GKE Dataplane V2.
• Symptôme : certaines instances répliquées de pods reçoivent un trafic excessif, tandis que d'autres restent inactives. Les applications clientes enregistrent connection reset by peer ou broken pipe.
• Objectif : déterminer si le déséquilibre du trafic est dû à l'adhérence de la connexion au niveau de la couche transport (couche OSI 4, TCP) ou de la couche application (couche OSI 7, HTTP/2 ou gRPC), et identifier la source des paquets TCP RST.

Étape 1 : Comparez le flux de trafic au niveau du pod

Pour déterminer si le trafic est réparti de manière uniforme entre vos instances répliquées, procédez comme suit :

1. Dans Cloud Monitoring, interrogez le nombre de flux d'entrée sur tous les pods d'un déploiement :

   sum by (pod) (rate(pod_flow_ingress_flows_count{destination_workload="my-service"}[5m]))
   

2. Évaluez la répartition du trafic entre les pods. Si un seul pod reçoit la majorité du trafic, examinez la réutilisation des connexions ou les sessions persistantes :

   • gRPC ou HTTP/2 : les connexions TCP de longue durée entraînent le passage de toutes les requêtes par un seul flux TCP vers un pod de backend. Le routage de service Kubernetes de couche transport (couche 4 OSI, TCP) ne peut pas équilibrer les requêtes au sein d'une connexion HTTP/2 établie.
   • Affinité de session ClientIP : vérifiez si le service est configuré avec sessionAffinity: ClientIP.
   • Services sans adresse IP de cluster : les clients peuvent résoudre le DNS une fois et mettre en cache l'adresse IP unique de manière permanente.

Étape 2 : Analysez les métriques de réinitialisation TCP

Les réinitialisations TCP (RST) mettent fin aux connexions immédiatement. Ils sont émis par le noyau du système d'exploitation lorsqu'un point de terminaison reçoit un paquet pour un port inconnu, ou lorsqu'une application ferme une connexion avec des données non lues dans le tampon.

Exécutez la requête MQL suivante dans Cloud Monitoring :

fetch prometheus_target
| metric 'prometheus.googleapis.com/hubble_tcp_flags_total/counter'
| filter (metric.flag == 'RST')
| align rate(1m)
| every 1m
| group_by [metric.source, metric.destination, metric.traffic_direction], sum(val())

Examinez les résultats de la requête pour déterminer la source de la réinitialisation :

• RST sortant (traffic_direction=egress) : le pod local génère la réinitialisation. Vérifiez si l'application du pod plante, atteint sa limite de connexion ou rejette activement la connexion.
• RST entrant (traffic_direction=ingress) : le pair distant (base de données externe, API ou pod distant) a envoyé la réinitialisation. Vérifiez l'état de santé et du pare-feu du serveur de destination.

Étape 3 : Diffusez les réinitialisations TCP en direct

Utilisez la CLI Hubble pour capturer le handshake de réinitialisation en direct :

gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST --namespace default

Étape 4 : Correction et mesures correctives

Appliquez les étapes de correction suivantes en fonction de la cause de votre déséquilibre de trafic ou de vos réinitialisations TCP :

• Pour l'affinité de connexion au niveau de la couche d'application (couche 7 OSI) ou gRPC :
  • Déployez Cloud Service Mesh pour activer l'équilibrage de charge au niveau des requêtes de la couche d'application (couche 7 du modèle OSI).
  • Configurez des limites de connexion côté client ou des délais d'expiration de persistance (par exemple, MAX_CONNECTION_AGE et MAX_CONNECTION_AGE_GRACE gRPC) pour forcer le rétablissement périodique de la connexion.
• Pour l'affinité d'adresse IP du service : supprimez service.spec.sessionAffinity, sauf si l'état de l'application l'exige strictement.
• Pour la mise en cache DNS des services sans adresse IP de cluster : assurez-vous que les environnements d'exécution d'application (tels que JVM networkaddress.cache.ttl) ne mettent pas en cache les résultats DNS indéfiniment.
• Pour le dépassement de la file d'attente du backlog d'application : lorsqu'une file d'attente d'écoute d'application est pleine, le noyau Linux supprime les paquets SYN entrants ou envoie un RST TCP. Effectuez un scaling horizontal des instances répliquées de pods ou augmentez le backlog d'écoute de l'application (somaxconn).

---

Niveau 2 : Observabilité des nœuds et de l'interface CNI (noyau)

Le niveau du nœud et de l'interface CNI englobe le noyau Linux hôte, les programmes eBPF et les interfaces réseau du nœud. Les goulots d'étranglement à ce niveau affectent toutes les charges de travail exécutées sur le nœud concerné.

Vérification de l'intégrité du système : détection des correctifs non autorisés d'anetd

Attention : Modifier ou redémarrer manuellement le DaemonSet de mise en réseau GKE Dataplane V2 (anetd) peut entraîner des pannes de réseau à l'échelle du cluster et enfreindre les objectifs de niveau de service géré de GKE.

GKE Dataplane V2 s'exécute en tant que DaemonSet géré (anetd) dans l'espace de noms kube-system. Dans Cloud Logging, vous pouvez interroger les journaux d'audit Kubernetes pour détecter si des utilisateurs non autorisés ou des scripts automatisés ont corrigé ou redémarré anetd :

protoPayload.methodName="io.k8s.core.v1.daemonsets.patch" OR
protoPayload.methodName="io.k8s.core.v1.daemonsets.update"
protoPayload.resourceName="namespaces/kube-system/daemonsets/anetd"

Si une application de correctifs non autorisée est détectée, rétablissez la configuration par défaut du DaemonSet ou déclenchez une recréation du pool de nœuds pour restaurer l'état géré.

---

Triage de la latence au niveau des nœuds et des goulots d'étranglement CNI

Examinez le champ d'application et les conditions préalables du diagnostic avant de diagnostiquer la latence au niveau du nœud et les goulots d'étranglement du noyau :

• Domaine d'intérêt : latence du noyau hôte, pertes de paquets au niveau de l'interface de la VM, saturation de l'agent eBPF GKE Dataplane V2, épuisement de conntrack.
• Prérequis : métriques de VM Compute Engine activées ; accès kubectl.
• Compatibilité CNI : GKE Dataplane V2 et GKE CNI standard.
• Symptôme : le trafic entre les nœuds subit des pics de latence ou des pertes aléatoires, tandis que le trafic intra-nœud reste opérationnel.
• Objectif : différencier la limitation de bande passante réseau de la VM hôte, les pertes de paquets du noyau Linux et les goulots d'étranglement au niveau de l'interface CNI.

Étape 1 : Différencier les problèmes extérieurs à GKE des problèmes internes à GKE

Exécutez le test de référence de VM Compute Engine : déployez une VM Compute Engine autonome dans le même sous-réseau VPC que les nœuds du cluster GKE. Testez la connectivité de la VM à la destination cible.

• Si la VM autonome subit les mêmes pertes de paquets ou la même latence, le problème se situe en dehors de GKE (pare-feu VPC, Cloud NAT, Cloud Interconnect ou serveur externe). Passez à la section Isoler les problèmes de connectivité GKE par rapport aux problèmes de connectivité VPC ou externe.
• Si la VM autonome communique normalement, mais que les pods GKE échouent : le problème se situe dans GKE (eBPF, conntrack ou CNI au niveau du nœud). Passez à l'étape 2.

Limites du test de référence de VM : ce test peut ne pas détecter les pertes intermittentes ou à faible débit qui ne se manifestent que sous des volumes de trafic agrégés élevés. De plus, si le problème est isolé au niveau du matériel sous-jacent d'un seul hôte de VM, il est possible que les autres VM ne reproduisent pas le comportement.

Étape 2 : Différenciez les problèmes d'application des problèmes liés aux nœuds et au niveau CNI

Résoudre les problèmes de collision de ports SNAT ip-masq-agent personnalisés : Les clusters utilisant une configuration ip-masq-agent personnalisée avec l'option --random-fully peuvent rencontrer une latence de sortie intermittente. En cas de volumes de trafic élevés, iptables --random-fully peut allouer un port éphémère qui entre en conflit avec un NodePort actif, ce qui entraîne des retards de connexion. Mettez à niveau ip-masq-agent vers la version 2.11.1 ou ultérieure, ou supprimez --random-fully pour éviter les conflits de ports.

Pour déterminer si la latence provient de l'application ou du nœud et du niveau CNI, procédez comme suit :

1. Vérifiez la saturation des ressources de l'application : vérifiez que le nœud ne subit pas de limitation du processeur ni de pression de la mémoire, ce qui retarde le traitement des paquets dans l'espace utilisateur :

   kubectl top nodes
   kubectl top pods -n default
   

2. Inspecter le nombre de conntracks du noyau Linux : vérifiez le nombre de conntracks actifs sur l'hôte :

   # On a node where you have debugging access
   cat /proc/sys/net/netfilter/nf_conntrack_count
   cat /proc/sys/net/netfilter/nf_conntrack_max
   

   Si nf_conntrack_count approche de nf_conntrack_max, le kernel hôte supprime les nouveaux paquets TCP SYN.

Étape 3 : Vérifiez les pertes de paquets au niveau de la VM à l'aide de la télémétrie Compute Engine

Google Cloud Compute Engine exporte les métriques d'interface réseau au niveau de la VM vers Cloud Monitoring.

Dans Cloud Monitoring > Explorateur de métriques, exécutez la requête suivante :

sum by (drop_reason) (rate(compute_googleapis_com:instance_network_dropped_packets_count[5m]))

• FQ_CODEL_DROP : paquet supprimé en raison d'une saturation de la file d'attente Fair Queuing ou CoDel (limite de bande passante de sortie de la VM dépassée).
• FIREWALL_RULE_DROP : paquet supprimé par une règle de pare-feu VPC.
• RATE_LIMIT_DROP : paquet supprimé, car la VM a dépassé son quota maximal de paquets par seconde (PPS) de l'interface réseau.

Étape 4 : Examinez les pertes au niveau du noyau à l'aide d'eBPF

Si les métriques au niveau de la VM n'indiquent aucune perte, mais que les pods GKE continuent de perdre des paquets, inspectez l'agent GKE Dataplane V2 (anetd) pour détecter les pertes de mappage eBPF :

kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=200 | grep -i "drop"

Recherchez ct-map-insertion-failed ou fib-lookup-failed.

---

Niveau 3 : Observabilité du VPC et du routage (Cloud Network)

Le niveau de routage VPC et cloud connecte les nœuds GKE à d'autres services Google Cloud , aux réseaux sur site et à Internet. Les échecs à ce niveau proviennent généralement des règles de pare-feu VPC, des routes personnalisées ou des configurations de passerelle.

Isoler les problèmes de connectivité GKE par rapport aux problèmes de connectivité VPC ou externe

Examinez le champ d'application du diagnostic et les conditions préalables avant d'isoler les problèmes de réseau externe des défaillances au sein du cluster :

• Domaine d'intérêt : isolation des limites entre le routage interne Kubernetes et le routage cloud VPC.
• Prérequis : gcloud CLI ; autorisations de créer des tests de connectivité.
• Compatibilité CNI : tous les clusters.
• Symptôme : Les pods ne parviennent pas à se connecter à une ressource externe (par exemple, Cloud SQL, une API sur site ou un point de terminaison tiers).
• Objectif : déterminer rapidement si la suppression se produit dans le nœud GKE, dans le VPC Google Cloud ou dans le réseau externe.

Étape 1 : Test de référence de la VM Compute Engine

Pour déployer une VM de référence et évaluer si le problème persiste en dehors de GKE, procédez comme suit :

1. Déployez une instance de VM Compute Engine temporaire dans le même sous-réseau et la même zone VPC que votre pool de nœuds GKE :

   gcloud compute instances create gke-baseline-tester \
       --zone=us-central1-a \
       --subnet=gke-subnet \
       --machine-type=e2-micro
   

2. Connectez-vous à l'instance via SSH et testez la connectivité à la destination :

   curl -v --connect-timeout 5 https://api.example.com
   

3. Évaluer le résultat :

   • Si la VM Compute Engine ne peut pas se connecter : le problème se situe au niveau du VPC ou du réseau externe (règles de pare-feu, tables de routage, épuisement des adresses IP Cloud NAT ou ajout d'adresses IP externes à la liste d'autorisation).
   • Si la VM Compute Engine se connecte correctement : le problème se situe dans GKE (NetworkPolicy bloquant la sortie, CIDR de pod non masqué ou DNS au niveau du conteneur).

Étape 2 : Exécuter un test de connectivité à la demande

Exécutez un test de Google Cloud Tests de connectivité depuis la VM du nœud vers la destination :

gcloud network-management connectivity-tests create test-node-to-dest \
    --source-instance=projects/PROJECT_ID/zones/us-central1-a/instances/gke-baseline-tester \
    --destination-ip-address=203.0.113.10 \
    --destination-port=443 \
    --protocol=TCP \
    --round-trip

Vérifiez le résultat dans la console Google Cloud pour déterminer si une règle de pare-feu ou une route VPC supprime le trafic.

---

Diagnostiquer la connectivité à l'aide de Tests de connectivité

Les tests de connectivité simulent les chemins des paquets entre les ressources GKE et VPC sans envoyer de trafic réel. Cette simulation évalue la résolution DNAT de l'adresse ClusterIP du service vers le pod, les règles d'entrée et de sortie NetworkPolicy de GKE Dataplane V2, ainsi que l'IP masquerading (SNAT) des nœuds. Examinez le champ d'application du diagnostic et les conditions préalables avant d'exécuter des simulations de chemin automatisées :

• Domaine d'intervention : simulation de chemin statique automatisée pour les pods, les services, les NetworkPolicies et les routes VPC GKE.
• Prérequis : Network Intelligence Center activé ; API Network Management activée.
• Compatibilité CNI : GKE Dataplane V2 (analyse améliorée).
• Symptôme : pertes de connectivité inexpliquées alors que toutes les configurations semblent valides lors d'une inspection manuelle.
• Objectif : simuler et tracer de manière statique l'intégralité du chemin des paquets d'une source de pod vers une destination, en identifiant la ligne exacte de la règle à l'origine d'une suppression.

Scénario A : Vérifier si une règle NetworkPolicy GKE bloque la collecte de métriques

Lors de l'extraction de métriques à partir de pods dans un espace de noms sécurisé, les collecteurs Google Cloud Managed Service pour Prometheus peuvent être bloqués par une NetworkPolicy de refus par défaut :

gcloud network-management connectivity-tests create test-gmp-to-pod \
    --source-ip-address=10.0.0.15 \
    --destination-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/backend-pod \
    --destination-port=8080 \
    --protocol=TCP \
    --round-trip

Inspectez la trace de test dans la console Google Cloud . Si le test se termine à l'étape GKE Network Policy evaluation avec DROP, une règle d'entrée doit être ajoutée pour autoriser le trafic provenant des pods du collecteur.

Scénario B : Vérifier l'accessibilité d'un service GKE

Simulez l'accessibilité d'une VM cliente à un service Kubernetes interne :

gcloud network-management connectivity-tests create test-vm-to-service \
    --source-instance=projects/PROJECT_ID/zones/us-central1-a/instances/client-vm \
    --destination-ip-address=10.96.0.100 \
    --destination-port=80 \
    --protocol=TCP \
    --round-trip

La trace simulée affiche les éléments suivants :

1. Correspondance de route VPC.
2. Autorisation de sortie et d'entrée du pare-feu VPC.
3. Arrivée au nœud GKE.
4. DNAT du service vers l'adresse IP du pod de backend.
5. Évaluation de la règle NetworkPolicy d'entrée sur le pod de backend.

Scénario C : Diagnostiquer les problèmes de sortie d'un pod vers Internet

Lorsque les pods ne peuvent pas accéder à une API externe sur Internet :

1. Créez un test du pod vers l'adresse IP publique externe (par exemple, 8.8.8.8) :

   gcloud network-management connectivity-tests create test-pod-to-internet \
       --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/app-pod \
       --destination-ip-address=8.8.8.8 \
       --destination-port=53 \
       --protocol=UDP \
       --round-trip
   

2. Examinez le point de dépôt :

   • Abandonné au niveau de NetworkPolicy : le pod ne dispose pas d'une règle NetworkPolicy de sortie autorisant le trafic vers 0.0.0.0/0.
   • Supprimé au niveau du pare-feu VPC : une règle de pare-feu VPC refuse le trafic sortant du sous-réseau du nœud.
   • Supprimé au niveau de Cloud NAT ou de la route : le sous-réseau ne dispose pas d'une route par défaut vers la passerelle Internet ou Cloud NAT n'est pas configuré pour le sous-réseau.

---

Niveau 4 : Observabilité de la passerelle externe et des coûts (Internet et NAT)

Le niveau de passerelle externe gère le trafic sortant vers des destinations Internet publiques via Cloud NAT ou des passerelles externes. L'observabilité à ce niveau permet d'identifier les charges de travail à fort trafic sortant et de contrôler les coûts de transfert de données.

Identifier le trafic NAT (sortie vers Internet)

Examinez le champ d'application et les conditions préalables du diagnostic avant d'analyser le trafic Internet et NAT sortant :

• Domaine d'intérêt : trafic Internet sortant, utilisation des ports Cloud NAT, coûts de transfert de données externes.
• Prérequis : l'observabilité des flux GKE Dataplane V2 doit être activée.
• Compatibilité CNI : GKE Dataplane V2.
• Symptôme : erreurs d'épuisement des ports Cloud NAT ou coûts de sortie Internet sortants anormalement élevés.
• Objectif : identifier les objets Pod et Service GKE spécifiques qui transmettent du trafic vers des points de terminaison Internet externes.

Étape 1 : Comprendre les concepts de "to-stack" et de "world" dans GKE Dataplane V2

Dans GKE Dataplane V2 :

• world : représente toute destination en dehors du cluster GKE et du VPC (l'Internet public).
• to-stack : représente les paquets qui passent de l'interface veth du conteneur eBPF à la pile réseau Linux de l'hôte pour subir un masquage d'adresse IP (SNAT) avant d'atteindre Cloud NAT.

Étape 2 : Diffuser et filtrer le trafic NAT avec la CLI Hubble

Diffusez en direct les flux Internet sortants provenant de votre cluster :

# Stream egress flows heading to external internet ("world")
gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    --follow

Exemple de résultat :

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:25:01.120          default/worker-pod   142.250.190.46:443   to-stack FORWARDED

Pour identifier les principaux émetteurs sortants, vous pouvez également rediriger la sortie JSON de Hubble vers jq pour compter les flux de sortie externes par pod :

timeout 60s gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    -o json | jq -r '.flow.source.namespace + "/" + .flow.source.pod_name' | sort | uniq -c | sort -nr | head -n 10

Étape 3 : Surveiller le trafic externe à l'aide de métriques

Dans Cloud Monitoring, suivez le volume des flux externes :

fetch prometheus_target
| metric 'prometheus.googleapis.com/pod_flow_egress_flows_count/counter'
| filter (metric.destination_identity == 'world')
| align rate(1m)
| every 1m
| group_by [metric.source_workload, metric.source_namespace], sum(val())

---

Analyser les coûts et les performances du trafic des clusters à l'aide de Flow Analyzer

Examinez le champ d'application et les conditions préalables du diagnostic avant de visualiser les flux de trafic et les coûts interzones :

• Domaine d'intérêt : coûts de transfert de données interzone, principaux émetteurs, visibilité du trafic entre les nœuds sans requêtes SQL.
• Prérequis : journaux de flux VPC activés avec INCLUDE_ALL_METADATA ; visibilité intranœud activée ; Analyse de l'observabilité activée sur le bucket de journaux.
• Compatibilité CNI : tous les clusters.
• Symptôme : frais de transfert de données interzones élevés sur les factures mensuellesGoogle Cloud .
• Objectif : identifier visuellement les charges de travail GKE qui génèrent du trafic interzone et optimiser l'emplacement sans interroger les journaux bruts.

Prérequis

Pour utiliser Flow Analyzer pour GKE :

1. Journaux de flux VPC : doivent être activés sur le sous-réseau du cluster avec metadata="INCLUDE_ALL_METADATA".
2. Visibilité intranœud : doit être activée sur le cluster afin que le trafic entre pods soit exposé au pipeline de journalisation des flux VPC.
3. Analyse de journaux : le bucket _Default dans Cloud Logging doit être mis à niveau pour utiliser l'Analyse de l'observabilité.

Remarque : Les journaux de flux sont écrits dans le projet propriétaire du réseau. Dans une configuration de VPC partagé, ce projet est le projet hôte, et non le projet de service qui s'exécute sur votre cluster GKE. Exécutez Flow Analyzer dans le projet hôte et utilisez l'ID du projet hôte pour PROJECT_ID dans la requête Analyse de l'observabilité.

Étape 1 : Identifier les top talkers GKE dans Flow Analyzer

Pour afficher les charges de travail à volume élevé dans Flow Analyzer, procédez comme suit :

1. Dans la console Google Cloud , accédez à la page Flow Analyzer.
2. Cliquez sur Bucket source, puis sélectionnez le bucket de journaux qui contient vos journaux de flux. Sauf si vous les avez acheminés ailleurs, il s'agit du bucket _Default.
3. Dans Agrégation du trafic, sélectionnez Source - Destination.
4. Définissez la période de votre fenêtre d'analyse.
5. Sous Organiser les flux par, sélectionnez les champs de pod ou de charge de travail GKE.
6. Cliquez sur Exécuter une nouvelle requête. Le graphique Flux de données les plus élevés indique les charges de travail qui déplacent le plus de données.

Étape 2 : Analyser les coûts du trafic interzone

Le trafic interzone entraîne des frais de transfert de données. Pour localiser les charges de travail qui transmettent des données entre les zones :

1. Sous Organiser les flux par, sélectionnez les champs de zone source et de zone de destination.
2. Cliquez sur Exécuter une nouvelle requête et lisez le tableau Tous les flux de données. Les lignes où les zones source et de destination diffèrent correspondent à votre trafic interzone. Les filtres de Flow Analyzer correspondent à des valeurs. Vous ne pouvez donc pas filtrer par "différent de". Comparez plutôt les paires de zones dans les résultats.
3. Développez une paire de zones à volume élevé pour afficher les charges de travail GKE sources et de destination sous-jacentes.

Remédiation :

• Implémentez topologySpreadConstraints ou podAffinity Kubernetes pour colocaliser les services communicants dans la même zone de disponibilité.
• Activez le routage basé sur la topologie (service.kubernetes.io/topology-mode: Auto) sur le service pour que le trafic reste dans la zone d'origine.

Étape 3 : Accéder à l'analyse de l'observabilité (pour les requêtes SQL avancées)

Dans Flow Analyzer, cliquez sur Afficher dans l'Analyse de journaux pour exécuter des requêtes SQL sur les données de flux.

La requête SQL suivante calcule les principaux pods qui communiquent entre les zones :

SELECT
  JSON_VALUE(json_payload.src_gke_details.pod.workload.workload_name) AS src_workload,
  JSON_VALUE(json_payload.dest_gke_details.pod.workload.workload_name) AS dest_workload,
  JSON_VALUE(json_payload.src_instance.zone) AS src_zone,
  JSON_VALUE(json_payload.dest_instance.zone) AS dest_zone,
  SUM(CAST(JSON_VALUE(json_payload.bytes_sent) AS INT64)) / 1024 / 1024 / 1024 AS total_gb_sent
FROM
  `PROJECT_ID.global._Default._AllLogs`
WHERE
  log_name LIKE '%vpc_flows%'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND JSON_VALUE(json_payload.src_instance.zone) != JSON_VALUE(json_payload.dest_instance.zone)
GROUP BY
  1, 2, 3, 4
ORDER BY
  total_gb_sent DESC
LIMIT 20;

---

Documentation de référence sur la CLI Hubble et aide-mémoire pour les requêtes

La CLI Hubble diffuse et filtre les données de flux réseau en temps réel directement à partir du tampon circulaire du noyau GKE Dataplane V2.

Configuration : créer un alias d'assistance

Étant donné que Hubble s'exécute dans le plan de contrôle du cluster, configurez un alias de shell pour exécuter les commandes Hubble sans déployer de binaires locaux :

alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

Recettes de filtrage courantes

Objectif de dépannage	Commande CLI Hubble
Observez tous les paquets supprimés en temps réel dans le cluster.	gke-hubble observe --verdict DROPPED --follow
Diffuser tout le trafic d'un pod spécifique dans n'importe quel espace de noms	gke-hubble observe --pod default/my-pod --follow
Filtrer le trafic entre deux espaces de noms spécifiques	gke-hubble observe --from-namespace frontend --to-namespace backend
Isoler le trafic sur un port spécifique (par exemple, le port 80)	gke-hubble observe --port 80
Inspecter les requêtes et réponses DNS en direct	gke-hubble observe --port 53
Afficher les réinitialisations TCP en direct (paquets RST)	gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST
Diffuser tout le trafic sortant vers l'Internet public	gke-hubble observe --traffic-direction egress --to-identity world
Inspecter le trafic de la couche d'application HTTP (couche 7 OSI)	gke-hubble observe --protocol http

Filtrage avancé avec négation (--not)

Vous pouvez exclure le trafic connu à volume élevé ou sain pour vous concentrer sur les anomalies :

# Observe drops, but exclude internal kube-system health probes and DNS
gke-hubble observe \
    --verdict DROPPED \
    --not --namespace kube-system \
    --not --port 53

Formatage de la sortie et intégration de jq

Pour traiter les enregistrements de flux de manière automatisée, générez la sortie au format JSON :

# Extract only source, destination, and drop reason from the last 100 flows
gke-hubble observe --verdict DROPPED -o json --last 100 | \
    jq -r '[.time, .flow.source.pod_name, .flow.destination.pod_name, .flow.drop_reason_desc] | @tsv'

Limites

Lorsque vous utilisez la CLI Hubble pour résoudre des problèmes en direct, tenez compte des limites techniques suivantes :

• Tampon circulaire éphémère local au nœud : les flux Hubble sont stockés dans un tampon circulaire en mémoire sur chaque nœud individuel. Lors d'événements à fort trafic, les anciens journaux de flux sont écrasés en quelques secondes. Pour l'analyse de l'historique, utilisez la journalisation NetworkPolicy et les journaux de flux VPC dans Cloud Logging.
• Pas d'opérateur logique OR intégré : les options de la CLI Hubble évaluent plusieurs arguments à l'aide de l'opérateur logique AND. Pour rechercher plusieurs conditions (par exemple, le port 80 OU le port 443), exécutez des commandes distinctes ou filtrez la sortie JSON à l'aide de jq.

Étapes suivantes

• Bonnes pratiques pour l'observabilité du réseau
• Résoudre les problèmes de mise en réseau GKE
• Résoudre les problèmes de connectivité de votre cluster
• À propos de l'observabilité de GKE Dataplane V2
• Résoudre les problèmes de données dans Flow Analyzer