Comprendre l'adressage IP dans GKE

Pour créer des clusters Google Kubernetes Engine (GKE) évolutifs et sécurisés, vous devez gérer efficacement l'adressage IP. Ce document vous offre une vue d'ensemble complète de la façon dont GKE utilise les adresses IP pour la communication des clusters, des modèles de mise en réseau compatibles et des bonnes pratiques pour une gestion efficace des adresses IP.

Ce document s'adresse aux architectes cloud et aux spécialistes de la mise en réseau qui conçoivent et implémentent le réseau pour leur organisation. Pour en savoir plus sur les rôles courants et les exemples de tâches dans Google Cloud, consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avant de continuer, assurez-vous de bien comprendre les concepts suivants :

Comment les adresses IP connectent les composants GKE

GKE s'appuie sur le modèle de mise en réseau Kubernetes, qui exige que chaque composant dispose d'une adresse IP distincte pour communiquer. Les sections suivantes décrivent comment GKE attribue et utilise les adresses IP pour les composants principaux du cluster :

  • Nœuds : GKE attribue à chaque nœud, qui est une instance de VM Compute Engine, une adresse IP interne à partir de la plage d'adresses IP principale du sous-réseau associé à son pool de nœuds. Cette adresse IP permet la communication entre le nœud et le plan de contrôle Kubernetes. Les nœuds peuvent également disposer d'une adresse IP externe pour l'accès Internet sortant.

  • Pods : en suivant le modèle Kubernetes "une adresse IP par pod", GKE attribue à chaque pod une adresse IP unique à partir d'une plage CIDR de pods allouée au nœud. Dans GKE, le réseau VPC achemine en mode natif les adresses IP des pods. Cette capacité de routage intégrée permet une communication directe entre les pods, même sur différents nœuds, sans nécessiter de traduction d'adresse réseau (NAT). Tous les conteneurs d'un même pod partagent la même adresse IP et peuvent communiquer sur localhost.

  • Services : GKE attribue à chaque service Kubernetes une adresse IP virtuelle stable (ClusterIP) à partir d'une plage d'adresses IP secondaires dédiée. Ce ClusterIP fournit un point de terminaison unique et fiable pour un groupe de pods. Lorsque vous envoyez du trafic à ClusterIP, GKE l'équilibre automatiquement vers un pod sain de ce service.

  • Plan de contrôle : dans les clusters privés, le plan de contrôle réside dans un projet locataire géré par Google et utilise sa propre plage d'adresses IP internes. Ce projet locataire se connecte à votre réseau VPC, ce qui permet une communication sécurisée entre le plan de contrôle et les nœuds du réseau VPC de votre cluster. Cette connexion utilise généralement Private Service Connect.

  • Équilibreurs de charge : pour exposer des applications sur Internet ou au sein de votre réseau VPC, vous pouvez configurer GKE pour qu'il utilise des équilibreurs de chargeGoogle Cloud . Les équilibreurs de charge externes utilisent des adresses IP publiques. Les équilibreurs de charge internes utilisent des adresses IP internes de la plage de sous-réseau principale de votre réseau VPC.

Le tableau suivant récapitule la façon dont GKE attribue des adresses IP aux composants du cluster :

Composant Comment les adresses IP sont-elles attribuées ?
Nœud GKE attribue une adresse IP interne à chaque nœud. GKE attribue cette adresse IP à partir de la plage d'adresses IP principale du sous-réseau associé au pool de nœuds du nœud. Il peut s'agir du sous-réseau par défaut du cluster ou d'un sous-réseau supplémentaire.
Pod GKE attribue à chaque pod une adresse IP unique à partir de la plage CIDR de pods allouée à son nœud.
Service (ClusterIP) GKE attribue à chaque service une adresse IP virtuelle stable (ClusterIP) à partir d'une plage d'adresses IP secondaire dédiée au sein du réseau VPC du cluster.
Plan de contrôle Dans les clusters privés, le plan de contrôle GKE possède sa propre plage d'adresses IP internes dans un projet locataire géré par Google. Ce projet locataire se connecte à votre réseau VPC, généralement à l'aide de Private Service Connect.
Équilibreur de charge Les équilibreurs de charge externes utilisent des adresses IP publiques. Les équilibreurs de charge internes utilisent des adresses IP internes provenant de la plage d'adresses IP principale du sous-réseau du cluster.

Adressage IP Kubernetes et implémentation GKE

Pour utiliser efficacement GKE, vous devez comprendre les différences entre le modèle de mise en réseau Kubernetes abstrait et la façon dont GKE implémente ce modèle sur Google Cloud.

  • Modèle d'adressage IP Kubernetes : le projet Kubernetes Open Source spécifie que chaque pod reçoit une adresse IP unique. Toutes les adresses IP des pods peuvent communiquer directement sans traduction d'adresse réseau (NAT). Cela garantit un espace réseau plat où les pods peuvent se joindre les uns les autres à l'aide de leurs adresses IP attribuées.

  • Implémentation de l'adressage IP GKE : GKE implémente le modèle d'adressage IP Kubernetes sur Google Cloud en s'intégrant à la mise en réseau native VPC. Lorsque vous créez un pod, GKE lui attribue une adresse IP à partir d'une plage d'adresses IP d'alias de VPC. Cela rend l'adresse IP de chaque pod routable en mode natif dans l'ensemble de votre réseau VPC. Cela permet une communication directe non seulement entre les pods, mais aussi avec d'autres ressources Google Cloud , telles que les instances Compute Engine et les bases de données Cloud SQL. De même, GKE gère les adresses IP Service Kubernetes (telles que les ClusterIP) au sein du réseau VPC. Lorsque vous créez des services LoadBalancer pour une exposition externe, GKE provisionne des équilibreurs de charge LoadBalancer.Google Cloud Ces équilibreurs de charge utilisent des adresses IP publiques ou internes de votre réseau VPC. GKE utilise l'infrastructure réseau et d'adressage IP robuste de Google Cloudpour implémenter les concepts de mise en réseau basés sur les adresses IP de Kubernetes de manière évolutive et sécurisée.

