Gestion des adresses GKE : optimisation des adresses IPv4

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 un processus permettant d'identifier les exigences du bloc CIDR de GKE. Il présente ensuite un modèle de décision qui aide à identifier la solution recommandée pour un scénario particulier. Enfin, il montre différentes solutions en les décrivant brièvement et en énumérant les avantages et les inconvénients correspondants.

Identifier les exigences du bloc CIDR de GKE

Dans cette section, vous allez déterminer la taille des blocs CIDR de votre cluster. Il est essentiel de le faire correctement, car vous ne pourrez pas modifier ou développer un bloc CIDR une fois le cluster créé.

Déterminer la taille du bloc CIDR du nœud

Suivez les étapes ci-dessous pour déterminer la taille du bloc CIDR du nœud :

  1. Déterminez le nombre maximal de nœuds dont vous aurez besoin dans votre cluster au cours de sa durée de vie.

    Si vous parvenez à déterminer ce nombre qui dépend des prévisions d'application, de conception et de croissance du client, utilisez-le comme nombre de nœuds requis. Sinon, utilisez comme nombre maximal la limite de quota de 5 000 nœuds.

  2. Déterminez les bits d'hôte nécessaires en fonction du nombre de nœuds requis.

    Lorsque vous connaissez le nombre de nœuds requis, vous pouvez utiliser le tableau 1 pour calculer les bits d'hôte nécessaires pour générer un masque de réseau. Recherchez le nombre de nœuds requis dans la colonne Nœuds requis. Pour l'étape suivante, utilisez le nombre correspondant dans la colonne Bits d'hôte pour les nœuds.

    Nœuds requis Bits d'hôte pour les nœuds
    1-4 3
    5-12 4
    13-28 5
    29-60 6
    61-124 7
    125-252 8
    253-508 9
    509-1020 10
    1021-2044 11
    2045-4092 12
    4093-8188 13

    Tableau 1. Bits nécessaires pour les adresses de nœud.

  3. Générez un masque de réseau du bloc CIDR à l'aide du nombre de la colonne Bits d'hôte pour les nœuds que vous avez déterminé à l'étape précédente :

    32 – bits d'hôte pour les nœuds = masque de réseau du bloc CIDR du nœud

    La figure suivante illustre de manière graphique cette équation.

    Masque de réseau du bloc CIDR du nœud.

    Par exemple, pour un cluster de 5 000 nœuds, le tableau 1 indique que le masque de réseau du nœud requiert 13 bits d'hôte pour les nœuds. Pour calculer le masque de réseau complet, remplacez le nombre de bits d'hôte pour les nœuds dans l'équation, 32 – 13 = 19. Le résultat est un masque de réseau de /19.

Déterminer la taille du bloc CIDR du pod

Suivez les étapes ci-dessous pour déterminer la taille du bloc CIDR du pod :

  1. Déterminez le nombre maximal de pods par nœud dont vous aurez besoin dans votre cluster au cours de sa durée de vie.

    Si vous parvenez à déterminer ce nombre qui dépend de l'application, utilisez-le comme nombre de pods requis par nœuds. Sinon, utilisez comme nombre maximal la limite de quota de 110 pods par nœud.

  2. Déterminez les bits d'hôte nécessaires pour le nombre de pods requis.

    Lorsque vous connaissez le nombre de pods requis par nœud, vous pouvez utiliser le tableau 2 pour calculer les bits d'hôte nécessaires afin de générer un masque de réseau. Recherchez le nombre de pods requis par nœud dans la colonne Nombre de pods par nœud. Pour l'étape suivante, utilisez le nombre correspondant dans la colonne Bits d'hôte pour les pods.

    Nombre de pods par nœud Bits d'hôte pour les pods
    1-8 4
    9-16 5
    17-32 6
    33-64 7
    65-110 8

    Tableau 2. Bits nécessaires pour les pods par nœud.

  3. Générez un masque de réseau du bloc CIDR en utilisant le nombre de bits d'hôte pour les nœuds que vous avez déterminé à l'étape 2 de la section Déterminer la taille du bloc CIDR du nœud et le nombre de bits d'hôte pour les pods que vous avez déterminé à l'étape précédente :

    32 – {bits d'hôte pour les nœuds + bits d'hôte pour les pods) = masque de réseau du bloc CIDR du pod

    La figure suivante illustre de manière graphique cette équation.

    Masque de réseau du bloc CIDR du pod.

    Par exemple, si vous avez besoin de 110 pods par nœud, vous aurez besoin de 8 bits d'hôte pour les pods par nœud. Prenez ensuite les bits d'hôte pour les nœuds (13) et remplacez ces nombres dans l'équation : 32 – (13 + 8) = 11. Le résultat est un masque de réseau de /11.

