Planifier des adresses IP lors de la migration vers GKE

Ce document explique comment gérer l'utilisation des adresses IP sur Google Kubernetes Engine (GKE) et comment utiliser d'autres modèles de réseau dans GKE si nécessaire. Ce document traite des concepts suivants :

  • Comment réduire l'utilisation des adresses IP de pod dans GKE afin que GKE réponde aux besoins d'adresses IP de la plupart des organisations.
  • Comment d'autres modèles de mise en réseau peuvent être mis en œuvre sur GKE lorsque l'architecture de cluster ne répond pas aux exigences de votre organisation.

Ce document s'adresse aux architectes cloud, aux ingénieurs d'exploitation et aux ingénieurs réseau qui souhaitent migrer des clusters Kubernetes depuis d'autres environnements vers GKE. Suivez les instructions de ce document lorsque votre organisation rencontre des difficultés pour attribuer suffisamment d'adresses IP internes pour votre utilisation prévue de GKE.

Dans ce document, nous partons du principe que vous maîtrisez Kubernetes et son modèle de mise en réseau. Vous devez également connaître les concepts de mise en réseau tels que l'adressage IP, la traduction d'adresses réseau (NAT), les pare-feu et les proxys.

Ce document ne traite pas des stratégies de gestion de la plage d'adresses utilisée pour les adresses IP de service. Le nombre d'adresses requis pour les services est nettement inférieur à celui des pods et les options permettant de réduire ce nombre sont limitées. Sur GKE, la plage d'adresses IP des services est fixe pendant toute la durée de vie du cluster. Ainsi, la plage d'adresses IP des services doit être dimensionnée au plus grand nombre de services attendu. Comme les adresses IP des services ne sont pas accessibles en dehors du cluster, vous pouvez les réutiliser dans d'autres réseaux.

Ce document fait également référence à différents modèles de réseau Kubernetes : entièrement intégrés, en mode île et isolés. Ces modèles diffèrent dans la manière dont les adresses IP des pods sont accessibles sur le réseau. Ces différences ont un impact sur les stratégies de gestion des adresses IP pouvant être utilisées. Pour plus de détails sur ces modèles et le modèle de réseau GKE, consultez Comparaison des modèles de réseau utilisés par GKE et d'autres implémentations Kubernetes.

Réduire l'utilisation des adresses IP internes dans GKE

GKE utilise un modèle de réseau entièrement intégré dans lequel les clusters sont déployés dans un réseau VPC pouvant également contenir d'autres applications. Le modèle GKE présente de nombreux avantages. Toutefois, ce type de modèle ne permet pas de réutiliser les adresses IP des pods. Ce manque de réutilisation nécessite l'utilisation d'adresses IP de pods uniques sur l'ensemble du réseau VPC. Par conséquent, vous devez soigneusement déterminer le nombre d'adresses IP uniques dont vous avez besoin.

Le nombre d'adresses uniques dont vous avez besoin a une incidence sur la nécessité ou non de réduire l'utilisation des adresses IP, comme suit :

  • Si vous disposez de suffisamment d'espace d'adressage pour vos besoins d'adresse IP, vous n'avez pas besoin de prendre des mesures pour réduire l'utilisation des adresses IP. Toutefois, il est utile de savoir comment réduire l'utilisation des adresses IP pour identifier le nombre minimal d'adresses IP à utiliser.
  • Si vous ne disposez pas d'un espace d'adresses suffisant, vous devez réduire l'utilisation des adresses IP afin de créer des clusters GKE répondant aux contraintes de votre espace d'adresses.

