Bonnes pratiques pour l'observabilité du réseau GKE

La gestion de la connectivité réseau et des règles de sécurité dans les environnements Kubernetes dynamiques présente des défis opérationnels importants. L'observabilité de GKE Dataplane V2 offre aux administrateurs de plate-forme une visibilité au niveau du noyau sur le trafic réseau des clusters, ce qui peut aider à résoudre rapidement les problèmes, à effectuer des audits de conformité continus et à valider de manière proactive les chemins d'accès.

Ce document décrit l'architecture conceptuelle et les bonnes pratiques pour l'observabilité du réseau Google Kubernetes Engine (GKE), y compris la pile de télémétrie, un modèle mental pour le triage, les règles d'alerte proactives, l'automatisation Terraform et les techniques d'optimisation des coûts.

Pour obtenir des instructions de dépannage détaillées et des procédures de diagnostic, consultez Résoudre les problèmes d'observabilité du réseau.

Avantages de l'observabilité du réseau GKE

L'implémentation d'une stratégie d'observabilité dans GKE offre les principaux avantages suivants :

  • Délai moyen de résolution (MTTR) accéléré : en exploitant les métriques optimisées par eBPF et les journaux de flux Hubble, vous pouvez isoler immédiatement les anomalies réseau. Cette visibilité vous permet de faire la distinction entre les échecs au niveau de l'application, les blocages de NetworkPolicy Kubernetes et les abandons de pare-feu VPC, ce qui réduit les cycles de débogage de plusieurs heures à quelques minutes.
  • Instrumentation au niveau du kernel sans sidecars : GKE Dataplane V2 exécute la logique d'observabilité directement dans le kernel Linux de l'hôte à l'aide d'eBPF. Cela élimine le besoin de proxys sidecar gourmands en ressources ou de modifications du code au niveau de l'application, ce qui garantit une surcharge minimale et préserve les performances de l'application.
  • Audit continu de la conformité en matière de sécurité : la journalisation NetworkPolicy génère des journaux d'audit détaillés pour chaque tentative de connexion (verdicts ALLOW ou DENY). Ces journaux fournissent un enregistrement infalsifiable du trafic du cluster, ce qui est essentiel pour répondre aux exigences des cadres de conformité réglementaires (tels que PCI-DSS, SOC 2 et HIPAA).
  • Validation proactive des chemins d'accès : l'intégration aux tests de connectivité vous permet de simuler des chemins d'accès réseau et d'évaluer les NetworkPolicies GKE de manière statique avant le déploiement des charges de travail. Vous évitez ainsi les écarts de configuration et les problèmes de connectivité lors de la phase de déploiement.
  • Optimisation des ressources et des coûts : le suivi détaillé des flux met en évidence les inefficacités telles que l'utilisation excessive des ports Cloud NAT, les pics de transfert de données entre zones et les modèles de résolution DNS non mis en cache, ce qui permet une planification de la capacité et une gestion des coûts éclairées.

Architecture de l'observabilité du réseau GKE

GKE Dataplane V2 propose une pile d'observabilité multicouche conçue pour différentes phases opérationnelles. Le tableau suivant présente les composants principaux et leurs cas d'utilisation recommandés :

