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 problèmes courants aux fonctionnalités et 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 s'adresse 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 connaissez déjà les problèmes 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 les 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 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 pour tenir 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 Gérer la migration d'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 type "zéro confiance" entre les pods.

Solution : utilisez des stratégies de pare-feu pour les périmètres de cluster. Pour en savoir plus, consultez 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, telles que des backends privés et des applications HTTP(S) publiques.

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

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

Scénario : vous devez résoudre des 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 dépanner le trafic réseau. Pour en savoir plus, consultez 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 entre pods

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 et un nom DNS stables, avec équilibrage de charge sur les pods. Pour en savoir plus, consultez 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 À propos des services LoadBalancer.

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 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 procéder comme suit :

  • 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 frontend et /api/v1 à la charge de travail de backend).
  • Sécurisez votre application avec HTTPS en gérant les certificats TLS.
  • Déployez de nouvelles fonctionnalités par étapes en toute sécurité à l'aide de versions Canary, qui vous permettent d'envoyer 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. Elle est compatible avec des fonctionnalités avancées telles que le routage basé sur le chemin d'accès, la mise en correspondance des en-têtes et la répartition du trafic. Pour en savoir plus, consultez À propos de l'API Gateway.

Cas d'utilisation : mise à l'échelle de la détection de services pour une application en pleine croissance

À mesure que le trafic et la complexité de votre application basée sur des microservices augmentent, 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'opérations sont souvent responsables de l'implémentation 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 entre les pods. Pour en savoir plus, consultez 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 Configurer NodeLocal DNSCache : présentation.

Défi : Fournir la détection de services dans le VPC

Scénario : les VM Compute Engine doivent accéder aux services du cluster.

Solution : intégrez Cloud DNS pour que les enregistrements DNS du service soient résolus dans l'ensemble du VPC. Pour en savoir plus, consultez 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 Zero Trust.

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

Scénario : seuls certains services doivent communiquer entre eux.

Solution : activez l'application des règles de réseau et appliquez les règles default deny, puis définissez des règles d'autorisation explicites (par exemple, le frontend autorise le trafic vers la facturation, la facturation autorise le trafic vers la base de données). Pour en savoir plus, consultez 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é exige une preuve de l'application et de la 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 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 être exposé à l'Internet public ni avoir à gérer les complexités de l'appairage de VPC.

Solution : utilisez Private Service Connect pour publier le service. Les clients 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 Exposer des services avec Private Service Connect.

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

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

Défi : Activer la communication entre clusters

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

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

Défi : Assurer un basculement résilient

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

Solution : MCS fournit détection de services tenant compte de l'état, ce qui permet aux clients de résoudre un seul nom DNS en un backend opérationnel 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'applications 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 Mise en réseau résident dans un projet hôte, mais les clusters d'applications s'exécutent dans des projets de service. Pour en savoir plus, consultez Configurer des clusters avec un VPC partagé.

Défi : Gérer efficacement un nombre limité d'adresses IP

Scénario : L'espace d'adresses 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 Gérer la migration d'adresses IP dans GKE.

Challenge : Utiliser un dataplane moderne et sécurisé, et provisionner des clusters avec le nouveau dataplane

Scénarios :

  • L'entreprise a besoin de performances élevées et d'une application des règles intégrée pour prendre en charge les charges de travail exigeantes et une posture de sécurité zéro confiance. Par exemple, vous pouvez exécuter des microservices à grande échelle sensibles à la latence du réseau, ou vous pouvez avoir besoin d'appliquer des limites de sécurité strictes entre les applications d'un cluster multitenant pour répondre aux exigences de conformité réglementaire.
  • Les clusters doivent être configurés pour utiliser un plan de données réseau moderne afin d'assurer des performances et une sécurité élevées. Ils doivent également ê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 ainsi qu'une application intégrée des règles de réseau. Pour en savoir plus, consultez GKE Dataplane V2.

Cas d'utilisation : observer et résoudre les problèmes de trafic

En tant qu'ingénieur SRE, vous cherchez à comprendre 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 : des paquets sont supprimés, mais la cause n'est pas claire.

Solution : activez l'observabilité GKE Dataplane V2. Des métriques telles que hubble_drop_total confirment que les paquets sont refusés. Pour en savoir plus, consultez Dépanner avec Hubble.

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

Scénario : après avoir confirmé que des paquets réseau sont abandonné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 tracer 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 du problème et de corriger le règlement. Pour en savoir plus, consultez Observer votre trafic à l'aide de l'observabilité GKE Dataplane V2.

Cas d'utilisation de bout en bout : déployer et mettre à l'échelle 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 et l'amélioration des performances pour les charges de travail de machine learning, ainsi que 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 du VPC partagé et de GKE Dataplane V2.
  • Phase 2 : exposez l'application à l'aide de l'API Gateway et des services multiclusters pour une haute disponibilité.
  • Phase 3 : accélérez les tâches de ML à l'aide de gVNIC et du réseau de niveau 1.
  • Phase 4 : déployez des appliances de sécurité avancées en utilisant la compatibilité multi-réseaux.
Schéma illustrant l'architecture de bout en bout d'une application de vente au détail sécurisée à plusieurs niveaux sur GKE, illustrant 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 réseau utilisés dans chaque phase de déploiement et de scaling. Les détails de chaque phase sont décrits dans les sections suivantes.

Phase 1 : Établir les bases de la plate-forme

Défi : centraliser la mise en réseau pour plusieurs équipes d'applications 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 entre les services et appliquer une sécurité "zéro confiance".

Solution :

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

Phase 3 : Exposer l'application et la faire évoluer pour la croissance

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 la haute disponibilité et résoudre les problèmes

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

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 un trafic de plan de gestion et de données distinct à très faible latence.

Solution :

Étapes suivantes