Vous pouvez envisager les options suivantes pour réduire l'utilisation des adresses IP dans GKE :

  • Modifiez le paramètre "Pods par nœud". Par défaut, les clusters GKE standards réservent une plage de sous-réseaux /24 pour chaque nœud et autorisent jusqu'à 110 pods par nœud. Si vous prévoyez de n'utiliser que 64 pods ou moins par nœud, vous pouvez ajuster le nombre maximal de pods par nœud et ainsi réduire d'au moins de moitié l'utilisation de l'adresse IP des pods. Les clusters Autopilot permettent de définir 32 pods par nœud, et ce paramètre ne peut pas être modifié.
  • Utilisez plusieurs plages d'adresses IP de pods. Le classless inter-domain routing (CIDR) multipod non contigu est un outil qui vous permet d'ajouter des plages d'adresses IP de pods secondaires aux clusters existants. Vous pouvez sélectionner la plage d'adresses IP des pods utilisée par chaque pool de nœuds. Sélectionner la plage d'adresses IP utilisée par chaque pool vous permet de rester prudent lorsque vous allouez l'espace d'adresses IP initial du pod tout en continuant à développer votre cluster.

  • Utilisez des adresses IP non-RFC 1918. Il est possible que votre réseau d'entreprise ne dispose pas de suffisamment d'adresses IP RFC 1918 non allouées à utiliser pour les adresses IP de vos pods. Si vous ne disposez pas assez d'adresses IP RFC 1918 non allouées, vous pouvez utiliser des Adresses non-RFC 1918, telles que les adresses dans l'espace d'adressage RFC 6598 (100.64.0.0/10).

    Si vous utilisez déjà l'espace RFC 6598 ailleurs dans votre réseau d'entreprise, vous pouvez utiliser l'espace d'adressage Classe E/RFC 5735 (240.0.0.0/4) pour les Adresses IP des pods. Toutefois, le trafic provenant de ces adresses IP est bloqué sur les hôtes Windows et sur du matériel sur site. Pour éviter de bloquer les adresses RFC 5735, envisagez de masquer le trafic vers ces destinations externes, comme décrit dans la section Masquer les adresses IP des pods des réseaux sur site uniquement. Cependant, lorsque vous masquez le trafic vers des destinations externes, vous perdez certaines données de télémétrie dirigées vers des applications sur site.

Si votre organisation dispose d'un grand espace d'adresses IP publiques, vous pouvez également utiliser des adresses publiques PUPI (Privately Used Public Adresses). Lorsque vous utilisez des adresses PUPI, vous devez inclure les adresses PUPI dans la liste nonMasqueradeCIDRs pour avoir une connectivité en dehors du cluster sans utiliser la NAT.

Choisir un modèle de réseau dans GKE

Le document Modèle de mise en réseau GKE explique le fonctionnement des clusters Standard dans GKE, y compris les adresses IP des pods impliquées. Dans ce document, la section Réduire l'utilisation des adresses IP internes dans GKE explique comment réduire le nombre d'adresses IP internes nécessaires dans ces clusters. Il est essentiel de connaître le fonctionnement du modèle de mise en réseau GKE et la réduction des adresses IP internes pour tout modèle de réseau utilisé dans GKE.

Toutefois, connaître et appliquer ces concepts peut ne pas vous fournir de mise en œuvre de réseau répondant à vos besoins. L'arbre de décision suivant peut vous aider à choisir la méthode la plus adaptée pour mettre en œuvre le modèle de réseau GKE:

Arbre de décision des stratégies de migration des adresses IP dans GKE.

L'arbre de décision commence toujours par la création de clusters GKE standards basés sur un modèle de réseau entièrement intégré. L'étape suivante dans l'arborescence consiste à réduire l'utilisation des adresses IP en appliquant toutes les options décrites dans ce document.

Si vous avez réduit autant que possible l'utilisation des adresses IP et que vous n'avez pas suffisamment d'espace d'adressage pour vos clusters GKE, vous avez besoin d'un autre modèle de réseau. L'arbre de décision vous aide à choisir l'un des modèles de réseau alternatifs suivants:

Notez que cet arbre de décision ne doit être utilisé qu'à titre indicatif. Selon votre cas d'utilisation spécifique, vous pouvez toujours préférer un autre modèle en fonction des avantages et des inconvénients de chaque modèle. Souvent, plusieurs modèles sont adaptés et vous pouvez choisir l'approche la mieux adaptée à votre organisation.

Dans de rares cas, les modèles alternatifs présentés dans l'arbre de décision ne répondent pas à vos besoins. Pour ces rares cas, vous pouvez utiliser le modèle décrit dans la section Utiliser des instances dotées de plusieurs cartes d'interface réseau pour masquer les adresses de cluster.

Émuler d'autres modèles de réseau

