Ce document explique comment planifier vos adresses IP pour une installation de GKE sur VMware qui inclut des clusters d'utilisateur utilisant kubeception.
Qu'est-ce que kubeception ?
Le terme kubeception est utilisé pour transmettre l'idée qu'un cluster Kubernetes est utilisé pour créer et gérer d'autres clusters Kubernetes. Dans le contexte de GKE sur VMware, la 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 d'un cluster d'administrateur.
Nous vous déconseillons d'utiliser kubeception. Nous vous recommandons plutôt d'utiliser Controlplane V2. Avec le plan de contrôle V2, les nœuds du plan de contrôle du cluster d'utilisateur se trouvent dans le cluster d'utilisateur lui-même.
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
Un cluster d'utilisateur haute disponibilité comprenant cinq nœuds de calcul
Un cluster d'utilisateur standard comportant quatre nœuds de calcul
Nœuds du cluster d'administrateur
Le cluster d'administrateur comporte sept nœuds :
- Un nœud qui exécute le plan de contrôle pour le cluster d'administrateur
- Deux nœuds qui exécutent des modules complémentaires pour le cluster d'administrateur
- Trois nœuds qui exécutent le plan de contrôle pour le cluster d'utilisateur haute disponibilité
- Un nœud qui exécute le plan de contrôle pour le cluster d'utilisateur standard
É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
Pour un cluster d'administrateur comportant sept nœuds, vous devez réserver huit 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 de votre cluster d'administrateur :
| Adresses IP des nœuds du cluster d'administrateur |
|---|
| 172.16.20.2 – 172.16.20.9 |
Exemples d'adresses IP : adresses IP virtuelles dans le sous-réseau du cluster d'administrateur
Le tableau suivant montre comment désigner des adresses IP virtuelles à configurer sur l'équilibreur de charge pour le cluster d'administrateur. Notez que les adresses IP virtuelles des serveurs d'API Kubernetes des clusters d'utilisateur se trouvent sur le sous-réseau du cluster d'administrateur. En effet, dans cet exemple, le serveur d'API Kubernetes d'un cluster d'utilisateur s'exécute sur un nœud du cluster d'administrateur. Notez que dans les fichiers de configuration du cluster, le champ dans lequel vous spécifiez l'adresse IP virtuelle pour un serveur d'API Kubernetes est appelé controlPlaneVIP:
| VIP | Adresse IP |
|---|---|
| Adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'administrateur | 172.16.20.30 |
| Adresse IP virtuelle des modules complémentaires du cluster d'administrateur | 172.16.20.31 |
| Adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'utilisateur 1 | 172.16.20.32 |
| Adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'utilisateur 2 | 172.16.20.33 |
Exemples d'adresses IP : nœud de cluster utilisateur 1
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 1:
| Adresses IP des nœuds du cluster d'utilisateur 1 |
|---|
| 172.16.21.2 à 172.16.21.7 |
Exemples d'adresses IP : adresses IP virtuelles dans le sous-réseau du 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 d'entrée pour le cluster d'utilisateur 1 | Configuré sur l'équilibreur de charge pour le cluster d'utilisateur 1 | 172.16.21.30 |
| 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.30 - 172.16.21.39 |
Exemples d'adresses IP : nœud de cluster utilisateur 2
Pour un cluster d'utilisateur comportant quatre nœuds, vous devez réserver cinq 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.6 |
Exemples d'adresses IP : adresses IP virtuelles dans le sous-réseau du 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 d'entrée pour le cluster d'utilisateur 2 | Configuré sur l'équilibreur de charge pour le cluster d'utilisateur 2 | 172.16.22.30 |
| 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.30 - 172.16.22.39 |
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. L'exemple de plage de pods 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