Apprendre les bases de la mise en réseau GKE

La mise en réseau Google Kubernetes Engine (GKE) fournit une base puissante, évolutive et sécurisée pour vos applications conteneurisées, basée sur le VPC mondial de Google. Elle traduit le modèle de mise en réseau Kubernetes abstrait en ressources concrètes et hautes performances, telles que des équilibreurs de charge mondiaux et une mise en réseau de VM à haut débit.

Ce document et le reste de cette documentation s'adressent aux architectes cloud et aux spécialistes de la mise en réseau qui conçoivent l'architecture réseau de leur organisation.

Pourquoi la mise en réseau Kubernetes est-elle différente ?

Lorsque vous utilisez Kubernetes pour orchestrer vos applications, vous pensez différemment à la conception du réseau. Avec Kubernetes, vous vous concentrez sur la façon dont les pods, les services et les clients externes communiquent, plutôt que sur la gestion de la mise en réseau d'un hôte ou d'une machine virtuelle (VM) individuelle. Cette abstraction simplifie le déploiement et la mise à l'échelle des applications en éliminant les complexités telles que le mappage manuel des ports.

Prérequis

Avant de découvrir la mise en réseau dans GKE, vous devez comprendre les points suivants :

  • Concepts clés de la mise en réseau générale, Google Cloud, et de Kubernetes
  • Consultez la page Premiers pas avec GKE.

Principes de base de la mise en réseau et Google Cloud

GKE s'appuie sur des principes de mise en réseau standards. Pour comprendre comment GKE gère et achemine le trafic au sein des clusters et entre eux, vous devez connaître les concepts de mise en réseau de base suivants.

Couches et protocoles de mise en réseau

Pour comprendre comment les données transitent par un réseau, commencez par les couches de mise en réseau. GKE utilise de manière intensive des concepts issus des couches de transport, Internet et application de la pile réseau. Vous devez connaître leurs fonctions de base et les protocoles courants tels que HTTP, DNS et la suite TCP/IP. Pour en savoir plus, consultez le modèle OSI.

  • Couche transport : protocole TCP (TCP) ou protocole de datagramme utilisateur (UDP) : gère la communication de bout en bout entre les applications. Protocole TCP (TCP) assure une livraison fiable, ordonnée et vérifiée, ce qui est essentiel pour la plupart du trafic applicatif. Le protocole de datagramme utilisateur (UDP) offre une communication plus rapide et sans connexion, souvent utilisée pour le streaming ou les jeux. GKE utilise les deux protocoles pour la communication entre les pods et les services.

  • Couche Internet : protocole Internet (IP) : adresse et achemine les paquets sur différents réseaux. Chaque pod et chaque nœud de GKE reçoit une adresse IP, et le routage des adresses IP détermine comment le trafic circule dans votre cluster et votre réseau VPC.

  • Couche application : protocole de transfert hypertexte (HTTP) et système de noms de domaine (DNS) : cette couche est celle où les applications interagissent avec le réseau. HTTP et HTTPS sont essentiels à la communication Web et sont couramment utilisés par les contrôleurs d'Ingress et les équilibreurs de charge pour exposer les applications. Le DNS est essentiel pour la détection de services dans Kubernetes, car il traduit les noms de services lisibles par l'homme en adresses IP.

Attribution d'adresses IP et notation CIDR

Vous devez comprendre l'attribution d'adresses IP et la notation CIDR (Classless Inter-Domain Routing) car le modèle de mise en réseau Kubernetes utilise intensivement les adresses IP pour la communication entre tous ses composants. Le CIDR est essentiel pour planifier l'allocation d'adresses IP de votre cluster's au sein de votre Google Cloud réseau VPC. Il vous permet de définir des blocs d'adresses IP pour les pods, les services et les nœuds. Par exemple, l'allocation de 10.10.0.0/16 pour vos pods réserve 65 536 adresses IP. Une planification CIDR appropriée permet d'éviter les situations où vous manquez d'adresses IP à mesure que votre cluster évolue.

Utilitaires de mise en réseau Linux

