Sie können einen Tanzu Kubernetes-Cluster (TanzuKubernetesCluster) mit routingfähigen Pods-Netzwerken erstellen, indem Sie ein routingfähiges Namespace-Netzwerk auf Supervisor konfigurieren und antrea-nsx-routed als CNI für den Cluster angeben.

Informationen zum Netzwerk von routingfähigen Pods

Wenn Sie einen Tanzu Kubernetes-Cluster mithilfe der Plug-Ins antrea oder calico bereitstellen, erstellt das System das Standardnetzwerk für Pods 192.168.0.0/16. Dieses Subnetz ist ein privater Adressbereich, der nur innerhalb des Clusters eindeutig und nicht im Netzwerk routingfähig ist.

Die TKG-v1alpha3-API unterstützt routingfähige Pod-Netzwerke mithilfe des antrea-nsx-routed-CNI-Plug-Ins. Diese Netzwerkschnittstelle ist ein angepasstes Antrea-Plug-In, das zur Unterstützung routingfähiger Pod-Netzwerke für TKG-Cluster konfiguriert ist. In der Clusterspezifikation muss das Feld „pods CIDR blocks“ explizit Null sein, damit die IP-Adressenverwaltung (IP Address Management, IPAM) vom Supervisor verarbeitet wird. Weitere Informationen finden Sie in dem folgenden Beispiel.

Durch die Aktivierung eines routingfähigen Pod-Netzwerks können Pods direkt von einem Client adressiert werden, der sich außerhalb des Clusters befindet. Darüber hinaus werden Pod-IP-Adressen beibehalten, sodass externe Netzwerkdienste und -server die Quell-Pods identifizieren und Richtlinien basierend auf IP-Adressen anwenden können. Unterstützte Datenverkehrsmuster, einschließlich der folgenden:
  • Der Datenverkehr ist zwischen einem TKG-Cluster-Pod und einem vSphere Pod in demselben vSphere-Namespace zulässig.
  • Der Datenverkehr wird zwischen einem TKG-Cluster-Pod und einem vSphere Pod in demselben vSphere-Namespaces gelöscht.
  • Knoten der Supervisor-Steuerungsebene können TKG-Cluster-Pods erreichen.
  • TKG-Cluster-Pods können das externe Netzwerk erreichen.
  • Externes Netzwerk kann TKG-Cluster-Pods nicht erreichen. Der Datenverkehr wird von den Isolierungsregeln der verteilten Firewall (DFW) auf den Clusterknoten verworfen.

Erstellen eines routingfähigen Pod-Netzwerks: Supervisor-Konfiguration

Zum Erstellen eines routingfähigen Pod-Netzwerks ist eine Konfiguration auf dem Supervisor und im TKG-Cluster erforderlich.
Hinweis: Supervisor muss mit NSX konfiguriert werden, um routingfähige Pods-Netzwerke zu verwenden. Sie können keine routingfähigen Pods mit dem VDS-Netzwerk verwenden.
So konfigurieren Sie ein routingfähiges Pod-Netzwerk auf Supervisor:
  1. Erstellen Sie einen neuen vSphere-Namespace.

    Weitere Informationen finden Sie unter Erstellen eines vSphere-Namespace für das Hosting von TKG-Dienst-Clustern.

  2. Aktivieren Sie das Kontrollkästchen Supervisor-Netzwerkeinstellungen außer Kraft setzen.

    Weitere Informationen finden Sie unter Überschreiben der Einstellungen für das Arbeitslastennetzwerk für einen vSphere-Namespace.

  3. Konfigurieren Sie das routingfähige Pod-Netzwerk wie folgt.
    Bereich Beschreibung
    NAT-Modus Da Sie ein routingfähiges Subnetz verwenden, deaktivieren Sie diese Option, um die Netzwerkadressübersetzung (Network Address Translation, NAT) zu deaktivieren.
    Namespace-Netzwerk-CIDR

    Das Namespace-Netzwerk-CIDR ist ein Subnetz, das als IP-Pool für den vSphere-Namespace betrieben wird. Mit dem Namespace-Subnetzpräfix wird die Größe eines beliebigen nachfolgenden CIDR-Blocks beschrieben, der aus diesem IP-Pool entfernt wird.

    Befüllen Sie dieses Feld mit einem routingfähigen IP-Subnetz im Format „IP-Adresse/Bit“ (z. B. 10.0.0.6/16). NCP erstellt einen oder mehrere IP-Pools aus den für das Netzwerk angegebenen IP-Blöcken.

    Sie sollten mindestens eine /23-Subnetzgröße angeben. Wenn Sie beispielsweise ein routingfähiges /23-Subnetz mit einem /28-Subnetzpräfix angeben, erhalten Sie 32 Subnetze, die für einen Cluster mit 6 Knoten ausreichen sollten. Ein /24-Subnetz mit einem /28-Präfix ergibt nur 2 Subnetze, die nicht ausreichen.
    Namespace-Subnetzpräfix

    Mit dem Namespace-Subnetzpräfix wird die Größe eines beliebigen nachfolgenden CIDR-Blocks beschrieben, der aus diesem IP-Pool des Namespace-Netzwerks entfernt wird.

    Geben Sie beispielsweise ein Subnetzpräfix im Format „/28“ an.

  4. Klicken Sie auf Erstellen, um ein Netzwerk routingfähiger Pods zu erstellen.

Erstellen eines routingfähigen Pod-Netzwerks: TKG-Clusterkonfiguration

Die folgende Beispiel-YAML zeigt, wie ein Cluster mit einem Netzwerk routingfähiger Pods konfiguriert wird.

Die Clusterspezifikation deklariert antrea-nsx-routed als CNI, um Netzwerke routingfähiger Pods zu aktivieren. Wenn antrea-nsx-routed angegeben ist, schlägt die Clusterbereitstellung fehl, wenn kein NSX-T-Netzwerk verwendet wird.

Wenn die CNI als „ antrea-nsx-routed“ angegeben ist, muss das Feld „ pods.cidrBlock“ leer sein. 
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesCluster
metadata:
  name: tkc-routable-pods
  namespace: tkg-cluster-ns
spec:
  topology:
    controlPlane:
      replicas: 3
      vmClass: guaranteed-medium
      storageClass: tkg-storage-policy
      tkr:  
        reference:
          name: v1.25.7---vmware.3-fips.1-tkg.1
    nodePools:
    - name: worker-nodepool-a1
      replicas: 3
      vmClass: guaranteed-large
      storageClass: tkg-storage-policy
      tkr:  
        reference:
          name: v1.25.7---vmware.3-fips.1-tkg.1
  settings:
    storage:
      defaultClass: tkg-storage-policy
    network:
      #antrea-nsx-routed is the required CNI
      cni:
        name: antrea-nsx-routed
      services:
        cidrBlocks: ["10.97.0.0/24"]
      #pods.cidrBlocks must be null (empty)
      pods:
        cidrBlocks:
      serviceDomain: cluster.local