Pour profiter des avantages du modèle de réseau entièrement intégré, nous vous recommandons de conserver vos clusters GKE sur le même réseau logique que vos autres ressources cloud. Toutefois, vous ne pourrez peut-être pas suivre cette recommandation. Il se peut que vous n'ayez pas suffisamment d'espace d'adresses IP ou que vous deviez masquer des adresses IP de pod sur le réseau plus grand de votre organisation.

Cette section fournit des options permettant d'utiliser le modèle de réseau entièrement intégré en décrivant différents modèles d'architecture qui imitent divers modèles de réseau alternatifs sur GKE. Ces modèles d'architecture alternatifs créent un mode de fonctionnement pour GKE semblable au modèle de réseau en mode île ou au modèle réseau en mode isolé.

Chaque modèle d'architecture alternatif inclut les informations suivantes:

Masquer les adresses IP de pods des réseaux sur site uniquement

Le modèle d'architecture dans lequel vous masquez les adresses IP des réseaux sur site utilise une combinaison des objectifs de routage suivants:

  • Demandez aux clusters GKE sur Google Cloud d'attribuer des adresses IP de pods acheminées tout au long du déploiement Google Cloud.
  • Empêchez le routage de ces adresses IP sans NAT vers des ressources sur site ou vers d'autres environnements cloud via Cloud VPN ou Cloud Interconnect.

Ce modèle d'architecture est couramment utilisé avec l'espace d'adressage IP de classe E/RFC 5735, car cet espace comprend de nombreuses adresses IP. Le nombre d'adresses IP disponibles permet de répondre à la nécessité de fournir des adresses IP uniques à chaque pod. Cependant, les adresses IP de classe E/RFC 5735 ne peuvent pas être facilement acheminées vers des ressources sur site, car de nombreux fournisseurs de matériel réseau bloquent ce trafic.

Au lieu d'utiliser l'espace d'adresses IP de la classe E/RFC 5735, vous pouvez utiliser les adresses IP RFC 1918 ou un ensemble interne d'adresses IP non-RFC 1918. Si vous utilisez l'un de ces autres ensembles d'adresses IP, déterminez s'il existe un chevauchement des adresses IP entre les adresses utilisées pour les pods et celles utilisées dans les réseaux sur site. En cas de chevauchement, assurez-vous qu'il n'existe aucune communication entre les clusters utilisant ces adresses et les applications sur site qui utilisent ces mêmes adresses.

Pour configurer ce modèle d'architecture, procédez comme suit:

  1. Créez une plage d'adresses IP secondaire pour le sous-réseau de pod. Comme décrit précédemment dans cette section, vous pouvez créer cette plage d'adresses à partir de l'espace de classe E/RFC 5735, de l'espace RFC 1918 ou d'un ensemble interne d'adresses IP non-RFC 1918. En règle générale, l'espace de classe E/RFC 5735 est utilisé.
  2. Utilisez des routes annoncées personnalisées et supprimez la plage d'adresses IP des pods des annonces sur vos routeurs Cloud Router. La suppression de ces adresses permet de garantir que les plages d'adresses IP de pods ne sont pas annoncées via le protocole BGP (Border Gateway Protocol) à vos routeurs sur site.
  3. Créez votre cluster GKE en utilisant la plage d'adresses IP secondaire en tant que routage interdomaine sans classe (CIDR) pour le pod. Vous pouvez utiliser les stratégies décrites dans la section Réduire l'utilisation des adresses IP internes dans GKE pour réduire l'utilisation des adresses IP.

  4. Ajoutez les adresses IP suivantes à la liste nonMasqueradeCIDRs dans l'agent de masquage:

    • La plage d'adresses IP que vous avez utilisée pour les pods
    • La plage d'adresses IP utilisée pour les nœuds
    • Autres adresses IP utilisées uniquement sur Google Cloud, telles que les plages d'adresses IP principales utilisées sur Google Cloud.

    N'incluez pas les plages d'adresses IP internes utilisées dans les environnements sur site ou dans d'autres environnements cloud. Si vous avez des charges de travail Windows dans Google Cloud, conservez-les dans des sous-réseaux distincts et n'incluez pas ces plages.