GKE utilise les fonctionnalités sous-jacentes du noyau Linux pour implémenter le routage du trafic et l'équilibrage de charge au sein du cluster. Vous devez connaître les concepts et utilitaires de gestion de réseau Linux de base, tels que les tables de routage et iptables. Traditionnellement, kube-proxy, un composant Kubernetes clé sur chaque nœud, programme ces utilitaires pour intercepter le trafic destiné à un service et le rediriger vers l'un des pods de backend. Les clusters GKE modernes qui utilisent GKE Dataplane V2 remplacent iptables par eBPF pour améliorer les performances et l'observabilité.

Comprendre le modèle de mise en réseau Kubernetes

Le modèle de mise en réseau Kubernetes définit la façon dont les applications conteneurisées communiquent au sein d'un cluster. Contrairement aux modèles conventionnels axés sur les machines virtuelles, Kubernetes met l'accent sur la communication entre les pods et basée sur les services. Ce modèle rend la mise en réseau des applications plus prévisible en éliminant le manque de fiabilité des adresses IP dynamiques des pods. Les pods étant éphémères et pouvant être recréés à tout moment avec une nouvelle adresse IP, la communication directe avec les adresses IP des pods est intrinsèquement instable. Kubernetes résout ce problème en regroupant les pods dans un service. Un service fournit une adresse IP virtuelle stable (ClusterIP) et un nom DNS cohérent, auxquels les applications peuvent se connecter de manière fiable. Ce point de terminaison stable, combiné à un réseau plat qui permet à tous les pods de communiquer directement sans avoir besoin de NAT, crée une base solide pour les applications conteneurisées modernes.

Principes clés du modèle de mise en réseau Kubernetes

  • Chaque pod possède une adresse IP unique : chaque pod d'un cluster Kubernetes reçoit sa propre adresse IP, qui est partagée par tous les conteneurs de ce pod. Cette adresse IP unique permet aux pods d'agir comme des hôtes individuels sur le réseau, semblables à des machines virtuelles.

  • Communication plate entre les pods sans NAT : tous les pods peuvent communiquer directement entre eux à l'aide de leurs adresses IP, quel que soit le nœud sur lequel ils s'exécutent. Dans GKE, cette communication directe est obtenue à l'aide de clusters VPC natifs, où les adresses IP des pods sont des adresses IP d'alias au sein de votre réseau VPC. Ces adresses IP d'alias rendent les pods directement routables au sein du VPC, ce qui élimine le besoin de traduction d'adresses réseau (NAT) et simplifie la communication entre les nœuds.

  • Les services fournissent des points de terminaison stables : les pods étant éphémères et pouvant être recréés à tout moment avec de nouvelles adresses IP, la communication directe avec les adresses IP des pods n'est pas fiable. Les services Kubernetes résolvent ce problème en regroupant un ensemble de pods et en exposant une adresse IP stable (ClusterIP) et un nom DNS. Cette abstraction de problème permet un accès cohérent à un ensemble dynamique de pods.

  • Découverte de services intégrée avec DNS : Kubernetes inclut un service DNS intégré qui attribue automatiquement des noms DNS aux services. Les applications peuvent utiliser ces noms (par exemple, my-service.my-namespace.svc.cluster.local) pour localiser et communiquer de manière fiable avec d'autres services.

  • Équilibrage de charge intégré : lorsque les clients envoient du trafic à l'adresse ClusterIP d'un service, les règles de mise en réseau sur le nœud (programmées par kube-proxy ou GKE Dataplane V2) interceptent le trafic et l'équilibrent sur tous les pods sains de ce service. Cette distribution se produit à la source, ce qui la rend très efficace et contribue à garantir une haute disponibilité.

En résumé, le modèle de mise en réseau Kubernetes abstrait de nombreuses complexités réseau conventionnelles en un ensemble de primitives plus simple et plus puissant pour les applications conteneurisées. En permettant la communication directe entre les pods, les points de terminaison de service stables, ainsi que le DNS et l'équilibrage de charge intégrés, il fournit une base robuste et évolutive pour les applications conteneurisées modernes.

