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. Il traduit le modèle de mise en réseau Kubernetes abstrait en ressources concrètes et hautes performances, telles que les équilibreurs de charge mondiaux et la 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 devez repenser la conception du réseau. Avec Kubernetes, vous vous concentrez sur la façon dont les pods, les services et les clients externes communiquent, au lieu de gérer la mise en réseau des hôtes ou des machines virtuelles (VM) individuels. Cette abstraction simplifie le déploiement et le scaling 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 :

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

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

Couches et protocoles Mise en réseau

Pour comprendre comment les données transitent par un réseau, commencez par les couches réseau. GKE utilise de manière intensive des concepts issus des couches 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 la section Modèle OSI.

  • Couche transport : protocole TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol) : gère la communication de bout en bout entre les applications. Le protocole TCP (Transmission Control Protocol) permet une diffusion fiable, ordonnée et vérifiée, ce qui est essentiel pour la plupart du trafic applicatif. Le protocole UDP (User Datagram Protocol) 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 route les paquets sur différents réseaux. Chaque pod et nœud de GKE reçoit une adresse IP. Le routage des adresses IP détermine comment le trafic transite par votre cluster et votre réseau VPC.

  • Couche application : protocole HTTP (Hypertext Transfer Protocol) et DNS (Domain Name System) : c'est au niveau de cette couche que les applications interagissent avec le réseau. HTTP et HTTPS sont essentiels à la communication Web et sont couramment utilisés par les contrôleurs 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 service lisibles en adresses IP.

Adressage IP et notation CIDR

Vous devez comprendre l'adressage 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 dans votre réseau VPC Google Cloud. 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 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 dans le cluster. Vous devez être familiarisé avec les concepts et utilitaires fondamentaux de gestion de réseau Linux, 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 réseau Kubernetes

Le modèle de mise en réseau Kubernetes définit la manière dont les applications conteneurisées communiquent au sein d'un cluster. Contrairement aux modèles conventionnels qui se concentrent sur les machines virtuelles, Kubernetes met l'accent sur la communication entre pods et basée sur les services. Ce modèle rend la mise en réseau des applications plus prévisible en faisant abstraction du 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 de 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, constitue une base solide pour les applications conteneurisées modernes.

Principes clés du modèle de 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, à l'instar des machines virtuelles.

  • Communication de pod à pod 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 possible grâce aux clusters natifs au VPC, où les adresses IP des pods sont des adresses IP d'alias au sein de votre réseau VPC. Ces adresses IP alias permettent d'acheminer directement les pods au sein du VPC, ce qui élimine le besoin de traduction d'adresse réseau (NAT) et simplifie la communication entre les nœuds.

  • Les services fournissent des points de terminaison stables : comme les pods sont éphémères et peuvent ê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 (ClusterIP) et un nom DNS stables. Cette abstraction de problème permet un accès cohérent à un ensemble dynamique de pods.

  • Découverte des 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 de manière fiable d'autres services et communiquer avec eux.

  • L'é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 a lieu à la source, ce qui la rend très efficace et contribue à assurer une haute disponibilité.

En résumé, le modèle de réseau Kubernetes abstrait de nombreuses complexités réseau conventionnelles en un ensemble de primitives plus simples et plus puissantes pour les applications conteneurisées. En permettant la communication directe entre les pods, les points de terminaison de service stables, ainsi que l'équilibrage de charge et le DNS 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 la mise en réseau Kubernetes et l'infrastructure physique de Google Cloud :

  • Modèle de 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 de pod à pod 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 Google Cloud.

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

  • Plan de contrôle GKE : ces composants interagissent avecGoogle 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 aux composants Google Cloud tels que VPC, Cloud Load Balancing et Cloud Firewall pour fournir un environnement sécurisé et évolutif.

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

GKE s'appuie sur l'infrastructure réseau Google Cloud. GKE ne crée pas de couche réseau distincte. Il utilise plutôt les composants réseau Google Cloud existants. Par conséquent, il est essentiel de comprendre la mise en réseau Google Cloud pour concevoir et sécuriser vos clusters GKE.

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

  • 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 des adresses IP et éviter d'en manquer, vous devez avoir une bonne connaissance 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 équilibreurs de charge Google Cloud  : lorsque vous exposez des applications en dehors du cluster à l'aide d'un service LoadBalancer ou d'un objet Ingress, GKE provisionne un équilibreur de charge Google Cloud intégré. Un service LoadBalancer est généralement utilisé pour le trafic de couche 4, et un Ingress 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 en savoir plus, consultez la documentation 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 essentiel du cluster. Toutefois, pour sécuriser vos charges de travail, vous devez définir des 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 Cloud Next Generation Firewall.

Étapes suivantes