Gestion des adresses GKE : NAT pour un bloc CIDR du pod GKE

Ce document fait partie d'une série destinée aux architectes de réseau. Cette série aborde les options de gestion des adresses Google Kubernetes Engine (GKE) disponibles pour les organisations dont l'adressage  IPv4 est limitée.

Cette série comprend les parties suivantes :

Ce document décrit une solution dans laquelle le bloc CIDR du pod se voit attribuer un bloc d'adresses RFC 1918 déjà utilisé dans le réseau sur site. Ce bloc CIDR est ensuite traduit avec la fonctionnalité ip-masq-agent. Cette approche masque les adresses IPv4 du pod derrière les adresses IP des nœuds.

Considérations sur les blocs CIDR

Lorsque vous installez un cluster GKE, vous devez allouer trois blocs CIDR : un nœud, un pod et un bloc de service. Après avoir lu les deux premiers documents de cette série, vous avez maintenant une liste des masques réseau requis pour ces blocs, et vous savez que vous devez réutiliser l'espace d'adressage pour le bloc CIDR du pod.

Lorsque vous sélectionnez une plage d'adresses, procédez comme suit :

  • Le bloc CIDR du pod est considéré comme une plage d'adresses réutilisée du VPC isolé. En effet, vous devez sélectionner le bloc CIDR dans l'espace d'adressage déjà attribué sur site et le configurer dans le VPC isolé.
  • Le bloc CIDR de service peut être considéré comme une plage d'adresses réutilisée du VPC isolé. Il est judicieux d'attribuer une adresse réutilisée à cet espace, car elle est utilisée uniquement pour la communication entre les pods dans le cluster.
  • Le bloc CIDR du nœud doit être une adresse allouée au domaine routé.
  • Les blocs CIDR du pod et du service ne doivent pas être un sous-ensemble du bloc CIDR attribué au VPC isolé, ou un bloc CIDR attribué à des VPC appairés.
  • Les blocs CIDR du pod et du service ne doivent pas être réutilisés dans des VPC appairés.
  • Les blocs CIDR du pod, du nœud et du service ne doivent pas se chevaucher.
  • Lorsque vous sélectionnez une plage d'adresses à réutiliser pour le bloc CIDR du pod, vous devez sélectionner une plage attribuée aux ressources auxquelles les pods ne devront jamais se connecter. Cette approche évite d'attribuer des adresses réutilisées de domaine routé pour ces ressources sur site.

Solution

La figure suivante montre une vue d'ensemble de la solution. À droite du schéma se trouve votre réseau sur site. Sur la gauche se trouve un cluster GKE dans votre VPC isolé. La fonctionnalité ip-masq-agent est configurée pour les nœuds du cluster. Le VPC isolé fait la promotion du nœud GKE CIDR sur le réseau sur site. Chaque composant fonctionnel est abordé dans les sections suivantes.

Fonctionnalité NAT pour un bloc CIDR du pod dans un cluster GKE. (Pour obtenir une version PDF lisible, cliquez sur l'image.)
Figure 1. Fonctionnalité NAT pour un bloc CIDR du pod dans un cluster GKE. (Pour obtenir une version PDF lisible, cliquez sur l'image.)

VPC isolé

Le VPC isolé est un VPC standard. On dit qu'il est isolé pour indiquer que l'espace d'adressage réutilisé doit être isolé de la table de routage globale sur site. Ce VPC présente les caractéristiques suivantes :

  • L'API GKE est activée.
  • Il contient le cluster GKE.
  • Il contient des équilibreurs de charge internes pour l'accès de domaine routé aux adresses IP du service GKE.

Dans ce VPC, les plages CIDR du pod se voient allouer un espace d'adressage réutilisé. Les plages CIDR du service peuvent être affectées à un espace d'adressage réutilisé ou alloué. Les blocs CIDR du nœud doivent être associés à un espace d'adressage alloué au domaine routé.

Routage

Lorsque vous faites la promotion de routes vers le réseau sur site, vous ne devez pas annoncer de plages d'adresses de VPC isolé réutilisées, c'est-à-dire les plages CIDR du pod et éventuellement du service. Les routeurs sur site ou les pare-feu qui appairent avec les routeurs cloud ne doivent accepter aucun bloc d'adresses réutilisé de VPC isolé provenant de leurs pairs routés.

Configuration NAT

Vous devez configurer le cluster GKE pour utiliser la fonctionnalité ip-masq-agent. Les nœuds de cluster ne doivent pas traduire les plages de blocs CIDR du pod ou du service dans le VPC ou tous les VPC appairés.

Trafic provenant du VPC isolé acheminé vers le domaine routé

Le trafic provenant des adresses de VPC isolé du pod réutilisées est traduit dans l'interface du nœud. Par conséquent, tout le trafic provenant d'un pod possède une adresse source du nœud sur lequel il réside. Un pod ne peut pas non plus établir de communication avec des blocs CIDR identiques utilisés en tant qu'adresses allouées de domaine routé. Les adresses sont dites partagées avec le VPC isolé, car ces sous-réseaux sont toujours considérés comme étant directement connectés. Ce trafic n'est jamais acheminé vers la passerelle de VPC isolé. Il s'agit d'un problème de routage, pas d'un problème de NAT.

Trafic provenant du domaine routé acheminé vers le VPC isolé

Le trafic provenant du domaine routé se connecte aux pods via les adresses IP de l'équilibreur de charge interne. Ces adresses IP sont attribuées à partir du bloc CIDR de nœud alloué au domaine routé.

Les ressources du réseau sur site, qui partagent le même bloc CIDR que les pods, c'est-à-dire un bloc CIDR utilisé à la fois comme adresse allouée de domaine routé et comme adresse de VPC isolé réutilisée, ne peuvent pas communiquer avec les pods, car les pods considèrent la plage CIDR comme connectée localement. Les adresses sont partagées avec le cluster. La figure suivante illustre le partage d'adresses.

Adresses IP internes de l'équilibreur de charge partagées avec un cluster. (Pour obtenir une version PDF lisible, cliquez sur l'image.)
Figure 2. Adresses IP internes de l'équilibreur de charge partagées avec un cluster. (Pour obtenir une version PDF lisible, cliquez sur l'image.)