Relation entre GKE et Google Cloud

La mise en réseau GKE sert de pont entre le modèle conceptuel de mise en réseau Kubernetes et l'infrastructure physique de Google Cloud:

  • Modèle de mise en réseau Kubernetes : Kubernetes définit des règles selon lesquelles chaque pod reçoit sa propre adresse IP, ce qui permet une communication directe entre les pods sans avoir besoin de NAT.

  • Google Cloud Mise en réseau : il s'agit de l'infrastructure sous-jacente , y compris le VPC, les sous-réseaux, les pare-feu et les équilibreurs de charge.

  • Mise en réseau GKE : cette couche de connexion implémente le modèle Kubernetes à l'aide de l'infrastructure de Google Cloud.

  • Interface CNI (Container Network Interface): GKE utilise un plug-in CNI sur chaque nœud pour gérer l'allocation d'adresses IP des pods et connecter les pods au réseau du nœud.

  • Plan de contrôle GKE : ces composants interagissent avec Google Cloud pour configurer automatiquement les routes VPC pour les plages d'adresses IP des pods, gérer les règles de pare-feu et provisionner les équilibreurs de charge en fonction de vos déploiements Kubernetes.

Le schéma suivant illustre le flux de trafic entrant et sortant vers et depuis les clusters GKE qui se trouvent dans un VPC et derrière un pare-feu cloud. Le trafic Ingress inclut le trafic à charge équilibrée provenant de composants tels que le proxy SSL, le proxy TCP ou l'équilibrage de charge HTTP(S). Le trafic sortant inclut des destinations telles que les réseaux externes, les utilisateurs et l'équilibrage de charge proxy TCP.
Figure 1. La mise en réseau GKE s'intègre à Google Cloud des composants tels que VPC, Cloud Load Balancing, et Cloud Firewall pour fournir un environnement sécurisé et évolutif.

Pourquoi les connaissances en mise en réseau sont-elles essentielles pour GKE ? Google Cloud

GKE s'appuie sur Google Cloud une infrastructure de mise en réseau. GKE ne crée pas de couche réseau distincte . Au lieu de cela, il utilise des composants de mise en réseau existants Google Cloud . Par conséquent, la compréhension de la mise en réseau est essentielle pour concevoir et sécuriser vos clusters GKE. Google Cloud

Voici pourquoi Google Cloud les principes fondamentaux de la mise en réseau sont importants :

  • Votre cluster s'exécute dans un VPC : chaque cluster GKE fonctionne dans un VPC. Toutes les adresses IP (pour les nœuds, les pods et les services) proviennent des plages d'adresses IP définies dans vos sous-réseaux VPC. Pour allouer correctement les adresses IP et éviter d'en manquer, vous devez avoir une connaissance pratique de la conception de VPC et de sous-réseaux. Pour en savoir plus, consultez la documentation sur le VPC.

  • L'exposition des applications utilise des Google Cloud équilibreurs de charge : lorsque vous exposez des applications en dehors du cluster à l'aide d'un service LoadBalancer ou d'un objet Ingress, GKE provisionne un Google Cloud équilibreur de charge intégré. Un service LoadBalancer est généralement utilisé pour le trafic de couche 4, et un objet Ingress est utilisé pour le trafic HTTP(S) de couche 7. Comprendre le fonctionnement de ces équilibreurs de charge vous aide à gérer le trafic externe, à configurer des vérifications d'état et à résoudre efficacement les problèmes de connectivité. Pour plus d'informations, reportez-vous à la documentation sur Cloud Load Balancing.

  • La sécurité est appliquée par le biais de Google Cloud règles de pare-feu: GKE crée automatiquement certaines règles de pare-feu pour autoriser le trafic de cluster essentiel. Toutefois, la sécurisation de vos charges de travail nécessite la définition de règles de pare-feu VPC personnalisées. Les erreurs de configuration peuvent bloquer le trafic critique. Il est donc important de comprendre le fonctionnement de ces règles. Pour en savoir plus, consultez la documentation sur le pare-feu Cloud nouvelle génération.

Étape suivante