Vous pouvez configurer un cluster Tanzu Kubernetes pour utiliser la mise en réseau d'espaces routables en spécifiant antrea-nsx-routed en tant que CNI pour votre cluster.

Présentation de la mise en réseau de l'espace routable

Le modèle réseau Kubernetes nécessite qu'un espace dans le réseau de nœud d'un cluster puisse communiquer avec tous les espaces sur tous les nœuds du même cluster sans traduction d'adresse réseau (NAT). Pour répondre à cette exigence, chaque espace Kubernetes reçoit une adresse IP allouée à partir d'un réseau d'espaces dédié.

Lorsque vous provisionnez un cluster Tanzu Kubernetes à l'aide des plug-ins CNI antrea ou calico, le système crée le réseau d'espaces par défaut 192.168.0.0/16. Ce sous-réseau est un espace d'adresses privé unique au sein du cluster et non routable sur Internet. Bien que vous puissiez personnaliser les network.pods.cidrBlocks, le réseau d'espaces ne peut pas être rendu routable à l'aide de ces plug-ins CNI. Pour plus d'informations, consultez API TKGS v1alpha2 pour le provisionnement des clusters Tanzu Kubernetes.

L'API v1alpha2 du Service Tanzu Kubernetes Grid prend en charge la mise en réseau d'espaces routables à l'aide du plug-in CNI antrea-nsx-routed. Cette interface réseau est un plug-in Antrea personnalisé configuré pour prendre en charge les réseaux d'espaces routables pour les clusters Tanzu Kubernetes. Dans la spécification du cluster, le champ des blocs CIDR des espaces doit être explicitement null pour que la gestion d'adresses IP (IPAM) soit gérée par le Cluster superviseur.

L'activation de la mise en réseau d'espaces routables permet aux espaces d'être adressés directement depuis un client externe au cluster. En outre, les adresses IP des espaces sont conservées afin que les services réseau et les serveurs externes puissent identifier les espaces source et appliquer des stratégies basées sur les adresses IP. Modèles de trafic pris en charge, y compris les éléments suivants :
  • Le trafic est autorisé entre un espace de cluster Tanzu Kubernetes et un Espace vSphere dans le même Espace de noms vSphere.
  • Le trafic est abandonné entre un espace de cluster Tanzu Kubernetes et un Espace vSphere dans des Espaces de noms vSphere différents.
  • Les nœuds de plan de contrôle du Cluster superviseur doivent atteindre les espaces de cluster Tanzu Kubernetes.
  • Les espaces de cluster Tanzu Kubernetes doivent atteindre le réseau externe.
  • Le réseau externe ne peut pas atteindre les espaces de cluster Tanzu Kubernetes. Le trafic est abandonné par les règles d'isolation du pare-feu distribué (DFW) sur les nœuds de cluster Tanzu Kubernetes.

Configuration système requise pour les espaces routables

La mise en réseau d'espaces routables nécessite que le Cluster superviseur soit configuré avec NSX-T Data Center. Vous ne pouvez pas utiliser d'espaces routables avec la mise en réseau vSphere vDS native.

Les espaces routables nécessitent l'API v1alpha2 du Service Tanzu Kubernetes Grid. Reportez-vous à la section Conditions requises pour l'utilisation de l'API TKGS v1alpha2.

Exigences de configuration de NSX-T pour les espaces routables

Outre les exigences de base, aucune configuration NSX-T spéciale n'est requise pour utiliser des réseaux d'espaces routables avec des clusters Tanzu Kubernetes. Un environnement vSphere with Tanzu exécutant vSphere U3 avec NSX-T inclut la version NCP pour prendre en charge les réseaux d'espaces routables. Aucune configuration NSX-T supplémentaire n'est nécessaire.

NCP crée un pool d'adresses IP pour le réseau d'espaces routables à partir de l'une des deux sources suivantes :
  • Si le réseau de charge de travail est configuré avec un réseau d'espace de noms, NCP crée un ou plusieurs pools d'adresses IP à partir des blocs d'adresses IP spécifiés pour ce réseau d'espace de noms.
  • Si aucun réseau d'espace de noms n'est spécifié pour le réseau de charge de travail, NCP crée un ou plusieurs pools d'adresses IP à partir du CIDR d'espace du Cluster superviseur.
Pour plus d'informations, reportez-vous à Ajouter des réseaux de charge de travail à un Cluster superviseur configuré avec la mise en réseau VDS et Modifier les paramètres réseau de charge de travail sur un Cluster superviseur configuré avec NSX-T Data Center.

Exigences de configuration du Cluster superviseur pour les espaces routables

Outre les exigences de base, aucune configuration spéciale du Cluster superviseur n'est requise pour utiliser des réseaux d'espaces routables avec des clusters Tanzu Kubernetes.

Si la mise en réseau d'espaces routables est activée comme décrit ci-dessous, le CIDR d'espace du cluster Tanzu Kubernetes est alloué depuis le pool d'adresses IP créé à partir du réseau d'espace de noms ou, à défaut, depuis le CIDR d'espace du Cluster superviseur.

Vous devez vous assurer que le CIDR des services du Cluster superviseur qui alloue les adresses IP des nœuds de cluster ne chevauche pas le CIDR du réseau d'espace de noms ou le CIDR d'espace du Cluster superviseur.

Exemple de configuration de cluster pour les espaces routables

L'exemple de YAML suivant montre comment configurer un cluster avec un réseau d'espaces routables. est une configuration personnalisée permettant d'appeler le Service Tanzu Kubernetes Grid et de provisionner un cluster Tanzu Kubernetes à l'aide de l'API v1alpha2.

La spécification du cluster déclare antrea-nsx-routed comme CNI pour activer la mise en réseau d'espaces routables. Lorsque le CNI est spécifié sur antrea-nsx-routed, le champ pods.cidrBlock doit être vide. Si l'option antrea-nsx-routed est spécifiée, le provisionnement du cluster échouera si la mise en réseau NSX-T n'est pas utilisée.

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-v2-cluster-routable-pods
  namespace: tkgs-cluster-ns
spec:
  topology:
    controlPlane:
      replicas: 3
      vmClass: guaranteed-medium
      storageClass: vwt-storage-policy
      tkr:  
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      vmClass: guaranteed-large
      storageClass: vwt-storage-policy
      tkr:  
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
  settings:
    storage:
      defaultClass: vwt-storage-policy
    network:
      #`antrea-nsx-routed` is the required CNI
      #for routable pods 
      cni:
        name: antrea-nsx-routed
      services:
        cidrBlocks: ["10.97.0.0/24"]
      serviceDomain: tanzukubernetescluster.local
      #`pods.cidrBlocks` value must be empty
      #when `antrea-nsx-routed` is the CNI 
      pods:
        cidrBlocks: