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

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

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.

Le pool d'adresses IP est configuré en tant que subnet, avec des adresses start et end facultatives pour limiter la plage d'adresses dans le CIDR de sous-réseau.

Ce diagramme montre comment IPAM de nœud permet à CAPV de configurer des adresses de nœud statiques à partir de son pool d'adresses IP. Les composants (contour plein) et les définitions de ressources (contour en pointillés) qui sont spécifiques à IPAM de nœud sont affichés en vert.

Boîtes et lignes IPAM de nœud

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 résoudront plus les noms via DHCP dans vCenter
kubectl et la CLI Tanzu installée localement

Limitations

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

Uniquement pour les clusters de charge de travail basés sur une classe déployés par un cluster de gestion sur vSphere.
Aucune prise en charge de nœud Windows.
Uniquement pour l'environnement IPv4, pas IPv6 ou double pile.
Alloue uniquement des adresses de nœud, pas le point de terminaison du plan de contrôle du cluster.
Si vous configurez IPAM de nœud pour un cluster existant, cela ne vérifie pas si son pool d'adresses IP est en conflit avec un pool DHCP déjà utilisé par le cluster.
Cela est dû au fait que les pools d'adresses IP sont spécifiques aux espaces de noms et ne peuvent pas être partagés entre plusieurs espaces de noms.
- Les clusters qui s'exécutent sur plusieurs espaces de noms nécessitent un pool d'adresses IP dans chaque espace de noms, avec des plages d'adresses qui ne se chevauchent pas.
- Pour obtenir des restrictions supplémentaires sur les pools d'adresses IP, reportez-vous à la section Règles de pool ci-dessous.

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

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

Créez une définition d'objet InClusterIPPool 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. Par exemple, pour créer un objet inclusterippool qui réserve la plage de 10.10.10.200 à 10.10.10.250 pour les clusters dans l'espace de noms default :

---
apiVersion: ipam.cluster.x-k8s.io/v1alpha1
kind: InClusterIPPool
metadata:
  name: inclusterippool
  # the namespace where the workload cluster is deployed
  namespace: default
spec:
  # replace the IPs below with what works for your environment
  subnet: 10.10.10.0/24
  gateway: 10.10.10.1
  # start and end are optional fields that restrict the allocatable address range
  # within the subnet
  start: 10.10.10.200
  end: 10.10.10.250

Créez l'objet InClusterIPPool :
```
kubectl apply -f my-ip-pool.yaml
```
Activez la fonctionnalité de serveurs de noms personnalisés dans la configuration de la CLI Tanzu :
```
tanzu config set features.cluster.custom-nameservers true
```

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
WORKER_NODE_NAMESERVERS: 10.10.10.10

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]
  - name: worker
    value:
      network:
        nameservers: [10.10.10.10]

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 mettez pas à jour un objet InClusterIPPool avec un nouveau pool.
- TKG ne mettra pas automatiquement à jour les adresses IP des nœuds qui utilisent le pool et vous devrez recréer le nœud pour libérer son ancienne adresse 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 ou avec un cluster de gestion autonome sur vSphere 8. 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.