Lorsque vous utilisez les étapes précédentes pour configurer ce modèle, vous configurez vos clusters de la manière suivante:

  • Agissez en tant que modèle de réseau entièrement intégré dans Google Cloud.
  • Agissez en tant que modèle de réseau en mode île lors de l'interaction avec des réseaux sur site.

Pour que ce modèle alternatif émule entièrement le modèle de réseau en mode île, vous devez remplacer la liste nonMasqueradeCIDRs dans l'agent de masquage par une liste ne contenant que les plages d'adresses IP des pods et des nœuds du cluster. Le fait d'utiliser une telle liste entraîne toujours le masquage du trafic externe au cluster et à destination de l'adresse IP de nœud, même au sein Google Cloud. Cependant, après avoir effectué cette modification, vous ne pouvez pas collecter de données de télémétrie au niveau du pod dans le réseau VPC.

Le diagramme suivant montre une mise en œuvre de ce modèle d'architecture:

Schéma réseau illustrant la mise en œuvre du masquage d'une adresse IP à partir de réseaux sur site uniquement.

Le schéma précédent montre comment masquer les adresses IP des pods des réseaux externes. Comme le montre ce schéma, les pods de Google Cloud peuvent communiquer directement entre eux, même entre clusters. Cette communication de pod est semblable au modèle GKE. Notez que le schéma montre également les pods utilisant des adresses dans l'espace de classe E/RFC 5735.

Pour le trafic envoyé en dehors des clusters, le schéma montre comment la source NAT (SNAT) est appliquée à ce trafic lorsqu'elle quitte le nœud. La configuration SNAT est utilisée, que ce trafic soit acheminé via Cloud VPN vers des applications sur site ou via Cloud NAT vers des applications externes.

Ce modèle d'architecture utilise les adresses IP des pods pour la communication dans Google Cloud. Le trafic n'est masqué que lorsqu'il est dirigé vers des applications sur site ou d'autres environnements cloud. Bien que vous ne puissiez pas vous connecter directement aux pods depuis des applications sur site, vous pouvez vous connecter aux services exposés via l'équilibrage de charge interne.

Le fait de masquer les adresses IP de pods à partir de réseaux sur site présente les avantages suivants:

  • Vous pouvez toujours profiter du modèle de réseau entièrement intégré à Google Cloud, comme l'utilisation de pare-feu et la collecte de données de télémétrie basées sur les adresses IP des pods. De plus, vous pouvez vous connecter directement aux pods à des fins de débogage à partir de Google Cloud.
  • Vous pouvez toujours utiliser des maillages de services multiclusters avec des adresses IP de pods dans Google Cloud.

Toutefois, le fait de masquer les adresses IP de pods des réseaux externes présente les inconvénients suivants:

  • Vous ne pouvez pas réutiliser les plages d'adresses IP de pods ou des services pour différents clusters dans Google Cloud.
  • Vous devrez peut-être gérer deux ensembles de règles de pare-feu différents: l'un pour le trafic entre les réseaux sur site et l'autre pour le trafic entièrement dans Google Cloud.
  • Vous ne pouvez pas avoir de communication directe de pod à pod dans les maillages de services multiclusters qui s'appliquent à la fois à Google Cloud et à votre environnement sur site ou de fournisseur de services cloud. Lorsque vous utilisez Istio, par exemple, toute communication doit avoir lieu entre les passerelles Istio.

Masquer les adresses IP de pods à l'aide de Private Service Connect

Ce modèle d'architecture utilise Private Service Connect pour masquer les adresses IP des pods. Utilisez ce modèle d'architecture lorsque vous avez les besoins suivants:

  • Vous n'avez besoin d'exposer qu'un nombre limité de services à partir de vos clusters GKE.
  • Vos clusters GKE peuvent fonctionner indépendamment et ne nécessitent pas de communication de sortie avec de nombreuses applications de votre réseau d'entreprise.

Private Service Connect permet de publier les services qui doivent être utilisés depuis d'autres réseaux. Vous pouvez exposer vos services GKE à l'aide d'un équilibreur de charge réseau passthrough interne et de rattachements de service, et consommer ces services à l'aide d'un point de terminaison depuis d'autres réseaux VPC.