Dans la figure, comme l'adresse 10.0.0.2 du domaine routé est considérée comme appartenant à l'espace d'adressage de pod 10.0.0.0/11 dans le VPC isolé, les événements suivants se produisent :

  1. Le trafic quitte le nœud Host1 destiné au nœud Host2 avec une adresse source 10.0.0.2.
  2. Le paquet entre dans Host2 dans le VPC isolé comme prévu et est traité, mais il fait ensuite l'objet d'un processus appelé envoi dans le trou noir (black-holing) et est partagé avec le VPC isolé.
  3. Le paquet en réponse avec l'adresse de destination 10.0.0.2 est acheminé à tort vers une adresse de pod sur le nœud Host3, car la décision de routage sur le nœud Host2 considère le réseau comme local. Pour éviter ce problème, vous devez sélectionner des adresses réutilisées à partir de ressources qui n'ont pas besoin de se connecter aux pods. Si cela n'est pas possible, vous devez utiliser la solution NAT pour tous les blocs CIDR de GKE.

Équilibrage de charge

Par l'intermédiaire du fichier de configuration de service GKE, vous rendez vos adresses IP de service disponibles pour le domaine routé via des adresses IPv4 d'équilibreur de charge interne. Vous sélectionnez ces adresses d'équilibrage de charge interne dans la plage CIDR IPv4 de nœud attribuée au sous-réseau principal du VPC isolé. Comme le bloc du nœud est une adresse allouée au domaine routé, aucune étape de configuration supplémentaire n'est requise.

Autres problèmes

La NAT avec passerelle de la couche d'application n'est pas compatible avec la charge utile de paquets. Cette solution ne se traduit qu'au niveau de la couche 3.

Informations complémentaires

Cette section aborde en détail les facteurs supplémentaires à prendre en compte lors de la configuration de votre cluster GKE.

Gestion de l'authentification et des accès

Passez en revue les procédures et rôles IAM suivants, et attribuez-les de manière appropriée au sein de votre organisation :

Coût

Lorsque la facturation est activée pour le projet, le tutoriel associé entraîne les coûts supplémentaires suivants. Les coûts exacts dépendent de la mise en œuvre :

Pour vous aider à estimer les coûts, vous pouvez utiliser le simulateur de coût de Google Cloud.

Quota et limites

Tenez compte des limites et quotas suivants :

API

Vous devez activer l'API GKE dans le VPC isolé.

Sécurité

Nous vous recommandons de discuter des points de sécurité suivants avec votre équipe chargée du réseau et de la sécurité :

  • Étant donné qu'une mauvaise configuration des scénarios de réutilisation des adresses peut occasionner des pannes de réseau, configurez l'automatisation et des alias d'adresse e-mail tels que ipv4addrspaceviolation@example.com et ipv4routingviolation@example.com pour être averti en cas de problème.
  • Effectuez le suivi des traductions pour toute analyse de données ultérieure.
  • Pour vous assurer que vos règles de pare-feu sont conformes aux normes établies, examinez toute connexion externe à Internet depuis le VPC isolé.
  • Avant d'appliquer les règles de pare-feu en production, examinez chaque règle.

Étapes suivantes