Déterminer la taille du bloc CIDR de l'adresse IP du cluster

Suivez les étapes ci-dessous pour déterminer la taille du bloc CIDR de l'adresse IP du cluster :

  1. Déterminez le nombre maximal d'adresses IP de cluster dont vous avez besoin dans votre cluster au cours de sa durée de vie.

    Si vous parvenez à déterminer ce nombre qui dépend de l'application, utilisez-le comme nombre d'adresses IP de cluster requis. Sinon, utilisez comme nombre maximal le masque de réseau par défaut /20. Si vous utilisez le masque de réseau par défaut, vous pouvez ignorer l'étape suivante.

  2. Déterminez le masque de réseau pour le bloc CIDR de l'adresse IP du cluster.

    Lorsque vous connaissez le nombre maximal d'adresses IP de cluster dont vous avez besoin, vous pouvez utiliser le tableau 3 pour trouver le masque de réseau.

    Nombre d'adresses IP de cluster Masque de réseau
    1-32 /27
    33-64 /26
    65-128 /25
    129-256 /24
    257-512 /23
    513-1 024 /22
    1 025-2 048 /21
    2 049-4 096 /20
    4 097-8 192 /19
    8 193-16 384 /18
    16 385-32 768 /17
    32 769-65 536 /16

    Tableau 3. Masque de réseau du bloc CIDR des services.

Comprendre la demande d'adresses

En examinant les exigences du bloc CIDR dérivées des étapes précédentes, vous remarquerez que le bloc CIDR du pod génère la plus grande demande d'espace d'adressage IP. La plupart du temps, la deuxième plus grosse demande est celle du CIDR du nœud, suivie du bloc CIDR des services.

Maintenant que vous avez calculé les exigences relatives à l'adresse IP du cluster, vous devez vérifier l'espace d'adressage IP RFC 1918 disponible et sélectionner un chemin d'accès.

Sélectionner la meilleure solution

La figure 1 montre un arbre de décision que vous pouvez utiliser pour déterminer la meilleure solution en fonction des exigences du bloc CIDR. La section Examiner les solutions résume chaque solution.

Exemple de configuration du service. (Pour obtenir une version PDF lisible à l'écran, cliquez sur l'image.)
Figure 1. Exemple de configuration du service. (Pour obtenir une version PDF lisible à l'écran, cliquez sur l'image.)

Examiner les solutions

Cette section décrit chaque solution et quand l'utiliser, puis en résume les avantages, inconvénients et autres problèmes.

Attribuer l'espace d'adressage disponible

À quel moment l'utiliser ?

  • Après avoir examiné l'espace d'adressage IP disponible et parcouru la figure 1, vous avez déterminé qu'il y a suffisamment d'espace d'adressage RFC 1918 à allouer aux blocs CIDR du cluster. Par exemple, bien que l'adresse 10.0.0.0/8 soit épuisée, les adresses 172.16.0.0/12 ou 192.168.0.0/16 disposent de suffisamment d'espace pour répondre aux exigences du bloc CIDR.

Description :

  • Aucune autre étape de configuration particulière n'est requise pour cette solution. Allouez l'espace d'adressage et poursuivez l'installation.

Avantages :

  • Il s'agit de la solution la plus simple.
  • Aucune configuration particulière n'est requise.

Inconvénients :

  • Épuise l'espace d'adressage IP disponible.

Autres problèmes :

Traduire le bloc CIDR du pod GKE

À quel moment l'utiliser ?

  • Après avoir examiné l'espace d'adressage IP disponible et parcouru la figure 1, vous avez déterminé qu'il y a suffisamment d'espace d'adressage RFC 1918 disponible à allouer au bloc du nœud, mais pas assez pour le bloc CIDR du pod. Par conséquent, vous devez traduire les blocs CIDR du pod (et éventuellement du service).

Description :

  • Pour traduire les blocs CIDR du pod dans un cluster GKE, vous implémentez la fonctionnalité ip-masquerade-agent conformément à la figure 2. Cette fonctionnalité masque les adresses IP du pod derrière les adresses IP du nœud. Avec cette conception, il est également possible de réutiliser des blocs CIDR pour le bloc CIDR de service.

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

    Cette architecture comporte plusieurs composants :

    • Une nouvelle terminologie pour décrire les caractéristiques des blocs CIDR en relation avec la fonctionnalité NAT.
    • La fonctionnalité ip-masquerade-agent.
    • Des blocs CIDR RFC 1918 réutilisés.
    • Le filtrage au niveau de la connexion sur site.