Pour configurer ce modèle d'architecture, procédez comme suit:

  1. Dans un réseau VPC distinct, créez un cluster GKE. Le réseau VPC ne doit contenir que ce cluster.
  2. Pour chaque service GKE de votre cluster qui doit être accessible à partir d'autres clusters ou d'applications sur un autre réseau VPC, créez un équilibreur de charge réseau passthrough interne avec Private Service Connect.

  3. (Facultatif) Si votre cluster GKE nécessite une communication de sortie avec certaines applications de votre réseau d'entreprise, exposez ces applications en publiant des services via Private Service Connect.

    Le diagramme suivant montre une mise en œuvre de ce modèle d'architecture:

Schéma réseau illustrant la mise en œuvre du masquage d'adresses IP à l'aide de Private Service Connect.

Le schéma précédent montre comment la communication au sein des clusters et entre clusters dans le modèle Private Service Connect est semblable à un modèle de réseau isolé. Cependant, la communication autorisée se fait via des points de terminaison Private Service Connect, et non via des adresses IP publiques. Comme le montre le schéma, chaque cluster obtient son propre réseau VPC distinct. En outre, chaque réseau VPC peut partager la même adresse IP, et chaque cluster peut partager le même espace d'adresses IP. Seuls les pods d'un cluster peuvent communiquer directement entre eux.

Pour communiquer depuis l'extérieur du cluster, le schéma montre comment une application externe peut atteindre le cluster via un point de terminaison Private Service Connect. Ce point de terminaison se connecte au rattachement de service fourni par le producteur de services sur le réseau VPC du cluster. La communication entre les clusters passe également par un point de terminaison Private Service Connect et par le rattachement de service d'un producteur de services.

L'utilisation de Private Service Connect pour masquer les adresses IP de pods présente les avantages suivants:

  • Vous n'avez pas besoin de planifier des adresses IP, car l'espace d'adresses IP du cluster GKE est masqué du reste du réseau. Cette approche n'expose qu'une seule adresse IP par service au réseau VPC consommateur.
  • Il est plus facile de sécuriser votre cluster, car ce modèle définit clairement les services exposés et seuls ces services sont accessibles depuis le reste du réseau VPC.

Toutefois, l'utilisation de Private Service Connect pour masquer les adresses IP de pods présente les inconvénients suivants:

  • Les pods à l'intérieur du cluster ne peuvent pas établir de communication privée en dehors du cluster. Les pods ne peuvent communiquer qu'avec les services publics (lorsque les pods disposent d'une connectivité Internet) ou avec les API Google (via l'accès privé à Google). Si des services extérieurs au cluster sont exposés via Private Service Connect, les pods peuvent également atteindre ces services. Cependant, tous les fournisseurs de services internes ne créent pas de rattachements de service. L'utilisation de Private Service Connect ne fonctionne donc que lorsque le nombre de ces services est limité aux fournisseurs qui fournissent des rattachements.
  • Les points de terminaison ne sont accessibles que depuis la région dans laquelle se trouve le service. En outre, ces points de terminaison ne sont accessibles qu'à partir du réseau VPC connecté lui-même, et non des réseaux VPC appairés ou connectés via Cloud VPN ou Cloud Interconnect.

Masquer les adresses IP de pods à l'aide de Cloud VPN

Ce modèle d'architecture utilise Cloud VPN pour créer une séparation entre les clusters GKE et le réseau VPC principal. Lorsque vous créez cette séparation, le réseau obtenu fonctionne de la même manière que le modèle de réseau en mode île. À l'instar du modèle en mode île, ce modèle vous permet de réutiliser des plages d'adresses IP de pods et de services entre clusters. Cela est possible, car la communication avec des applications extérieures au cluster utilise la SNAT. Les nœuds utilisent la configuration SNAT pour mapper les adresses IP des pods à leur propre adresse IP de nœud avant que le trafic ne quitte le nœud.

