Explorer la documentation et les cas d'utilisation de la mise en réseau GKE

La mise en réseau dans Google Kubernetes Engine (GKE) couvre un large éventail de concepts, y compris les pods, les services, le DNS, l'équilibrage de charge, la sécurité et la gestion des adresses IP. Bien que la documentation explique chaque fonctionnalité en détail, il peut être difficile de savoir par où commencer face à un problème concret.

Ce document vous aide à parcourir la documentation sur la mise en réseau GKE en associant les défis courants aux fonctionnalités et aux sections qui les résolvent. Chaque cas d'utilisation présente un scénario, identifie le défi et vous renvoie à la documentation pertinente. Ce document est destiné aux architectes cloud, aux développeurs et aux équipes d'exploitation qui doivent comprendre et résoudre les problèmes de mise en réseau courants dans GKE.

Si vous êtes déjà familiarisé avec les défis de mise en réseau courants et que vous préférez vous plonger directement dans les détails techniques, explorez les ressources suivantes pour acquérir des connaissances de base sur la mise en réseau GKE :

Cas d'utilisation : concevoir les bases du réseau pour GKE

Dans ce cas d'utilisation, vous êtes un architecte cloud qui doit concevoir une base de réseau évolutive, sécurisée et fiable pour une nouvelle plate-forme GKE.

Défi : éviter l'épuisement des adresses IP

Scénario : la complexité et l'utilisation de votre application devraient augmenter. Vous devez donc concevoir un réseau capable de s'adapter à l'augmentation du trafic et de prendre en charge la croissance des pods, des services et des nœuds. Vous devez également planifier l'allocation de vos adresses IP pour éviter l'épuisement.

Solution : planifiez votre schéma d'adressage IP en tenant compte du nombre de nœuds, de pods et de services dont vous aurez besoin. Ce plan inclut le choix des plages d'adresses IP appropriées pour chacun, en tenant compte de la densité des pods et en évitant les chevauchements avec d'autres réseaux. Pour en savoir plus, consultez la section Gérer la migration des adresses IP dans GKE.

Défi : appliquer une sécurité de défense en profondeur

Scénario : vous devez sécuriser les périmètres de votre cluster et appliquer des règles de confiance zéro de pod à pod.

Solution : utilisez des règles de pare-feu pour les périmètres de cluster. Pour en savoir plus, consultez la section Contrôler la communication entre les pods et les services à l'aide de règles de réseau.

Défi : acheminer le trafic vers différents types d'applications

Scénario : vous devez vous assurer que d'autres services et utilisateurs peuvent accéder à différents types d'applications, tels que les backends privés et les applications HTTP(S) publiques.

Solution : utilisez des équilibreurs de charge internes pour les backends privés. Pour les applications HTTP(S) publiques, utilisez l'API Ingress ou Gateway. Pour en savoir plus, consultez la section À propos de l'équilibrage de charge dans GKE.

Défi : utiliser des outils d'observabilité pour surveiller et résoudre les problèmes liés aux charges de travail

Scénario : vous devez résoudre les problèmes liés au trafic réseau, et comprendre et surveiller les flux de trafic GKE pour diagnostiquer efficacement les problèmes.

Solution : implémentez des outils d'observabilité pour surveiller et résoudre les problèmes liés au trafic réseau. Pour en savoir plus, consultez la section Observer votre trafic à l'aide de l'observabilité GKE Dataplane V2.

Cas d'utilisation : exposer un nouveau microservice

Dans ce cas d'utilisation, vous êtes un développeur qui déploie un nouveau microservice dans GKE. Vous devez rendre le microservice accessible aux autres services du cluster, puis aux clients externes.

Défi : fournir un point de terminaison stable pour la communication de pod à pod

Scénario : votre application a besoin que les pods communiquent entre eux, mais les adresses IP dynamiques utilisées par les pods rendent cette communication peu fiable.

Solution : créez un service Kubernetes. Un service ClusterIP fournit une adresse IP virtuelle stable et un nom DNS, équilibrés entre les pods. Pour en savoir plus, consultez la section Comprendre les services Kubernetes.

Défi : exposer le service pour un accès externe

