Ce document explique comment configurer la connectivité des pods dans GKE aux points de terminaison externes, y compris les ressources des réseaux sur site et les services Internet publics. Pour contrôler l'adresse IP source du trafic des pods GKE, vous pouvez utiliser à la fois le ip-masq-agent (traduction au niveau du nœud) et Cloud NAT (sortie au niveau du VPC).
Présentation
Lorsqu'un pod d'un cluster GKE de VPC natif envoie un paquet à une destination en dehors du cluster, l'adresse IP source du paquet change en fonction de la configuration de l'agent de masquage d'adresses IP au niveau du nœud (ip-masq-agent) et de Cloud NAT.
- Traduction au niveau du nœud (
ip-masq-agent) : traduit l'adresse IP source du paquet de l'adresse IP du pod (plage de sous-réseau secondaire) en adresse IP du nœud interne (plage de sous-réseau principale) en fonction d'une listenonMasqueradeCIDRsconfigurée. - Passerelle au niveau du VPC (Cloud NAT) : traduit les adresses IP de VPC internes (adresses IP de nœud ou adresses IP de pod) en adresses IP publiques statiques pour autoriser l'accès sortant à Internet.
Selon que la destination est masquée par le nœud ou non, le paquet quitte le nœud avec l'adresse IP du nœud ou l'adresse IP du pod. Cette adresse IP source détermine la façon dont vous configurez vos routeurs Cloud Router ou sur site.
Fonctionnement combiné de l'IP masquerading et de Cloud NAT
Pour le trafic orienté vers Internet, les paquets d'un pod traversent à la fois la pile réseau du nœud et la passerelle Cloud NAT.
Scénario A : Masquage vers l'adresse IP du nœud (recommandé pour la sortie Internet)
Si l'adresse IP de destination ne correspond pas à une plage de la liste nonMasqueradeCIDRs :
ip-masq-agenteffectue la traduction NAT source (SNAT) sur le nœud GKE. L'adresse IP source est réécrite de l'adresse IP du pod vers l'adresse IP du nœud.- Le paquet entre dans le réseau VPC avec l'adresse IP du nœud comme source.
- La passerelle Cloud NAT intercepte le paquet.
- Cloud NAT traduit l'adresse IP du nœud en adresse IP publique et l'achemine vers Internet.
Scénario B : Conservation de l'adresse IP du pod (pas de masquage)
Si l'adresse IP de destination correspond à une plage de la liste nonMasqueradeCIDRs (ou si la SNAT par défaut est désactivée) :
ip-masq-agentlaisse le paquet inchangé. L'adresse IP source reste l'adresse IP du pod.- Le paquet entre dans le réseau VPC avec l'adresse IP du pod comme source.
- La passerelle Cloud NAT intercepte le paquet.
- Cloud NAT traduit l'adresse IP du pod en adresse IP publique uniquement si Cloud NAT est explicitement configuré pour traduire la plage d'adresses IP secondaire du sous-réseau utilisée pour les pods GKE.
Vérificateur de masquage d'adresses IP
Utilisez ce vérificateur pour déterminer si une adresse IP de destination sera masquée en fonction de votre configuration ip-masq-agent.
Exemple de flux de trafic
Pour comprendre le chemin de traduction, considérez l'exemple de configuration suivant :
- Plage d'adresses IP du pod :
10.4.0.0/14(adresse IP du pod :10.4.0.5) - Plage d'adresses IP du nœud :
10.128.0.0/20(adresse IP du nœud :10.128.0.10) - Adresse IP de destination :
8.8.8.8(serveur DNS public, ne figurant pas dans la listenonMasqueradeCIDRs)
Lorsque le pod envoie un paquet, les événements suivants se produisent :
- Le paquet démarre au niveau du pod : le paquet provient de l'interface réseau du pod (adresse IP :
10.4.0.5) avec une adresse IP de destination8.8.8.8. - Masquage au niveau du nœud : comme l'adresse IP de destination
8.8.8.8ne figure pas dans la listenonMasqueradeCIDRs,ip-masq-agentsur le nœud hôte intercepte le paquet à sa sortie et effectue la SNAT. L'adresse IP source est réécrite de l'adresse IP du pod10.4.0.5vers l'adresse IP du nœud hôte, qui est10.128.0.10. - Sortie VPC : le paquet atteint le réseau VPC en utilisant l'adresse IP du nœud hôte
10.128.0.10comme adresse IP source. - Passerelle Cloud NAT : comme la destination est l'Internet public, Cloud NAT traite le paquet, traduit l'adresse IP source de
10.128.0.10en adresse IP NAT publique (par exemple,203.0.113.1) et le transfère vers Internet. - Gestion des réponses : la réponse revient à l'adresse IP Cloud NAT publique, que Cloud NAT traduit en sens inverse vers l'adresse IP du nœud hôte
10.128.0.10. Le nœud traduit ensuite l'adresse IP du nœud hôte en sens inverse vers l'adresse IP du pod, qui est10.4.0.5, et la transmet au conteneur du pod.
Flux de trafic avec Cloud Service Mesh (CSM)
Si vos charges de travail utilisent Cloud Service Mesh, le routage du trafic se comporte comme suit :
- Proxy side-car ou redirection CNI sans side-car : les paquets sortants du conteneur d'application sont interceptés par le maillage (à l'aide d'un proxy side-car tel qu'Envoy ou via une redirection basée sur ebpf ou CNI) avant d'atteindre l'espace de noms réseau du nœud.
- Application de la règle : le maillage détermine si la connexion est autorisée en fonction de ses règles d'autorisation et de sortie.
- Routage de sortie
- Si le trafic est dirigé à l'aide d'une passerelle de sortie Cloud Service Mesh, l'adresse IP source du paquet quittant le nœud correspond à l'adresse IP du nœud ou du pod de la passerelle de sortie, plutôt qu'au pod d'origine.
- Si le trafic est acheminé directement vers le point de terminaison externe, le paquet quitte le proxy et est acheminé via la pile réseau standard du nœud hôte. Dans ce cas, les règles
ip-masq-agentet les configurations Cloud NAT décrites précédemment dans ce document s'appliquent toujours au trafic sortant.
- Pour en savoir plus sur la configuration du routage et des passerelles, ainsi que sur la gestion du trafic externe dans Cloud Service Mesh, consultez la documentation Cloud Service Mesh.
Résoudre les problèmes de connectivité et les isoler
Si un pod ne parvient pas à se connecter à un point de terminaison externe et que vous utilisez un maillage de services, vous devez déterminer si le problème provient de la configuration du maillage de services ou du routage GKE sous-jacent. Pour isoler le problème, procédez comme suit :
- Contournez le maillage de services : déployez un pod client temporaire dans un espace de noms où l’injection side-car est désactivée, ou utilisez l’annotation
sidecar.istio.io/inject: "false"dans la spécification du pod pour empêcher l’injection pour la charge de travail de test. - Testez la connectivité : tentez de vous connecter à la destination externe (par exemple, à l'aide de
curl,pingounc) à partir du pod non maillé. - Analysez les résultats :
- Si la connexion réussit : le routage réseau GKE sous-jacent, les règles
ip-masq-agentet la passerelle Cloud NAT sont correctement configurés. Le bloc de connectivité est dû aux règles Cloud Service Mesh, à des règles de sortie manquantes ou à des règles mTLS. Pour en savoir plus sur la résolution des problèmes, consultez la section Résoudre des problèmes pour les déploiements qui utilisent Envoy dans la documentation Cloud Service Mesh. - Si la connexion échoue : le problème appartient à l'infrastructure réseau sous-jacente (telle que l'IP masquerading, Cloud Router, Cloud NAT, les règles de pare-feu VPC ou les pare-feu sur site). Suivez les étapes de cette page pour vérifier votre configuration de routage.
- Si la connexion réussit : le routage réseau GKE sous-jacent, les règles
Déterminer la plage d'adresses IP source à l'aide du vérificateur
Avant de configurer des routeurs ou des pare-feu, utilisez le vérificateur de masquage d'adresses IP de ce document, puis procédez comme suit :
- Collez le contenu YAML de votre ConfigMap
ip-masq-agentdans le champ de configuration. - Saisissez l'adresse IP de destination de votre point de terminaison cible (par exemple, votre base de données sur site ou un service Internet externe).
- Cliquez sur Vérifier le masquage.
- Notez le résultat :
- Masqué : le paquet utilise la plage d'adresses IP du nœud comme source.
- Non masqué : le paquet utilise la plage d'adresses IP du pod comme source.
Configurer la connectivité aux points de terminaison
En fonction des résultats du vérificateur de masquage d'adresses IP, configurez vos chemins réseau et vos passerelles en fonction du type de destination.
Points de terminaison sur site (VPN ou Interconnect)
Cloud NAT n'est pas utilisé pour la connectivité sur site, mais vous devez configurer vos routeurs et pare-feu en fonction de la plage d'adresses IP source que vous avez déterminée à l'aide du vérificateur de masquage d'adresses IP.
Si le trafic est masqué (la source est l'adresse IP du nœud) :
- Cloud Router : assurez-vous que les annonces Cloud Router incluent la plage d'adresses IP principale du sous-réseau du cluster GKE.
- Routeur ou pare-feu sur site : configurez vos routeurs et pare-feu sur site pour autoriser et gérer le trafic entrant provenant de la plage d'adresses IP du nœud GKE.
Si le trafic n'est pas masqué (la source est l'adresse IP du pod) :
- Cloud Router : configurez des annonces de routage personnalisées sur votre Cloud Router pour annoncer la plage d'adresses IP secondaire du pod GKE sur votre réseau sur site.
- Routeur ou pare-feu sur site : configurez les tables de routage et les pare-feu sur site pour autoriser le trafic provenant de la plage d'adresses IP du pod GKE et assurez-vous que les routes de retour sont annoncées au VPC.
Points de terminaison Internet (Cloud NAT)
Lorsque vous acheminez du trafic vers des points de terminaison Internet publics, vous devez configurer une passerelle Cloud NAT dans le VPC.
- Dans la Cloud de Confiance console, accédez à la page Cloud NAT.
- Sélectionnez ou créez votre passerelle Cloud NAT.
- Sous Source Cloud NAT, choisissez comment la passerelle gère les plages de sous-réseaux GKE :
- Si le trafic est masqué (la source est l'adresse IP du nœud) : sélectionnez les plages d'adresses IP principales du sous-réseau. Les déploiements GKE commerciaux sont généralement définis par défaut sur cette option.
- Si le trafic n'est pas masqué (la source est l'adresse IP du pod) : vous devez sélectionner les plages d'adresses IP principales et secondaires (ou spécifier explicitement la plage secondaire du pod GKE). Si vous ne sélectionnez que les plages principales, le trafic Internet du pod GKE sera bloqué.