Pour configurer ce modèle, procédez comme suit:

  1. Dans un réseau VPC distinct, créez un cluster GKE. Le réseau VPC ne doit contenir que ce cluster.

    Pour le cluster, utilisez la partie inutilisée de votre attribution d'adresses IP publiques pour définir deux plages d'adresses IP: une pour les pods et une pour les services. Dimensionnez ces plages d'adresses IP en fonction des besoins du plus grand cluster GKE que vous comptez utiliser. Réservez chacune de ces plages pour une utilisation exclusive dans GKE. Vous pouvez également réutiliser ces plages pour tous les clusters GKE de votre organisation.

    Parfois, il est impossible de réserver une si grande plage d'adresses IP. Votre organisation utilise peut-être déjà les plages d'adresses IP des pods et des services pour d'autres applications. Si la plage d'adresses IP est utilisée et ne peut pas être réservée, assurez-vous que les applications qui utilisent ces adresses IP n'ont pas besoin de communiquer avec le cluster GKE.

  2. Pour le cluster que vous venez de créer, configurez la liste nonMasqueradeCIDRs dans l'agent de masquage comme une liste ne contenant que les plages d'adresses IP des pods et des nœuds du cluster. Cette liste a pour effet de forcer GKE à systématiquement masquer le trafic externe au cluster et à destination de l'adresse IP du nœud, même au sein de Google Cloud.

  3. Utilisez Cloud VPN pour connecter le réseau VPC contenant le cluster GKE au réseau VPC (principal) existant.

  4. Utilisez des routes annoncées personnalisées pour empêcher le réseau VPC du cluster d'annoncer les plages d'adresses IP de pods et de services dirigées vers votre réseau VPC principal.

  5. Répétez les étapes 1 à 4 pour les autres clusters GKE dont vous avez besoin. Pour tous les clusters, utilisez les mêmes plages d'adresses IP pour les pods et les services. Cependant, utilisez des adresses IP distinctes pour chaque nœud.

  6. Si vous disposez d'une connectivité à des réseaux sur site via Cloud VPN ou Cloud Interconnect, utilisez des routes annoncées personnalisées pour annoncer manuellement les plages d'adresses IP de nœuds.

  7. Si d'autres réseaux sont connectés à votre réseau VPC principal via l'appairage de réseaux VPC, exportez les routes personnalisées associées à ces appairages pour vous assurer que les nœuds de cluster GKE peuvent atteindre les réseaux appairés

Le diagramme suivant illustre une mise en œuvre de l'utilisation de Cloud VPN pour masquer les adresses IP de pods:

Schéma réseau illustrant la mise en œuvre du masquage d'adresses IP à l'aide de Cloud VPN

Le diagramme précédent montre comment masquer les adresses IP de pods à l'aide de Cloud VPN, ce qui crée une approche semblable au modèle de réseau en mode île. Comme le montre le diagramme, chaque cluster GKE obtient son propre réseau VPC distinct. Chaque réseau possède un espace d'adresses IP de nœud distinct, mais utilise le même espace d'adresses IP de pod. Les tunnels Cloud VPN connectent ces réseaux VPC les uns aux autres et au réseau d'entreprise, et l'espace d'adresses IP de pod n'est pas annoncé depuis les réseaux VPC contenant des clusters.

Notez dans le schéma que seuls les pods d'un cluster peuvent communiquer directement entre eux. Le nœud utilise la SNAT pour masquer l'espace d'adressage IP du pod lors de la communication en dehors du cluster avec un autre cluster, avec le réseau d'entreprise ou avec un réseau sur site connecté. Les pods ne sont pas accessibles directement à partir d'autres clusters ou du réseau d'entreprise. Seuls les services de cluster exposés avec un équilibreur de charge interne sont accessibles via les connexions Cloud VPN.

L'utilisation de Cloud VPN pour masquer les adresses IP de pods présente les avantages suivants:

  • Comme décrit dans le modèle de réseau en mode île, vous pouvez réutiliser les plages d'adresses IP de pods et de services entre les clusters.
  • Les pare-feu peuvent nécessiter moins de configuration, car les adresses IP des pods ne sont pas directement accessibles à partir du réseau VPC principal et des réseaux connectés. Vous n'avez donc pas besoin de configurer des règles de pare-feu explicites pour bloquer la communication avec les pods.