Modèle de mise en réseau GKE : clusters de VPC natif

GKE implémente le modèle de mise en réseau Kubernetes à l'aide de la mise en réseau native VPC, qui est une fonctionnalité Google Cloud de base.

Ce modèle utilise des plages d'adresses IP d'alias. Dans un cluster de VPC natif, Kubernetes configure les adresses IP des pods en tant que plages d'adresses IP d'alias sur l'interface réseau virtuelle du nœud.

Cette implémentation présente plusieurs avantages clés :

  • Routabilité VPC-native : les adresses IP des pods sont directement routables dans votre réseau VPC. Cela simplifie la conception du réseau et permet une communication directe à faible latence entre vos pods et d'autres ressources Google Cloud , telles que les instances Compute Engine et les instances Cloud SQL.
  • Économiser le quota de routes : en utilisant des adresses IP d'alias pour les pods, GKE ne crée pas de routes statiques personnalisées pour chaque nœud. Cela préserve votre quota de routes VPC, ce qui constitue une amélioration significative par rapport aux anciens clusters basés sur les routes. C'est important pour les déploiements à grande échelle.
  • Améliorer la sécurité : la routabilité native au VPC vous permet d'appliquer des règles de pare-feu natives au VPC directement au trafic de vos pods, ce qui améliore la sécurité au niveau du réseau.

Le VPC natif est le mode de mise en réseau par défaut et recommandé pour tous les clusters GKE.

Pourquoi une gestion efficace des adresses IP est-elle essentielle ?

Pour vous assurer que votre cluster peut évoluer et maintenir l'état de santé de l'application, vous devez planifier efficacement votre espace d'adresses IP :

  • Assurez l'évolutivité : planifiez efficacement les plages d'adresses IP de vos nœuds, pods et services pour éviter l'épuisement des adresses IP et permettre à votre cluster de s'adapter sans nécessiter de réarchitecture réseau perturbatrice.
  • Garantir la fiabilité : évitez les chevauchements de plages d'adresses IP entre votre cluster GKE et d'autres réseaux, tels que les environnements sur site connectés via Cloud VPN. Les plages qui se chevauchent peuvent entraîner des conflits de routage, un comportement imprévisible et des interruptions de service.
  • Renforcer la sécurité : gérez efficacement les adresses IP pour renforcer la sécurité du réseau. Définissez des règles de réseau Kubernetes pour contrôler le flux de trafic entre les pods et configurez des règles de pare-feu pour isoler les charges de travail au niveau du réseau.

Choisir un modèle d'adressage IP pour votre cluster

GKE est compatible avec plusieurs configurations de pile réseau pour répondre à vos besoins en matière de mise en réseau, y compris les options IPv4 uniquement, double pile (IPv4 et IPv6) et IPv6 uniquement à venir.

IPv4 uniquement (pile unique)

Il s'agit de la configuration standard et la plus courante, dans laquelle tous les composants du cluster utilisent des adresses IPv4. Même dans un modèle IPv4 uniquement, GKE offre de la flexibilité :

  • Adresses IP privées RFC 1918 : utilisez des plages d'adresses IP privées RFC 1918 (par exemple, 10.0.0.0/8) pour votre cluster.
  • Adresses IP publiques utilisées en mode privé (PUPI) : si votre organisation ne dispose pas d'un espace d'adresses IP privées suffisant, vous pouvez utiliser des plages d'adresses IP publiques pour un usage interne dans votre réseau VPC. Lorsque vous utilisez des PUPI, vous devez configurer l'agent de masquage d'adresses IP. Cet agent effectue la traduction d'adresse réseau source (SNAT) sur le trafic sortant des pods. Sans SNAT, le trafic de retour vers un pod qui utilise une adresse IP publique utilisée en mode privé est acheminé sur l'Internet public et échoue. L'agent de masquage d'adresses IP empêche cela en remplaçant l'adresse IP source des paquets sortants par l'adresse IP interne du nœud au lieu de l'adresse IP du pod. Cela garantit que le trafic de retour est correctement redirigé vers le nœud, puis transféré vers le pod d'origine.

Double pile (IPv4 et IPv6)

Un cluster à double pile utilise les protocoles IPv4 et IPv6. GKE attribue une adresse IPv4 et une adresse IPv6 aux nœuds, aux pods et aux services d'un cluster à double pile. Ce modèle est idéal pour :

  • Faciliter une transition progressive vers IPv6.
  • Assurer la compatibilité avec les charges de travail compatibles IPv6, ainsi qu'avec les clients et services existants IPv4 uniquement.

Vous pouvez activer la mise en réseau à double pile lorsque vous créez un cluster ou convertir un cluster à pile unique existant en cluster à double pile.

Étapes suivantes