Planifier vos adresses IP

Ce document explique comment planifier vos adresses IP pour une installation de Google Distributed Cloud.

Avant de commencer

Lisez la présentation de Google Distributed Cloud et la présentation de l'installation.

Exemple d'allocation d'adresses IP

Cette section donne un exemple d'allocation d'adresses IP statiques dans une installation comprenant les éléments suivants :

  • Un poste de travail d'administrateur

  • Un cluster d'administrateur haute disponibilité

  • Un cluster d'utilisateur à haute disponibilité comportant cinq nœuds de calcul

  • Un cluster d'utilisateur standard comportant quatre nœuds de calcul

Dans cet exemple, le Controlplane V2 est activé sur les clusters d'utilisateur. Avec Controlplane V2, les nœuds du plan de contrôle d'un cluster d'utilisateur se trouvent dans le cluster d'utilisateur lui-même.

Si vous ne souhaitez pas activer Controlplane V2 pour vos clusters d'utilisateur, consultez la page Planifier vos adresses IP (kubeception). Le terme kubeception fait référence au cas où le plan de contrôle d'un cluster d'utilisateur s'exécute sur un ou plusieurs nœuds du cluster d'administrateur. Nous vous déconseillons d'utiliser kubeception. Nous vous recommandons d'activer Controlplane V2.

Nœuds du cluster d'administrateur

Un cluster d'administrateur comporte trois nœuds, chacun exécutant des composants du plan de contrôle.

Équilibrage de charge

Pour cet exemple, supposons que les clusters utilisent l'équilibreur de charge MetalLB. Cet équilibreur de charge s'exécute sur les nœuds du cluster. Aucune VM supplémentaire n'est donc nécessaire pour l'équilibrage de charge.

Sous-réseaux

Pour cet exemple, supposons que chaque cluster se trouve sur son propre VLAN et que les clusters se trouvent dans les sous-réseaux suivants :

VM Sous-réseau Passerelle par défaut
Poste de travail d'administrateur et cluster d'administrateur 172.16.20.0/24 172.16.20.1
Cluster d'utilisateur 1 172.16.21.0/24 172.16.21.1
Cluster d'utilisateur 2 172.16.22.0/24 172.16.22.1

Le schéma suivant illustre les trois VLAN et sous-réseaux. Notez que les adresses IP virtuelles ne sont associées à aucun nœud particulier d'un cluster. En effet, l'équilibreur de charge MetalLB peut choisir le nœud qui annonce l'adresse IP virtuelle pour un service individuel. Par exemple, dans le cluster d'utilisateur 1, un nœud de calcul pourrait annoncer 172.16.21.31 et un autre nœud de calcul pourrait annoncer 172.16.21.32.

Adresses IP pour un cluster d'administrateur et deux clusters d'utilisateur.
Adresses IP pour un cluster d'administrateur et deux clusters d'utilisateur (cliquez pour agrandir)

Exemple d'adresse IP : poste de travail administrateur

Dans cet exemple, le poste de travail administrateur se trouve dans le même sous-réseau que le cluster d'administrateur : 172.16.20.0/24. Une adresse proche des adresses des nœuds convient au poste de travail administrateur. Exemple : 172.16.20.20.

Exemples d'adresses IP : nœuds de cluster d'administrateur

Dans cet exemple, le cluster d'administrateur comporte trois nœuds. Vous devez donc définir trois adresses IP. Par exemple, vous pouvez réserver les adresses IP suivantes pour les nœuds du cluster d'administrateur:

Cluster d'administrateur Adresses IP
Cluster d'administrateur haute disponibilité 172.16.20.2 à 172.16.20.4

Exemples d'adresses IP: adresse IP virtuelle pour le cluster d'administrateur

Vous devez réserver une adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'administrateur. Notez que dans le fichier de configuration du cluster, le champ de cette adresse IP virtuelle s'appelle controlPlaneVIP. Par exemple, vous pouvez réserver l'adresse IP virtuelle suivante pour le serveur d'API Kubernetes du cluster d'administrateur:

VIP Adresse IP
Adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'administrateur 172.16.20.30

Exemples d'adresses IP : nœud de cluster utilisateur 1

Pour un cluster d'utilisateur comportant huit nœuds, vous devez réserver neuf adresses IP. L'adresse supplémentaire est requise, car elle est nécessaire lors de la mise à niveau, de la mise à jour et de la réparation automatique du cluster. Par exemple, vous pouvez réserver les adresses IP suivantes pour les nœuds du cluster d'utilisateur 1:

Adresses IP des nœuds dans le cluster d'utilisateur 1
172.16.21.2 à 172.16.21.10

Exemples d'adresses IP: adresses IP virtuelles pour le cluster d'utilisateur 1

Le tableau suivant montre comment désigner des adresses IP virtuelles à configurer sur l'équilibreur de charge pour le cluster d'utilisateur 1 :

VIP Description Adresse IP
Adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'utilisateur 1 Configuré sur l'équilibreur de charge pour le cluster d'utilisateur 1 172.16.21.30
Adresse IP virtuelle d'entrée pour le cluster d'utilisateur 1 Configuré sur l'équilibreur de charge pour le cluster d'utilisateur 1 172.16.21.31
Adresses IP virtuelles de service pour le cluster d'utilisateur 1 Dix adresses pour les services de type LoadBalancer.
Configuré selon les besoins sur l'équilibreur de charge pour le cluster d'utilisateur 1.
Notez que cette plage inclut l'adresse IP virtuelle d'entrée.
Il s'agit d'une exigence pour l'équilibreur de charge MetalLB.
172.16.21.31 à 172.16.21.40