Toutefois, l'utilisation de Cloud VPN pour masquer les adresses IP de pods présente les inconvénients suivants:

  • Les mêmes inconvénients que ceux mentionnés dans le modèle de réseau en mode île s'appliquent. Par exemple, vous ne pouvez pas définir de règles de pare-feu au niveau du pod. Vous ne pouvez pas non plus collecter de données de télémétrie au niveau du pod dans le réseau VPC principal ou le réseau connecté.
  • Par rapport au modèle de mise en réseau GKE par défaut, ce modèle entraîne des coûts supplémentaires provenant des coûts associés aux tunnels Cloud VPN et des frais de transfert de données.
  • Cloud VPN comporte une limite de bande passante par tunnel VPN. Si vous atteignez cette limite de bande passante, vous pouvez configurer plusieurs tunnels Cloud VPN et distribuer le trafic à l'aide du routage ECMP (Equal-Cost Multi-Path). Toutefois, l'exécution de ces actions ajoute à la complexité de la configuration et de la maintenance de la mise en œuvre de GKE.
  • Synchroniser les annonces de routage ajoute de la complexité à la création des clusters. Chaque fois que vous créez des clusters GKE, vous devez configurer des tunnels Cloud VPN et créer des annonces de routage personnalisées sur ces tunnels et sur les applications sur site.

Masquer les adresses IP de pods à l'aide des adresses IP publiques utilisées en interne et de l'appairage de réseaux VPC

Si votre organisation possède des adresses IP publiques inutilisées, vous pouvez utiliser ce modèle d'architecture qui ressemble à un modèle de réseau en mode île, mais qui est utilisé en mode privé dans l'espace d'adresses IP publiques. Cette architecture est semblable au modèle qui utilise Cloud VPN, mais à la place elle utilise l'appairage de réseaux VPC pour créer la séparation entre le cluster GKE et le réseau principal.

Pour configurer ce modèle d'architecture, procédez comme suit:

  1. Dans un réseau VPC distinct, créez un cluster GKE. Le réseau VPC ne doit contenir que ce cluster.

    Pour le cluster, utilisez la partie inutilisée de votre attribution d'adresses IP publiques pour définir deux plages d'adresses IP: une pour les pods et une pour les services. Dimensionnez ces plages d'adresses IP en fonction des besoins du plus grand cluster GKE que vous comptez utiliser. Réservez chacune de ces plages pour une utilisation exclusive dans GKE. Vous pouvez également réutiliser ces plages pour tous les clusters GKE de votre organisation.

    Au lieu d'utiliser votre attribution d'adresses IP publiques, il est théoriquement possible d'utiliser les plus grands blocs d'adresses IP publiques non utilisés appartenant à des tiers. Cependant, nous déconseillons fortement une telle configuration, car ces adresses IP peuvent être vendues ou utilisées publiquement à tout moment. La vente ou l'utilisation d'adresses entraîne des problèmes de sécurité et de connectivité lors de l'utilisation de services publics sur Internet.

  2. Pour le cluster que vous venez de créer, configurez la liste nonMasqueradeCIDRs dans l'agent de masquage comme une liste ne contenant que les plages d'adresses IP des pods et des nœuds du cluster. Cette liste a pour effet de forcer GKE à systématiquement masquer le trafic sortant du cluster à destination de l'adresse IP du nœud, même au sein de Google Cloud.

  3. Utilisez la fonction d'appairage de réseaux VPC pour connecter le réseau VPC qui contient le cluster GKE au réseau VPC (principal) existant. Comme vous ne souhaitez pas que les adresses PUPI soient échangées dans ce modèle, définissez l'option --no-export-subnet-routes-with-public-ip lors de la configuration de l'appairage.

  4. Répétez les étapes 1 à 3 pour les autres clusters GKE dont vous avez besoin. Pour tous les clusters, utilisez la même plage d'adresses IP pour les pods et les services. Cependant, utilisez une adresse IP distincte pour chaque nœud.

  5. Si vous disposez d'une connectivité à des réseaux sur site via Cloud VPN ou Cloud Interconnect, utilisez des annonces de routage personnalisées pour annoncer manuellement les plages d'adresses IP de nœuds.

Le diagramme suivant montre une mise en œuvre de ce modèle d'architecture:

Schéma réseau montrant la mise en œuvre du masquage des adresses IP à l'aide de PUPI et de l'appairage de réseaux VPC

