Mise en réseau de nœuds

Cette rubrique décrit comment personnaliser la mise en réseau de nœuds pour les clusters de charge de travail, notamment la personnalisation des adresses IP des nœuds et la configuration des réservations DHCP, d'IPAM de nœud et d'IPv6 sur vSphere.

Configurer les réservations DHCP de nœuds et l'enregistrement DNS du point de terminaison (vSphere uniquement)

Pour les nouveaux clusters sur vSphere, vous devez créer des réservations DHCP pour ses nœuds. Vous devrez peut-être également créer un enregistrement DNS pour son point de terminaison de plan de contrôle :

Réservations DHCP pour les nœuds de cluster :

Par mesure de sécurité, dans les environnements dans lesquels plusieurs nœuds du plan de contrôle peuvent être mis hors tension ou hors ligne pendant de longues périodes, ajustez les réservations DHCP pour les adresses IP des nœuds worker et du plan de contrôle d'un cluster récemment créé afin que les adresses restent statiques et que les baux n'expirent jamais.

Pour obtenir des instructions sur la configuration des réservations DHCP, reportez-vous à la documentation de votre serveur DHCP.
Enregistrement DNS pour le point de terminaison du plan de contrôle :

Si vous utilisez NSX Advanced Load Balancer, pas Kube-Vip, pour votre point de terminaison du plan de contrôle et que vous définissez VSPHERE_CONTROL_PLANE_ENDPOINT sur un nom de domaine complet plutôt qu'une adresse IP numérique, réservez les adresses comme suit :
1. Récupérez l'adresse IP du plan de contrôle que NSX ALB a attribuée au cluster :
```
kubectl get cluster CLUSTER-NAME -o=jsonpath='{.spec.controlPlaneEndpoint} {"\n"}'
```
2. Enregistrez l'adresse IP répertoriée comme "host" dans la sortie, par exemple 192.168.104.107.
3. Créez un enregistrement A DNS qui associe le nom de domaine complet à l'adresse IP que vous avez enregistrée.
4. Pour tester le nom de domaine complet, créez un fichier kubeconfig qui utilise le nom de domaine complet au lieu de l'adresse IP de NSX ALB :
  1. Générez le fichier kubeconfig :
```
tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
```
  2. Modifiez le fichier kubeconfig KUBECONFIG-TEST pour remplacer l'adresse IP par le nom de domaine complet. Par exemple, remplacez :
```
server: https://192.168.104.107:443
```
    par :
```
server: https://CONTROLPLANE-FQDN:443
```
  3. Récupérez les espaces du cluster à l'aide du fichier kubeconfig modifié :
```
kubectl get pods -A --kubeconfig=./KUBECONFIG-TEST
```
    Si la sortie répertorie les espaces, DNS fonctionne pour le nom de domaine complet.

Personnaliser les adresses IP des nœuds de cluster (MC autonome)

Vous pouvez configurer des blocs d’adresses IP spécifiques au cluster pour les nœuds dans les clusters de gestion autonomes et les clusters de charge de travail qu’ils déploient. La manière dont vous procédez dépend de l'infrastructure de cloud sur laquelle le cluster s'exécute :

vSphere

Sur vSphere, le fichier de configuration du cluster VSPHERE_NETWORK définit le réseau de machines virtuelles que Tanzu Kubernetes Grid utilise pour les nœuds de cluster et d'autres objets Kubernetes. Les adresses IP sont allouées aux nœuds par un serveur DHCP qui s'exécute dans ce réseau de machines virtuelles, déployé séparément de Tanzu Kubernetes Grid.

Si vous utilisez la mise en réseau NSX, vous pouvez configurer des liaisons DHCP pour vos nœuds de cluster en suivant la section Configurer les liaisons statiques DHCP sur un segment dans la documentation VMware NSX-T Data Center.

Remarque
à partir de la version 4.0, VMware NSX-T Data Center est renommé « VMware NSX ».

AWS

Pour configurer des blocs d'adresses IP spécifiques au cluster sur Amazon Web Services (AWS), définissez les variables suivantes dans le fichier de configuration du cluster, comme décrit dans le tableau AWS de la Référence de variable du fichier de configuration.