Composant d'observabilité Cas d'utilisation principal Disponibilité Conservation des données Impact sur les performances Signaux de télémétrie clés
Métriques GKE Dataplane V2 Surveillance de l'état, analyse des tendances et alertes à l'échelle du système. GKE Dataplane V2 uniquement Rétention de la télémétrie historique (Cloud Monitoring et Google Cloud Managed Service pour Prometheus stockent les métriques et les journaux pendant 30 jours ou plus) Négligeable (agrégation au niveau du noyau) Compteurs de paquets et d'octets, nombre de réinitialisations TCP et taux d'abandon de connexion (pod_flow_drop_count).
Journaux NetworkPolicy Audit des règles de sécurité, analyse de l'historique des connexions et conformité. GKE Dataplane V2 uniquement (pour la configuration de la ressource personnalisée NetworkLogging) Configurable (Cloud Logging) Faible (exportation de journaux mis en mémoire tampon) Métadonnées de connexion (libellés source et de destination, adresses IP, ports) et verdicts de règles (ALLOW ou DENY).
CLI et UI Hubble Analyse interactive du trafic en direct et débogage au niveau des paquets en temps réel. GKE Dataplane V2 uniquement Éphémère (tampon circulaire local au nœud) Faible (activer de manière dynamique) Traces de flux en temps réel, motifs d'abandon détaillés (par exemple, refus de la règle ou saturation de la table conntrack).
Métriques DNS GKE Surveillance des performances de résolution DNS, de l'efficacité du cache et de la latence en amont. Tous les clusters Longue durée (Cloud Monitoring) Négligeable Nombre de requêtes DNS, ratio de succès et d'échecs du succès de cache (hit), latence de transfert en amont et refus de limite simultanée.
Tests de connectivité Validation du chemin d'accès avant le déploiement et audit de configuration statique. Tous les clusters Non applicable (simulation à la demande) Aucune (simulée de manière statique) Chemin de routage des paquets simulé, y compris l'évaluation simulée de NetworkPolicy.
Journaux de flux VPC Audit du trafic entre les nœuds et du trafic externe, investigation de la sécurité et analyse des coûts. Tous les clusters Configurable (Cloud Logging ou BigQuery) Aucun (taux d'échantillonnage configurable) Détails de la connexion à 5 éléments, octets et paquets envoyés, métadonnées GKE (espace de noms, charge de travail, service) et DAR (pour TCP).
Flow Analyzer Analyse visuelle du trafic VPC, identification des principaux émetteurs et analyse des coûts inter-zones sans écrire de requêtes SQL. Tous les clusters Dépend de la durée de conservation du bucket Observability Analytics Aucune (UI analytique) Volume de trafic et latence agrégés, regroupés par charge de travail ou service GKE.

Dans le tableau précédent, une surcharge de performances négligeable signifie que les composants restent strictement dans une empreinte de ressources minimale (généralement < 0,1 processeur virtuel et une mémoire minimale), quel que soit le volume de trafic ou l'échelle du système. Les composants Low maintiennent un encombrement minimal dans des conditions standards, mais évoluent de manière dynamique en fonction de la densité du trafic. Dans les scénarios à haut débit, l'utilisation des ressources peut atteindre deux processeurs virtuels et plusieurs centaines de mégaoctets de mémoire.

Modèle mental et boucle de triage de l'observabilité GKE

Pour résoudre efficacement les anomalies réseau, vous devez sélectionner le signal de télémétrie approprié pour votre champ d'application opérationnel et suivre une méthodologie de triage cohérente.

Choisir la bonne source de télémétrie

Plusieurs sources de télémétrie étant disponibles, choisissez l'outil qui correspond à votre tâche opérationnelle actuelle :

Source de télémétrie Réponses Idéal pour les cas suivants Google Cloud destination
Métriques GKE Dataplane V2 Que se passe-t-il et à quelle échelle ? Tableaux de bord, alertes et planification des capacités. Cloud Monitoring (prometheus.googleapis.com)
Journaux NetworkPolicy Pourquoi une connexion a-t-elle été bloquée dans GKE ? Analyse des causes premières des audits de sécurité et de la stratégie de sécurité. Cloud Logging (journal policy-action)
Journaux de flux VPC Qu'est-il advenu de ce trafic après qu'il a quitté le pod ? Analyse de l'historique du trafic entre les charges de travail, coûts de transfert de données interzones et attribution des pertes au niveau du VPC. Cloud Logging et Observability Analytics (journal vpc_flows)
CLI et UI Hubble Qu'est-ce qui transite par le nœud en ce moment ? Débogage en direct, alternative à tcpdump et incidents actifs. Buffer circulaire éphémère (CLI Hubble)
Tests de connectivité Le trafic peut-il transiter correctement ? Analyse active des chemins et sondage du plan de données : vérifiez l'accessibilité et identifiez les points de perte exacts dans les pare-feu VPC, les routes et les nœuds GKE. Network Intelligence Center (simulation)

Boucle de dépannage standardisée

Utilisez ce workflow reproductible pour trier tout incident lié à la mise en réseau GKE :

  1. Détecter une anomalie : identifiez le problème grâce aux alertes Cloud Monitoring (par exemple, les pics de réinitialisations TCP, les refus de limite simultanée DNS ou les pertes de paquets).
  2. Isoler le niveau : exécutez le test de référence de VM GCE (voir Triage pour la latence au niveau du nœud et les goulots d'étranglement CNI) pour déterminer si le blocage se trouve à l'intérieur du cluster GKE (CNI, NetworkPolicy, masquage d'adresses IP) ou à l'extérieur dans le VPC (règles de pare-feu, routage, Cloud NAT).
  3. Recherchez la cause racine : effectuez une analyse détaillée du flux :
    • Pour les incidents en direct : utilisez la CLI Hubble (hubble observe) pour diffuser des flux en temps réel et identifier les raisons des pertes de paquets.
    • Pour les problèmes historiques ou intermittents, interrogez les journaux NetworkPolicy ou les journaux de flux VPC dans Cloud Logging.
  4. Validez la correction : exécutez un test de connectivité simulé pour vérifier que le chemin est autorisé de manière statique, puis consultez le tableau de bord des métriques pour confirmer que le taux de perte est revenu à zéro.

Surveillance et alertes proactives concernant le réseau

Pour maintenir une haute disponibilité, les administrateurs de plate-forme doivent établir des règles d'alerte dans Cloud Monitoring afin d'identifier la dégradation du réseau avant qu'elle n'ait un impact sur les charges de travail.

Alerte en cas de pics de pertes de paquets

Une augmentation anormale des flux réseau abandonnés indique généralement une configuration incorrecte de la règle de sécurité ou une épuisement du suivi des connexions (conntrack) au niveau du nœud.

Alerte sur la saturation DNS

Lorsque CoreDNS ou NodeLocal DNSCache atteint sa limite de requêtes simultanées, les résolutions DNS suivantes sont refusées, ce qui entraîne des délais d'attente intermittents des applications.

  • Requête Prometheus (PromQL) :

    sum by (cluster_name) (rate(kubernetes_io_networking_dns_kubedns_max_concurrent_rejected_request_count[5m])) > 0

  • Action recommandée : mettez à l'échelle le nombre de répliques kube-dns ou implémentez NodeLocal DNSCache pour répartir la charge de résolution. Pour connaître la procédure détaillée, consultez Diagnostiquer les échecs de résolution DNS.

Alerte en cas de pics de réinitialisation TCP

Un pic de paquets de réinitialisation TCP indique souvent qu'un service de backend rejette les connexions, potentiellement en raison de boucles de plantage d'application ou de saturation de la file d'attente de sockets.

  • Langage MQL (Monitoring Query Language) :

    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], sum(val())
| condition val() > 50

  • Action recommandée : consultez Diagnostiquer le déséquilibre du trafic et les réinitialisations TCP pour examiner la persistance des connexions ou la saturation de la file d'attente des applications.

Validation automatisée des chemins d'accès dans CI/CD

Intégrez des tests de connectivité dans les pipelines de déploiement pour valider statiquement les chemins réseau avant le routage du trafic de production. Utilisez gcloud CLI pour vérifier que les charges de travail nouvellement déployées peuvent accéder aux dépendances externes (telles que les bases de données et les API) sans blocage de règles.

  • Exemple de commande :

    gcloud network-management connectivity-tests create test-prod-db-egress \
    --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/my-app-pod \
    --destination-ip-address=10.240.0.100 \
    --protocol=TCP \
    --destination-port=5432

Activer Observability Analytics pour l'analyse visuelle des flux

Pour activer l'analyse visuelle et sans SQL des flux de trafic VPC, mettez à niveau le bucket de journaux GKE (généralement le bucket _Default) pour utiliser Observability Analytics. Les administrateurs de plate-forme peuvent ainsi utiliser Flow Analyzer pour examiner la répartition du trafic et les coûts de transfert de données. Pour en savoir plus, consultez Analyser les coûts et les performances du trafic de cluster à l'aide de Flow Analyzer.

Automatisation Terraform : Observability-as-Code

Pour implémenter cette architecture d'observabilité de manière cohérente et éviter les erreurs de configuration manuelle, déployez le pipeline de télémétrie à l'aide de la configuration Terraform suivante (nécessite le fournisseur google-beta) :

# Configure the VPC Subnet with VPC Flow Logs enabled and all metadata included
resource "google_compute_subnetwork" "gke_subnet" {
  name          = "gke-subnet"
  ip_cidr_range = "10.0.0.0/20"
  region        = "us-central1"
  network       = google_compute_network.custom.id

  # Enable VPC Flow Logs. flow_sampling is the secondary sampling rate, which
  # applies to flow log entries after they are generated. The primary packet
  # sampling rate is dynamic and isn't configurable.
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.5 # Default rate; satisfies the LIGHT org policy tier
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# Configure GKE Cluster with Dataplane V2, Intranode Visibility, and Hubble
resource "google_container_cluster" "primary" {
  provider   = google-beta
  name       = "gke-observability-cluster"
  location   = "us-central1"
  network    = google_compute_network.custom.id
  subnetwork = google_compute_subnetwork.gke_subnet.id

  # Enable Dataplane V2 (Required for all advanced telemetry)
  datapath_provider = "ADVANCED_DATAPATH"

  # Enable Intranode Visibility (ensures local node pod-to-pod traffic hits the VPC)
  enable_intranode_visibility = true

  # Enable Managed Service for Prometheus (GMP)
  monitoring_config {
    enable_components = ["SYSTEM_COMPONENTS"]
    managed_prometheus {
      enabled = true
    }

    # Enable Dataplane V2 Flow Observability (Hubble Relay and metric exposure)
    advanced_datapath_observability_config {
      enable_metrics = true
      enable_relay   = true
    }
  }
}

# Upgrade the Default log bucket to use Log Analytics (required for Flow Analyzer)
resource "google_logging_project_bucket_config" "default_analytics" {
  project          = var.project_id
  location         = "global"
  bucket_id        = "_Default"
  enable_analytics = true
}

# Define a baseline static path validation test (Pod to external internet gateway)
resource "google_network_management_connectivity_test" "pod_to_internet" {
  name = "pod-to-internet-egress"
  source {
    gke_pod = "projects/${var.project_id}/locations/us-central1/clusters/${google_container_cluster.primary.name}/k8s/namespaces/prod/pods/my-app-pod"
  }
  destination {
    ip_address = "8.8.8.8"
    port       = 443
  }
  protocol = "TCP"
}

Optimisation des coûts et réduction du bruit

La télémétrie réseau (métriques et journaux) peut générer des volumes de données importants, ce qui entraîne des coûts d'ingestion et de stockage élevés. Utilisez les stratégies suivantes pour optimiser la collecte de données de télémétrie sans perdre en visibilité sur le trafic critique :

Désactiver les journaux des connexions autorisées

Par défaut, la journalisation NetworkPolicy enregistre les connexions autorisées et refusées. Les connexions autorisées représentent la majorité du volume de journaux (souvent 99% du trafic ou plus). Vous pouvez mettre à jour la configuration NetworkLogging du cluster pour n'enregistrer que les connexions refusées (supprimées), ce qui réduit considérablement les coûts de journalisation :

  1. Enregistrez le manifeste suivant sous le nom network-logging-config.yaml :

    apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: false # Disable logging for allowed traffic
      delegate: false
    deny:
      log: true  # Keep logging for blocked traffic (critical for security/triage)
      delegate: false

  2. Appliquez la configuration :

    kubectl apply -f network-logging-config.yaml

Déléguer la journalisation via des annotations

Pour un contrôle précis des coûts, déléguez la journalisation aux annotations en définissant delegate: true dans la ressource personnalisée NetworkLogging. Cette configuration garantit les éléments suivants :

  • Le trafic autorisé n'est consigné que si la NetworkPolicy correspondante comporte l'annotation policy.network.gke.io/enable-logging: "true".
  • Le trafic refusé n'est consigné que pour les objets de pod dans les espaces de noms annotés avec policy.network.gke.io/enable-deny-logging: "true".

Cette configuration vous permet d'activer la journalisation uniquement pour les charges de travail critiques (comme les passerelles de paiement), tout en ignorant les services bruyants et à faible risque.

Ajuster le taux d'échantillonnage des journaux de flux VPC

Dans votre configuration Terraform (ou dans la console Google Cloud ), diminuez le taux d'échantillonnage secondaire uniquement sur les sous-réseaux pour lesquels vous avez besoin d'agrégats de volume de trafic et de coût plutôt que d'enregistrements de flux individuels. Étant donné que les journaux de flux VPC estiment le trafic total à partir des paquets échantillonnés, le nombre d'octets et de paquets reste utilisable pour l'analyse des coûts à des taux inférieurs. Ne définissez pas le taux flow_sampling sur une valeur inférieure à 0.1, qui est le taux minimal qui satisfait le niveau ESSENTIAL de la règle d'administration constraints/compute.requireVpcFlowLogs :

resource "google_compute_subnetwork" "gke_subnet" {
  # ... other subnet configs ...
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.1 # ESSENTIAL tier: volume and cost analysis, not per-flow troubleshooting
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

Le tableau suivant récapitule les taux d'échantillonnage secondaires et les niveaux correspondants de la règle d'administration constraints/compute.requireVpcFlowLogs :

Taux d'échantillonnage secondaire Niveau de règle d'administration Quand utiliser cette fonctionnalité
1.0 COMPREHENSIVE Clusters avec une exigence permanente d'audit de sécurité ou d'investigation numérique par flux. Choisissez ce taux lorsque vous configurez le sous-réseau, car l'augmentation du taux après un incident ne permet pas de récupérer les flux qui n'ont jamais été capturés.
0.5 (par défaut) LIGHT Sous-réseaux qui sauvegardent les clusters pour lesquels vous résolvez les problèmes. Il s'agit du taux par défaut et de la référence recommandée.
0.1 ESSENTIAL Sous-réseaux pour lesquels vous avez besoin d'agrégats de volume de trafic et de coût plutôt que de flux individuels.

Appliquer des exclusions Cloud Logging

Excluez les journaux bruyants ou non pertinents (comme le trafic interne kube-system) directement au niveau du récepteur Cloud Logging. Ajoutez un filtre d'exclusion à votre récepteur _Default pour supprimer les métadonnées internes ou les journaux de pod système :

resource.type="gce_subnetwork" AND
log_name:"projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND
jsonPayload.src_gke_details.pod.pod_namespace="kube-system"

Bonnes pratiques et conseils opérationnels

Tenez compte des consignes opérationnelles suivantes lorsque vous déployez et gérez le pipeline de télémétrie de votre cluster :

  • Activez l'observabilité des flux GKE Dataplane V2 à la demande : l'observabilité des flux (hubble-relay) peut entraîner une légère surcharge. Pour les clusters de production, vous pouvez l'activer pendant les sessions de débogage et le désactiver ensuite pour minimiser la consommation de ressources sur les nœuds :

    gcloud container clusters update CLUSTER_NAME \
    --enable-dataplane-v2-flow-observability \
    --location=LOCATION

  • Activez la visibilité intranœud : par défaut, le trafic entre deux objets Pod sur le même nœud ne quitte pas le nœud, ce qui le rend invisible pour les journaux de flux VPC. La visibilité intranœud est activée par défaut dans les clusters Autopilot et désactivée par défaut dans les clusters Standard, y compris ceux qui utilisent GKE Dataplane V2. L'activation de la visibilité intranœud redirige ce trafic via le VPC et permet de s'assurer que les règles de pare-feu et les journaux de flux VPC s'appliquent de manière cohérente.

  • Comprendre le comportement de résolution des adresses IP virtuelles de service : une fois qu'une adresse IP virtuelle (VIP) de service Kubernetes est résolue en adresse IP de pod de backend, les métriques de la couche transport (couche 4 du modèle OSI) la comptabilisent comme du trafic de pod à pod. Pour identifier le VIP de service initialement ciblé, utilisez les flux en direct de la CLI Hubble lors de l'établissement de la connexion.

  • Alignez les codes temporels des métriques et des journaux : lorsque vous examinez un incident, mettez en corrélation le pic des métriques Cloud Monitoring avec la période exacte lorsque vous interrogez les journaux dans Cloud Logging ou l'interface de ligne de commande Hubble pour vous assurer d'analyser le même événement.

Étapes suivantes