Le schéma précédent montre comment masquer des adresses IP à l'aide de l'appairage de réseaux VPC. Comme le montre le diagramme, chaque cluster GKE obtient son propre réseau VPC distinct. Chaque nœud possède un espace d'adressage IP de nœud distinct, mais utilise le même espace d'adressage IP de pod que celui défini à partir de l'espace d'adressage PUPI de votre organisation. Les réseaux VPC se connectent les uns aux autres ainsi qu'à des applications autres que Kubernetes dans Google Cloud via l'appairage de réseaux VPC. L'espace d'adressage PUPI n'est pas annoncé entre les appairages. Les réseaux VPC se connectent au réseau d'entreprise via des tunnels Cloud VPN.

Seuls les pods d'un cluster peuvent communiquer directement entre eux. Le nœud utilise la SNAT pour masquer l'espace d'adresses IP des pods lors de la communication en dehors du cluster avec un autre cluster, avec le réseau d'entreprise ou avec un réseau connecté sur site. Les pods ne sont pas accessibles directement à partir d'autres clusters ou du réseau d'entreprise. Seuls les services exposés avec un équilibreur de charge interne sont accessibles via les connexions d'appairage de réseaux VPC.

Ce modèle d'architecture est semblable à l'approche Cloud VPN décrite précédemment, mais présente les avantages suivants par rapport à ce modèle :

  • Contrairement au modèle d'architecture Cloud VPN, l'appairage de réseaux VPC n'entraîne aucun coût supplémentaire pour les tunnels Cloud VPN et la bande passante entre les environnements.
  • L'appairage de réseaux VPC ne présente pas de limites de bande passante et est entièrement intégré aux réseaux définis par logiciel de Google. L'appairage de réseaux VPC peut donc offrir une latence légèrement inférieure à celle de Cloud VPN, car l'appairage ne nécessite pas les passerelles et le traitement requis par Cloud VPN.

Cependant, le modèle d'appairage de réseaux VPC présente également les inconvénients suivants par rapport au modèle Cloud VPN:

  • Votre organisation requiert un espace d'adresses IP publiques à la fois inutilisé et suffisamment grand pour l'espace d'adresses IP de pod requis par le plus grand cluster GKE prévu.
  • L'appairage de réseaux VPC n'est pas transitif. Ainsi, les clusters GKE connectés au réseau VPC principal via l'appairage de réseaux VPC ne peuvent pas communiquer directement entre eux ou avec les applications des réseaux VPC qui sont appairées avec le réseau VPC principal. Vous devez connecter directement ces réseaux via l'appairage de réseaux VPC pour activer une telle communication ou utiliser une VM proxy dans le réseau VPC principal.

Utiliser des instances avec plusieurs cartes d'interface réseau pour masquer les adresses de cluster

Ce modèle d'architecture comprend les composants et technologies suivants pour créer un modèle semblable à un modèle de réseau en mode île:

  • Il utilise les instances Compute Engine à cartes d'interface réseau multiples pour créer une couche de séparation entre les clusters GKE et le réseau VPC principal.
  • Il utilise NAT sur les adresses IP envoyées entre ces environnements.

Vous pouvez utiliser ce modèle lorsque vous devez inspecter, transformer ou filtrer le trafic spécifique qui entre ou sort du cluster GKE. Si vous devez effectuer ce type d'inspection, de transformation ou de filtrage, utilisez les instances Compute Engine déployées pour effectuer ces tâches.

L'utilisation d'instances à cartes d'interface réseau multiples pour masquer les adresses de cluster présente les avantages suivants:

  • L'espace d'adresses IP du cluster GKE est masqué du reste du réseau. Une seule adresse IP par service est exposée au réseau VPC consommateur.
  • Les services sont accessibles à l'échelle mondiale, à partir de réseaux sur site connectés et de réseaux appairés.

Toutefois, l'utilisation d'instances à cartes d'interface réseau multiples pour masquer les adresses de cluster présente les inconvénients suivants:

  • Ce modèle est plus complexe à mettre en œuvre que les autres approches, car il nécessite non seulement la mise en œuvre du modèle, mais également la configuration de la surveillance et de la journalisation pour les instances à cartes d'interface réseau multiples.
  • Les instances à cartes d'interface réseau multiples sont soumises à des limites de bande passante et aux tarifs des instances de VM.
  • Vous devez gérer et mettre à niveau les instances à cartes d'interface réseau multiples.

Étape suivante