Définissez AWS_PUBLIC_NODE_CIDR pour définir une plage d'adresses IP pour les nœuds publics.
- Ajoutez des plages supplémentaires en définissant AWS_PRIVATE_NODE_CIDR_1 ou AWS_PRIVATE_NODE_CIDR_2
Définissez AWS_PRIVATE_NODE_CIDR pour définir une plage d'adresses IP pour les nœuds privés.
- Ajoutez des plages supplémentaires en définissant AWS_PRIVATE_NODE_CIDR_1 et AWS_PRIVATE_NODE_CIDR_2
Toutes les plages CIDR de nœud doivent se trouver dans la plage VPC du cluster, qui est définie par défaut sur 10.0.0.0/16.

Microsoft Azure

Pour configurer des blocs d'adresses IP spécifiques au cluster sur Azure, définissez les variables suivantes dans le fichier de configuration du cluster, comme décrit dans le tableau Microsoft Azure de la Référence de variable du fichier de configuration.

Définissez AZURE_NODE_SUBNET_CIDR pour créer un réseau virtuel avec un bloc CIDR pour les adresses IP des nœuds worker.
Définissez AZURE_CONTROL_PLANE_SUBNET_CIDR pour créer un réseau virtuel avec un bloc CIDR pour les adresses IP du nœud de plan de contrôle.
Définissez AZURE_NODE_SUBNET_NAME pour attribuer des adresses IP de nœud worker à partir de la plage d'un réseau virtuel existant.
Définissez AZURE_CONTROL_PLANE_SUBNET_NAME pour attribuer des adresses IP de nœud de plan de contrôle à partir de la plage d'un réseau virtuel existant.

IPAM de nœud (vSphere)

Avec l'IPAM de nœud, un fournisseur IPAM de cluster alloue et gère les adresses IP pour les nœuds de cluster lors de la création et la mise à l'échelle du cluster, évitant ainsi de configurer un protocole DHCP externe.

Vous pouvez configurer l'IPAM de nœud pour les clusters de gestion autonomes sur vSphere et les clusters de charge de travail basés sur une classe qu'ils gèrent. La procédure ci-dessous configure l'IPAM de nœud pour les clusters de charge de travail basés sur une classe. Pour configurer l'IPAM de nœud pour un cluster de gestion, reportez-vous à la section Configurer l'IPAM de nœud du document Configuration du cluster de gestion pour vSphere.

Remarque
Cette procédure ne s'applique pas à TKG avec un superviseur vSphere with Tanzu ou un cluster de gestion autonome sur AWS ou Azure.

Lors de la configuration d'IPAM de nœud pour un cluster de charge de travail nouveau ou existant, l'utilisateur spécifie un pool d'adresses IP internes à partir duquel le fournisseur IPAM alloue des adresses IP statiques et une adresse de passerelle.

Lors de l'allocation d'adresses aux nœuds de cluster, l'IPAM de nœud choisit toujours l'adresse disponible la plus faible dans le pool.

Conditions requises

Cluster de gestion autonome TKG
Serveurs de noms pour le plan de contrôle et les nœuds worker du cluster de charge de travail
- Requis, car les nœuds de cluster ne recevront plus de serveurs de noms via DHCP pour résoudre les noms dans vCenter.
kubectl et la CLI Tanzu installée localement

Limitations

L'IPAM de nœud présente les limitations suivantes dans TKG v2.3 :

Uniquement pour les nouveaux clusters de charge de travail basés sur une classe déployés par un cluster de gestion sur vSphere.
- Vous ne pouvez pas convertir des clusters basés sur DHCP existants en IPAM de nœud.
Aucune prise en charge de nœud Windows.
Uniquement pour un environnement IPv4 ou IPv6, pas à double pile.
Alloue uniquement des adresses de nœud, pas le point de terminaison du plan de contrôle du cluster.
L'IPAM de nœud ne vérifie pas si son pool d'adresses IP est en conflit avec les pools DHCP déjà utilisés par d'autres clusters.

Configurer IPAM de nœud pour un cluster de charge de travail

