Ce document explique comment planifier vos adresses IP pour une installation de GKE sur VMware.
Avant de commencer
Lisez la présentation de GKE sur VMware 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, Controlplane V2 est activé pour les clusters d'utilisateur. Avec le plan de contrôle 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 le plan de contrôle V2 pour vos clusters d'utilisateur, consultez la section 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 le plan de contrôle V2.
Nœuds du cluster d'administrateur
Un cluster d'administrateur comporte trois nœuds, chacun exécutant les 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.
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 est appelé controlPlaneVIP. Par exemple, vous pouvez mettre de côté 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 du 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 du 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. |
de 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 à utiliser pour les adresses ClusterIP de Services Kubernetes.
Déterminez les plages CIDR que vous souhaitez utiliser pour les pods et les services. Exemple :
| Objectif | Plage CIDR |
|---|---|
| Pods dans le cluster d'administrateur | 192.168.0.0/16 |
| Pods dans le cluster d'utilisateur 1 | 192.168.0.0/16 |
| Pods dans le cluster d'utilisateur 2 | 192.168.0.0/16 |
| Services dans le cluster d'administrateur | 10.96.232.0/24 |
| Services dans le cluster d'utilisateur 1 | 10.96.0.0/20 |
| Services dans le cluster d'utilisateur 2 | 10.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 par 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, qui ne contient que 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 vos plages de services et de pods dans l'espace d'adressage 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.
Informations complémentaires
Gérer les adresses IP des nœuds