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 entre 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 Cloud de Confiance by S3NS, 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 :
- Mise en réseau de base : y compris les adresses IP, CIDR, les pare-feu et la traduction d'adresse réseau (NAT).
- Composants Kubernetes de base : tels que les clusters, les nœuds, les pods et les services.
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 la communication. Les sections suivantes décrivent comment GKE attribue et utilise les adresses IP pour les composants de cluster de base :
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 avoir une adresse IP externe pour l'accès sortant à Internet.
Pods : suivant le modèle "une adresse IP par pod" de Kubernetes, 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 via
localhost.Services : GKE attribue à chaque service Kubernetes une adresse IP virtuelle stable (
ClusterIP) à partir d'une plage d'adresses IP secondaire dédiée. CetteClusterIPfournit un point de terminaison unique et fiable pour un groupe de pods. Lorsque vous envoyez du trafic à laClusterIP, GKE l'équilibre automatiquement sur un pod sain au sein 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 Cloud de Confiance by S3NS des équilibreurs de charge. 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 comment 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 alloue cette adresse IP à partir de la plage d'adresses IP principale du sous-réseau associé au pool de nœuds du nœud. Ce sous-réseau peut être le sous-réseau par défaut du cluster ou 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 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 Cloud de Confiance by S3NS.
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). Cette approche permet de garantir un espace réseau plat où les pods peuvent se contacter à 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 Cloud de Confiance by S3NS en s'intégrant à la mise en réseau de VPC natif. Lorsque vous créez un pod, GKE alloue son adresse IP à partir d'une plage d'adresses IP d'alias 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 Cloud de Confiance by S3NS ressources, telles que les instances Compute Engine et les bases de données Cloud SQL. De même, GKE gère les adresses IP
ServiceKubernetes (telles que lesClusterIP) au sein du réseau VPC. Lorsque vous créezLoadBalancerdes services pour une exposition externe, GKE provisionne Cloud de Confiance by S3NS des équilibreurs de charge. Ces équilibreurs de charge utilisent des adresses IP publiques ou internes de votre réseau VPC. GKE utilise Cloud de Confiance by S3NS's l'infrastructure robuste d'adressage IP et de mise en réseau de pour implémenter les concepts de mise en réseau basés sur 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 de VPC natif, qui est une fonctionnalité de base Cloud de Confiance by S3NS .
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 offre plusieurs avantages clés :
- Capacité de routage de VPC natif : les adresses IP des pods sont directement routables au sein de votre réseau VPC. Cela simplifie la conception du réseau et permet une communication directe à faible latence entre vos pods et d'autres Cloud de Confiance by S3NS ressources, telles que les instances Compute Engine et les instances Cloud SQL.
- Conserver 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, une amélioration significative par rapport aux anciens clusters basés sur les routes, et est important pour les déploiements à grande échelle.
- Améliorer la sécurité : la capacité de routage de VPC natif vous permet d'appliquer directement des règles de pare-feu de VPC natif 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 l'application, vous devez planifier efficacement votre espace d'adresses IP :
- Assurer 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 l'isolation des 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 une 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 une utilisation interne au sein de 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 PUPI est acheminé sur l'Internet public et échoue. L'agent de masquage d'adresses IP empêche cela en modifiant l'adresse IP source des paquets sortants de la PUPI du pod en adresse IP interne du nœud. Cette approche permet de s'assurer que le trafic de retour est correctement acheminé 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 avec IPv6 et les clients et services IPv4 uniquement existants.
Vous pouvez activer la mise en réseau à double pile lorsque vous créez un cluster ou mettre à jour un cluster à pile unique existant vers une double pile.
Étape suivante
- Pour en savoir plus sur les avantages du mode de mise en réseau par défaut de GKE, consultez À propos des clusters de VPC natif.
- Pour commencer, découvrez comment créer un cluster de VPC natif.
- Pour obtenir des conseils sur le dimensionnement des plages d'adresses IP de votre cluster, consultez Planifier des plages d'adresses IP pour les clusters de VPC natif.
- Pour obtenir de l'aide sur les problèmes courants, consultez Résoudre les problèmes liés à l'agent de masquage d'adresses IP.