Le pool IPAM de nœud d'un cluster de charge de travail peut être défini par deux types d'objets différents, en fonction de la manière dont ses adresses sont partagées avec d'autres clusters :

InClusterIPPool configure des pools d'adresses IP uniquement disponibles pour les clusters de charge de travail dans le même espace de noms de cluster de gestion, tel que default.
- Il s'agissait du seul type disponible dans TKG v2.1 et v2.2.
GlobalInClusterIPPool configure des pools d'adresses IP avec des adresses qui peuvent être allouées à des clusters de charge de travail sur plusieurs espaces de noms.

Pour configurer un nouveau cluster ou un cluster existant avec IPAM de nœud :

Créez un fichier de définition d'objet de pool d'adresses IP my-ip-pool.yaml qui définit une plage d'adresses IP à partir d'un sous-réseau que TKG peut utiliser pour allouer des adresses IP statiques à votre cluster de charge de travail. Définissez l'objet en tant que InClusterIPPool ou GlobalInClusterIPPool en fonction de la manière dont vous souhaitez délimiter le pool d'adresses IP, par exemple :
- InClusterIPPool: pour créer un pool d'adresses IP inclusterippool pour les clusters de charge de travail dans l'espace de noms default qui contient la plage 10.10.10.2-10.10.10.100, ainsi que les plages 10.10.10.102 et 10.10.10.104 :
```
apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: InClusterIPPool
metadata:
  name: inclusterippool
  namespace: default
spec:
  gateway: 10.10.10.1
  addresses:
  - 10.10.10.2-10.10.10.100
  - 10.10.10.102
  - 10.10.10.104
  prefix: 24
```
  Remarque
  Les versions précédentes de TKG utilisaient la version valpha1 de l'objet InClusterIPPool, qui ne prenait en charge qu'une plage de pools d'adresses IP contiguë spécifiée par start et end, comme décrit dans la documentation de TKG v2.1. La mise à niveau des clusters vers la version v2.3 convertit leurs pools d'adresses IP en nouvelle structure.
- GlobalInClusterIPPool: pour créer un pool d'adresses IP inclusterippool à partager entre des espaces de noms contenant les mêmes adresses que celles du InClusterIPPool ci-dessus :
```
apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: GlobalInClusterIPPool
metadata:
  name: inclusterippool
spec:
  gateway: 10.10.10.1
  addresses:
  - 10.10.10.2-10.10.10.100
  - 10.10.10.102
  - 10.10.10.104
  prefix: 24
```
Créez l'objet de pool d'adresses IP :
```
kubectl apply -f my-ip-pool.yaml
```

Configurez le cluster de charge de travail afin d'utiliser le pool d'adresses IP dans un fichier de configuration de cluster plat ou dans une spécification d'objet de style Kubernetes, comme décrit dans Fichiers de configuration.

Par exemple :

Fichier de configuration plat (pour créer des clusters) :

# The name of the InClusterIPPool object specified above
NODE_IPAM_IP_POOL_NAME: inclusterippool
CONTROL_PLANE_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11
WORKER_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11

Spécification d'objet (pour créer des clusters ou modifier des clusters existants) :

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
spec:
topology:
  variables:
  - name: network
    value:
      addressesFromPools:
      - apiGroup: ipam.cluster.x-k8s.io
        kind: InClusterIPPool
        name: inclusterippool
  - name: controlplane
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]
  - name: worker
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]

Vous pouvez maintenant déployer votre cluster de charge de travail.

Règles de pool

Les plages de pools d'adresses IP ne doivent pas se chevaucher
- Le chevauchement de pools peut entraîner des pannes et TKG ne valide pas les plages de pools ou ne détecte pas les chevauchements.
Ne supprimez pas une adresse IP actuellement allouée d'un pool d'adresses IP.

Dépannage d'IPAM de nœud