Scénario : le microservice doit être accessible depuis Internet pour une démonstration.

Solution : créez un service LoadBalancer. GKE provisionne un équilibreur de charge réseau passthrough externe régional avec une adresse IP publique. Pour le trafic HTTP(S), envisagez d'utiliser Ingress ou Gateway, qui fournissent des fonctionnalités de couche 7. Pour en savoir plus, consultez la section À propos des services LoadBalancer Services.

Défi : attribuer une URL permanente et conviviale

Scénario : le service a besoin d'un nom de domaine stable pour les clients.

Solution : réservez une adresse IP statique et configurez le DNS pour un domaine personnalisé. Pour en savoir plus, consultez la section Configurer des noms de domaine avec des adresses IP statiques.

Défi : gérer le routage avancé du trafic

Scénario : à mesure que votre application se développe, vous avez besoin d'un contrôle plus sophistiqué sur la façon dont le trafic est acheminé. Par exemple, vous devrez peut-être effectuer les opérations suivantes :

  • Hébergez plusieurs sites Web (comme api.example.com et shop.example.com) sur un seul équilibreur de charge pour réduire les coûts.
  • Acheminez les requêtes vers différents services en fonction du chemin d'URL (par exemple, en envoyant / à la charge de travail de l'interface et /api/v1 à la charge de travail du backend).
  • Sécurisez votre application avec HTTPS en gérant les certificats TLS.
  • Déployez en toute sécurité de nouvelles fonctionnalités par étapes à l'aide de versions Canary, où vous envoyez une petite partie du trafic vers une nouvelle version avant un déploiement complet.

Solution : utilisez l'API Gateway. L'implémentation de l'API Gateway par GKE fournit un moyen puissant et standardisé de gérer ce type de trafic nord-sud, en prenant en charge des fonctionnalités avancées telles que le routage basé sur le chemin, la correspondance des en-têtes et la répartition du trafic. Pour en savoir plus, consultez la section À propos de l'API Gateway.

Cas d'utilisation : faire évoluer la détection de services pour une application en pleine croissance

À mesure que votre application basée sur des microservices augmente en trafic et en complexité, les requêtes DNS entre les services augmentent considérablement. Bien que les développeurs doivent comprendre comment créer des applications résilientes dans cet environnement, les équipes de plate-forme et d'exploitation sont souvent responsables de la mise en œuvre de solutions de mise en réseau évolutives.

Défi : activer la communication de service à service

Scénario : les pods ont besoin d'un moyen fiable de localiser d'autres services.

Solution : GKE fournit un service DNS dans le cluster (tel que kube-dns ou Cloud DNS) qui résout les noms DNS stables pour les services, ce qui permet une communication fiable de pod à pod. Pour en savoir plus, consultez la section Découverte des services et DNS.

Défi : améliorer les performances DNS à grande échelle

Scénario : un volume de requêtes élevé entraîne des retards de recherche.

Solution : activez NodeLocal DNSCache. Chaque nœud met en cache les requêtes DNS localement, ce qui réduit la latence. Pour en savoir plus, consultez la section Présentation de la configuration de NodeLocal DNSCache.

Défi : fournir la détection de services sur l'ensemble du VPC

Scénario : les VM Compute Engine doivent accéder aux services à l'intérieur du cluster.

Solution : intégrez-vous à Cloud DNS afin que les enregistrements DNS du service soient résolus sur l'ensemble du VPC. Pour en savoir plus, consultez la section Utiliser Cloud DNS pour GKE.

Cas d'utilisation : sécuriser une application à plusieurs niveaux

Dans ce cas d'utilisation, vous faites partie d'une équipe d'ingénierie de plate-forme qui déploie une application à trois niveaux (interface, facturation, base de données) et vous devez appliquer une communication de confiance zéro.

Défi : appliquer des règles de trafic strictes

Scénario : seuls des services spécifiques doivent communiquer entre eux.