Exemples d'adresses IP : nœud de cluster utilisateur 2

Pour un cluster d'utilisateur comportant cinq nœuds, vous devez réserver six adresses IP. L'adresse supplémentaire est requise, car elle est nécessaire lors de la mise à niveau, de la mise à jour et de la réparation automatique du cluster. Par exemple, vous pouvez réserver les adresses IP suivantes pour les nœuds du cluster d'utilisateur 2:

Adresses IP des nœuds dans le cluster d'utilisateur 2
172.16.22.2 à 172.16.22.7

Exemples d'adresses IP: adresses IP virtuelles pour le cluster d'utilisateur 2

Le tableau suivant montre comment désigner des adresses IP virtuelles à configurer sur l'équilibreur de charge pour le cluster d'utilisateur 2 :

VIP Description Adresse IP
Adresse IP virtuelle pour le serveur d'API Kubernetes pour le cluster d'utilisateur 2 Configuré sur l'équilibreur de charge pour le cluster d'utilisateur 2 172.16.22.30
Adresse IP virtuelle d'entrée pour le cluster d'utilisateur 2 Configuré sur l'équilibreur de charge pour le cluster d'utilisateur 2 172.16.22.31
Adresses IP virtuelles de service pour le cluster d'utilisateur 2 Dix adresses pour les services de type LoadBalancer.
Configuré selon les besoins sur l'équilibreur de charge pour le cluster d'utilisateur 2.
Notez que cette plage inclut l'adresse IP virtuelle d'entrée.
Il s'agit d'une exigence pour l'équilibreur de charge MetalLB.
172.16.22.31 à 172.16.22.40

Exemples d'adresses IP : pods et services

Avant de créer un cluster, vous devez spécifier une plage CIDR à utiliser pour les adresses IP des pods et une autre plage CIDR à utiliser pour les adresses ClusterIP des services Kubernetes.

Déterminez les plages CIDR que vous souhaitez utiliser pour les pods et les services. Exemple :

ObjectifPlage CIDR
Pods dans le cluster d'administrateur192.168.0.0/16
Pods dans le cluster d'utilisateur 1192.168.0.0/16
Pods dans le cluster d'utilisateur 2192.168.0.0/16
Services dans le cluster d'administrateur10.96.232.0/24
Services dans le cluster d'utilisateur 110.96.0.0/20
Services dans le cluster d'utilisateur 210.96.128.0/20

Les exemples précédents illustrent ces points :

  • La plage CIDR du pod peut être identique pour plusieurs clusters.

  • Généralement, vous avez besoin de plus de pods que de services. Par conséquent, pour un cluster donné, vous souhaiterez probablement une plage CIDR de pods plus grande que la plage CIDR de service. La plage de pods fournie en exemple pour un cluster d'utilisateur est 192.168.0.0/16, soit 2^(32-16) = 2^16 adresses. Toutefois, un exemple de plage de services pour un cluster d'utilisateur est 10.96.0.0/20, soit 2^(32-20) = 2^12 adresses.

Éviter le chevauchement

Vous pouvez utiliser des plages CIDR autres que celles par défaut pour éviter le chevauchement des adresses IP accessibles sur votre réseau. Les plages de services et de pods ne doivent chevaucher aucune adresse en dehors du cluster que vous souhaitez atteindre depuis l'intérieur du cluster.

Par exemple, supposons que votre plage de services soit 10.96.232.0/24 et que votre plage de pods soit 192.168.0.0/16 (192.168.0.1 - 192.168.255.254). Tout trafic envoyé depuis un pod vers une adresse dans l'une de ces plages est traité comme étant dans un cluster et n'atteint aucune destination en dehors du cluster.

En particulier, les plages de services et de pods ne doivent pas chevaucher les éléments suivants :

  • Adresses IP des nœuds d'un cluster

  • Adresses IP utilisées par les machines des équilibreurs de charge

  • Adresses IP virtuelles utilisées par les nœuds de plan de contrôle et les équilibreurs de charge

  • Adresses IP des serveurs vCenter, DNS et NTP

Nous vous recommandons de placer les plages de services et de pods dans l'espace d'adressage privé RFC 1918.

Voici l'une des raisons pour lesquelles il est recommandé d'utiliser les adresses RFC 1918 Supposons que votre plage de services et de pods contienne des adresses IP externes. Tout trafic envoyé depuis un pod vers l'une de ces adresses externes sera traité comme du trafic interne au cluster et n'atteindra pas la destination externe.

Serveur DNS et passerelle par défaut

Avant de renseigner vos fichiers de configuration, vous devez connaître l'adresse IP d'un serveur DNS pouvant être utilisé par votre poste de travail administrateur et vos nœuds de cluster.

Vous devez également connaître l'adresse IP de la passerelle par défaut pour chacun de vos sous-réseaux. Dans les exemples précédents, la passerelle par défaut de chaque sous-réseau est la première adresse de la plage. Par exemple, dans le sous-réseau du cluster d'administrateur, la passerelle par défaut est l'adresse 172.16.20.1.

En savoir plus

Gérer les adresses IP des nœuds