Pour voir si des adresses IP sont attribuées aux nœuds de cluster, exécutez kubectl get pour répertorier les objets de machine spécifiques à IaaS, vspherevms et vérifiez leur état IPAddressClaimed. True signifie que la réclamation d'adresse du nœud a réussi et que l'état est False, la sortie de la commande signale la Reason pour laquelle la condition n'est pas prête :
```
kubectl -n CLUSTER-NAMESPACE get vspherevms
```
Pour afficher les réclamations d'adresses IP, répertoriez ipaddressclaims. Pour chaque machine, l'entrée addressesFromPools entraîne la création d'une IPAddressClaim :
```
kubectl -n CLUSTER-NAMESPACE get ipaddressclaims
```
Pour afficher les adresses IP, répertoriez ipaddress. Le fournisseur IPAM de cluster doit détecter chaque IPAddressClaim et créer un objet IPAddress correspondant :
```
kubectl -n CLUSTER-NAMESPACE get ipaddress
```
Lorsque toutes les réclamations d'une machine virtuelle donnée ont été mises en correspondance avec des adresses IP, CAPV écrit les adresses IP attribuées dans les métadonnées cloud-init de la machine virtuelle et crée la machine virtuelle. Pour voir les étapes de rapprochement des adresses IP, reportez-vous aux journaux de CAPV et du fournisseur IPAM d'API de cluster (CAIP) :
```
kubectl logs -n capv-system capv-controller-manager
kubectl logs -n caip-in-cluster-system capi-in-cluster-controller-manager
```

Mise en réseau IPv6 (vSphere)

Vous pouvez exécuter des clusters de gestion et de charge de travail dans un environnement de mise en réseau IPv6 uniquement à pile simple sur vSphere avec Kube-Vip, à l'aide de nœuds basés sur Ubuntu.

Remarques Vous ne pouvez pas créer de clusters IPv6 avec un cluster superviseur vSphere with Tanzu. Vous ne pouvez pas enregistrer des clusters IPv6 dans Tanzu Mission Control. Les services NSX Advanced Load Balancer et la mise en réseau IPv4/IPv6 à double pile ne sont actuellement pas pris en charge.

Conditions préalables :

Configurez vSphere pour les adresses IPv6 accessibles par le cluster de démarrage.
Configurez le programme de résolution DNS dans le démon Docker avec une adresse IPv6 accessible par le cluster de démarrage.
Si les clusters IPv6 doivent atteindre un réseau IPv4, comme c'est le cas, configurez un proxy HTTP comme décrit dans la Configuration de proxy.

Déployer un cluster de gestion IPv6

Procédez comme suit sur votre machine de démarrage pour déployer un cluster de gestion dans un environnement de mise en réseau IPv6 :

Configurez Linux pour accepter les annonces du routeur afin de vous assurer que la route IPv6 par défaut n'est pas supprimée de la table de routage lors du démarrage du service Docker. Pour plus d'informations, reportez-vous à la page Docker CE deletes IPv6 Default route. sudo sysctl net.ipv6.conf.eth0.accept_ra=2
Créez une règle de masquage pour le cluster de démarrage afin d'envoyer le trafic sortant à partir du cluster de démarrage : sudo ip6tables -t nat -A POSTROUTING -s fc00:f853:ccd:e793::/64 ! -o docker0 -j MASQUERADE Pour plus d'informations sur les règles de masquage, reportez-vous à la page MASQUERADE.
Définissez les variables suivantes dans le fichier de configuration pour le cluster de gestion.
- Définissez TKG_IP_FAMILY sur ipv6.
- Définissez VSPHERE_CONTROL_PLANE_ENDPOINT sur une adresse IPv6 statique.
- (Facultatif) Définissez CLUSTER_CIDR and SERVICE_CIDR. Les valeurs par défaut sont fd00:100:64::/48 et fd00:100:96::/108 respectivement.
Déployez le cluster de gestion en exécutant tanzu mc create, comme décrit dans la section Déployer des clusters de gestion à partir d'un fichier de configuration.
- Pour la prise en charge d'IPv6, vous devez déployer le cluster de gestion à partir d'un fichier de configuration, et non à l'aide de l'interface du programme d'installation.

Déployer un cluster de charge de travail IPv6

Si vous avez déployé un cluster de gestion IPv6, déployez un cluster de charge de travail IPv6 comme suit :