Solution : activez l'application des règles de réseau et appliquez des règles default deny, puis définissez des règles d'autorisation explicites (par exemple, l'interface autorise le trafic vers la facturation, la facturation autorise le trafic vers la base de données). Pour en savoir plus, consultez la section Configurer des règles de réseau pour les applications.

Défi : auditer et vérifier les règles de réseau

Scénario : la sécurité nécessite une preuve d'application et de visibilité.

Solution : activez la journalisation des règles de réseau pour enregistrer les connexions autorisées et refusées. Pour en savoir plus, consultez la section Utiliser la journalisation des règles de réseau.

Défi : exposer un service de manière privée aux consommateurs

Scénario : un service de backend, tel qu'une base de données ou une API, doit être accessible aux consommateurs d'autres réseaux VPC sans l'exposer à l'Internet public ni gérer les complexités de l'appairage VPC.

Solution : utilisez Private Service Connect pour publier le service. Les consommateurs peuvent ensuite créer un point de terminaison PSC dans leur propre VPC pour accéder à votre service de manière privée et sécurisée. Pour en savoir plus, consultez la section Exposer des services avec Private Service Connect.

Cas d'utilisation : assurer une haute disponibilité sur plusieurs clusters

Dans ce cas d'utilisation, vous êtes un SRE qui exécute des charges de travail pour une entreprise de commerce électronique dans plusieurs clusters GKE de différentes régions afin d'améliorer la fiabilité.

Défi : activer la communication interclusters

Scénario : les services d'un cluster doivent découvrir et appeler les services d'un autre cluster.

Solution : utilisez les services multiclusters GKE pour créer un nom DNS global et acheminer automatiquement le trafic vers des backends sains. Pour en savoir plus, consultez la section Services multiclusters.

Défi : assurer un basculement résilient

Scénario : si un service régional devient indisponible, le trafic doit être redirigé automatiquement.

Solution : les services multiclusters fournissent détection de services tenant compte de l'état de santé, ce qui permet aux clients de résoudre un seul nom DNS en un backend sain dans le cluster disponible le plus proche. Cette approche permet un basculement résilient. Pour en savoir plus, consultez la section Services multiclusters.

Cas d'utilisation : créer un environnement GKE mutualisé sécurisé et efficace

En tant que membre d'une équipe d'ingénierie de plate-forme, vous fournissez des clusters GKE à plusieurs équipes d'application. Vous devez centraliser le contrôle du réseau, économiser les adresses IP et appliquer une sécurité stricte.

Défi : centraliser le contrôle du réseau

Scénario : plusieurs équipes d'application ont besoin de leurs propres clusters, mais la mise en réseau doit être gérée de manière centralisée.

Solution : utilisez un VPC partagé. Les ressources de mise en réseau résident dans un projet hôte, mais les clusters d'application s'exécutent dans des projets de service. Pour en savoir plus, consultez la section Configurer des clusters avec un VPC partagé.

Défi : gérer efficacement les adresses IP limitées

Scénario : l'espace d'adressage IP est limité et doit être utilisé efficacement.

Solution : ajustez le nombre maximal de pods par nœud et, si nécessaire, utilisez des plages non RFC 1918 pour les adresses IP des pods. Pour en savoir plus, consultez la section Gérer la migration des adresses IP dans GKE.

Défi : utiliser un plan de données moderne et sécurisé, et provisionner des clusters avec le nouveau plan de données

Scénarios :

  • L'entreprise nécessite des performances élevées et une application de règles intégrée pour prendre en charge les charges de travail exigeantes et une stratégie de sécurité de confiance zéro. Par exemple, vous pouvez exécuter des microservices à grande échelle sensibles à la latence du réseau, ou vous devrez peut-être appliquer des limites de sécurité strictes entre les applications d'un cluster mutualisé pour répondre aux exigences de conformité réglementaire.
  • Les clusters doivent être configurés pour utiliser un plan de données de mise en réseau moderne pour des performances et une sécurité élevées, et ils doivent être déployés dans la structure de réseau gérée de manière centralisée de l'organisation.

Solution : utilisez GKE Dataplane V2, qui est basé sur eBPF et offre des performances élevées et une application de règles de réseau intégrée. Pour en savoir plus, consultez la section GKE Dataplane V2.

Cas d'utilisation : observer et résoudre les problèmes liés au trafic

En tant que SRE, vous recherchez pourquoi un service de paiement ne peut pas se connecter à un service de paiement.

Défi : résoudre les problèmes de connectivité

Scénario : les paquets sont supprimés, mais la cause n'est pas claire.

Solution : activez l'observabilité GKE Dataplane V2. Les métriques telles que hubble_drop_total confirment que les paquets sont refusés. Pour en savoir plus, consultez la section Résoudre les problèmes avec Hubble.

Défi : identifier la cause première des paquets supprimés

Scénario : après avoir confirmé que les paquets réseau sont supprimés (par exemple, à l'aide de hubble_drop_total), identifiez la règle de réseau spécifique qui bloque le trafic entre les services.

Solution : utilisez l'interface de ligne de commande ou l'interface utilisateur Hubble pour suivre les flux. L'interface utilisateur Hubble fournit une représentation visuelle du trafic, en mettant en évidence la règle mal configurée exacte qui refuse la connexion. Cette visualisation permet à l'équipe d'identifier rapidement la cause première du problème et de corriger la règle. Pour en savoir plus, consultez la section Observer votre trafic à l'aide de l'observabilité GKE Dataplane V2.

Cas d'utilisation de bout en bout : déployer et faire évoluer une application de vente au détail sécurisée

Dans ce scénario de bout en bout, une équipe d'ingénierie de plate-forme crée une plate-forme GKE standardisée pour plusieurs équipes d'application. L'équipe déploie et optimise une application de vente au détail à trois niveaux (interface, facturation, base de données). Ce processus inclut la sécurisation, la mise à l'échelle, l'amélioration des performances pour les charges de travail de machine learning et l'intégration d'appliances de sécurité avancées.

Le schéma suivant illustre l'architecture de bout en bout d'une application de vente au détail sécurisée à plusieurs niveaux déployée sur GKE. L'architecture évolue en plusieurs phases :

  • Phase 1 : créez une configuration de base à l'aide d'un VPC partagé et de GKE Dataplane V2.
  • Phase 2 : exposez l'application à l'aide de l'API Gateway et de services multiclusters pour une haute disponibilité.
  • Phase 3 : accélérez les tâches de ML à l'aide de gVNIC et de la mise en réseau de niveau 1.
  • Phase 4 : déployez des appliances de sécurité avancées à l'aide de la compatibilité multiréseau.
Diagramme illustrant l'architecture de bout en bout d'une application de vente au détail sécurisée à plusieurs niveaux sur GKE, montrant les composants réseau au cours des six phases de déploiement et de scaling.
Figure 1. Architecture de bout en bout pour une application de vente au détail sécurisée à plusieurs niveaux sur GKE, mettant en évidence les principaux composants de mise en réseau utilisés dans chaque phase de déploiement et de mise à l'échelle. Les détails de chaque phase sont décrits dans les sections suivantes.

Phase 1 : créer les bases de la plate-forme

Défi : centraliser la mise en réseau pour plusieurs équipes d'application et allouer suffisamment d'adresses IP pour gérer la mise à l'échelle.

Solution :

Phase 2 : déployer et sécuriser l'application

Défi : assurer une communication fiable de service à service et appliquer une sécurité de confiance zéro.

Solution :

  • Créez des services ClusterIP pour des points de terminaison internes stables.
  • Appliquez des règles de réseau avec une base de référence de refus par défaut et des règles d'autorisation explicites.

Phase 3 : exposer l'application et la faire évoluer

Défi : fournir un accès externe et réduire la latence de résolution DNS à mesure que le trafic augmente.

Solution :

Phase 4 : assurer une haute disponibilité et résoudre les problèmes

Défi : assurer le basculement régional et déboguer le trafic supprimé.

Solution :

Phase 5 : accélérer les charges de travail de machine learning

Défi : éliminer les goulots d'étranglement du réseau pour l'entraînement de modèles basés sur GPU.

Solution :

Phase 6 : déployer des appliances de sécurité avancées

Défi : déployer un pare-feu et un IDS tiers avec une gestion et un trafic de plan de données distincts à une latence ultra-faible.

Solution :

Étape suivante