Avantages :

  • Facilite l'allocation d'adresses IPv4 pour le CIDR du pod.
  • S'adapte au plus grand bloc CIDR de pod supportable.
  • Permet d'isoler les blocs CIDR RFC 1918 réutilisés du tableau de routage global.
  • Rend les réseaux maillés Istio multi-cluster toujours possibles.
  • Permet de tout de même utiliser les configurations de groupes de points de terminaison du réseau.

Inconvénients :

  • La fonctionnalité NAT introduit de nouveaux problèmes à résoudre, tels que le partage et la journalisation de l'adresse.
  • Toutes les ressources du VPC ne peuvent pas communiquer avec les ressources sur site auxquelles est attribuée la même plage CIDR que la plage CIDR du pod. Ce problème existe également pour les ressources sur site qui partagent le bloc CIDR de service si la plage de services est réutilisée. Le problème est que les blocs CIDR réutilisés apparaissent comme des itinéraires locaux vers le VPC et ne sont donc jamais routés en dehors de ce VPC.

Autres problèmes :

  • Soyez prudent lorsque vous sélectionnez les blocs CIDR RFC 1918 à réutiliser pour les blocs CIDR de GKE.
  • Ne faites pas la promotion des blocs CIDR RFC 1918 réutilisés sur le réseau sur site.
  • Étant donné que les blocs CIDR réutilisés se trouvent dans le tableau de routage VPC, soyez prudent lorsque vous utilisez l'appairage de VPC ou les connexions VPN.

Traduire tous les blocs CIDR de GKE

À quel moment l'utiliser ?

  • Après avoir examiné l'espace d'adressage IP disponible et parcouru la figure 1, vous avez déterminé qu'il n'y a pas suffisamment d'espace d'adressage RFC 1918 disponible pour l'allouer aux blocs CIDR du pod ou du nœud du cluster. Vous devez donc traduire tous les blocs CIDR.

Description :

  • Pour traduire tous les blocs CIDR d'un cluster GKE, vous devez implémenter l'architecture illustrée à la figure 3.

    Fonctionnalité NAT pour tous les blocs CIDR d'un cluster GKE. (Pour obtenir une version PDF lisible à l'écran, cliquez sur l'image.)
    Figure 3. Fonctionnalité NAT pour tous les blocs CIDR d'un cluster GKE. (Pour obtenir une version PDF lisible à l'écran, cliquez sur l'image.)

    Cette architecture comporte plusieurs composants :

    • Une nouvelle terminologie pour décrire les caractéristiques des blocs CIDR en relation avec la fonctionnalité NAT.
    • Des blocs CIDR RFC 1918 réutilisés.
    • Un VPC hôte qui possède un réseau partagé.
    • Un VPC de service appelé VPC isolé qui contient le cluster GKE.
    • Une instance Compute Engine appelée passerelle de VPC isolé qui exécute la fonctionnalité NAT et possède une interface réseau à la fois dans le VPC isolé et dans le VPC hôte.
    • Le concept d'un bloc CIDR d'équilibreur de charge interne.
    • Des itinéraires statiques dans les deux VPC qui dirigent le trafic de manière appropriée.
    • Le filtrage au niveau de la connexion sur site.

Avantages :

  • Facilite l'allocation d'adresses IPv4.
  • S'adapte au plus grand cluster compatible.
  • Permet la réplication pour plusieurs clusters.
  • Offre la meilleure isolation possible des blocs CIDR RFC 1918 réutilisés dans le tableau de routage global.
  • Rend les configurations de groupe de points de terminaison de réseau toujours possibles.

Inconvénients :

  • Cette solution présente plus de complexité que les solutions précédentes.
  • La fonctionnalité NAT introduit de nouveaux problèmes à résoudre, tels que le partage et la journalisation de l'adresse.
  • Les réseaux maillés Istio multi-cluster ne sont pas possibles dans certains déploiements.

Autres problèmes :

  • Soyez prudent lorsque vous sélectionnez les blocs CIDR RFC 1918 à réutiliser pour les blocs CIDR de GKE.
  • Ne faites pas la promotion des blocs CIDR RFC 1918 réutilisés sur le réseau sur site.

Étapes suivantes