Définissez les variables suivantes dans le fichier de configuration pour le cluster de charge de travail.
- Définissez TKG_IP_FAMILY sur ipv6.
- Définissez VSPHERE_CONTROL_PLANE_ENDPOINT sur une adresse IPv6 statique.
- (Facultatif) Définissez CLUSTER_CIDR and SERVICE_CIDR. Les valeurs par défaut sont fd00:100:64::/48 et fd00:100:96::/108 respectivement.
Déployez les clusters de charge de travail comme décrit dans la section Créer des clusters de charge de travail.

Clusters à double pile (version d'évaluation technique)

Remarque
Cette fonctionnalité est dans l'état Version d'évaluation technique non pris en charge. Reportez-vous à la section États des fonctionnalités TKG.

La fonctionnalité de double pile vous permet de déployer des clusters avec des familles d'adresses IP IPv4 et IPv6. Toutefois, la famille d'adresses IP principale est IPv4. Avant d'expérimenter cette fonctionnalité, configurez votre instance de vCenter Server afin de prendre en charge la connectivité IPv4 et IPv6.

Les limitations de la fonctionnalité de double pile dans cette version sont les suivantes :

La fonctionnalité de double pile prend en charge vSphere comme produit IaaS (infrastructure en tant que service) unique.
Vous ne pouvez pas configurer la double pile sur les clusters avec des nœuds Photon OS. Seuls les clusters configurés avec un OS_NAME correspondant à ubuntu sont pris en charge.
Vous ne pouvez pas configurer la mise en réseau à double pile pour les clusters superviseurs vSphere with Tanzu ou les clusters de charge de travail qu'ils créent.
Vous ne pouvez pas déployer un cluster de gestion à double pile avec l'interface du programme d'installation.
Vous ne pouvez pas utiliser les services à double pile ou IPv6 sur les services d'équilibrage de charge fournis par NSX Advanced Load Balancer (ALB). Vous pouvez utiliser kube-vip en tant que fournisseur de point de terminaison de plan de contrôle pour un cluster à double pile. L'utilisation de NSX ALB en tant que fournisseur de point de terminaison de plan de contrôle pour un cluster à double pile n'a pas été validée.
Seuls les composants complémentaires de base (tels qu'Antrea, Calico, CSI, CPI et Pinniped) ont été validés pour la prise en charge de la double pile dans cette version.

Pour configurer la double pile sur les clusters :

Définissez l'indicateur de fonctionnalité de la double pile :

a. Pour activer la fonctionnalité sur le cluster de gestion, exécutez la commande suivante :
```
tanzu config set features.management-cluster.dual-stack-ipv4-primary true
```
b. Pour activer la fonctionnalité sur le cluster de charge de travail, exécutez la commande suivante :
```
tanzu config set features.cluster.dual-stack-ipv4-primary true
```
Vous pouvez Déployer des clusters de gestion ou Créer des clusters de charge de travail, si nécessaire.

Dans le fichier de configuration du cluster :
- Définissez la variable de configuration de la famille d'adresses IP TKG_IP_FAMILY: ipv4,ipv6.
- Vous pouvez éventuellement définir les CIDR de service et les CIDR de cluster.
Remarque
Il existe deux CIDR pour chaque variable. Les familles d'adresses IP de ces CIDR suivent l'ordre de la TKG_IP_FAMILY configurée. La plus grande plage CIDR autorisée pour les adresses IPv4 est /12 et la plage de SERVICE_CIDR IPv6 la plus grande est /108. Si vous ne définissez pas les CIDR, les valeurs par défaut sont utilisées.
- Définissez le paramètre de fichier de configuration suivant, si vous utilisez Antrea comme CNI pour votre cluster :
```
ANTREA_ENDPOINTSLICES: true
```
Les services qui disposent d'une ipFamilyPolicy spécifiée dans leurs spécifications de PreferDualStack ou RequireDualStack sont désormais accessibles via IPv4 ou IPv6.

Remarque
Les tests de bout en bout pour la fonctionnalité de double pile dans Kubernetes en amont peuvent échouer, car un nœud de cluster annonce uniquement son adresse IP principale (dans ce cas, l'adresse IPv4) en tant qu'adresse IP.