Sie können einen Tanzu Kubernetes-Cluster für die Verwendung eines routingfähigen Pod-Netzwerks konfigurieren, indem Sie antrea-nsx-routed als CNI für Ihren Cluster angeben.

Einführung eines routingfähigen Pod-Netzwerks

Das Kubernetes-Netzwerkmodell erfordert, dass ein Pod im Knotennetzwerk eines Clusters ohne Netzwerkadressübersetzung (NAT) mit allen Pods auf allen Knoten im selben Cluster kommunizieren kann. Um diese Anforderung zu erfüllen, wird jedem Kubernetes-Pod eine IP-Adresse zugewiesen, die aus einem dedizierten Pod-Netzwerk zugeteilt wird.

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 Internet routingfähig ist. Obwohl Sie die network.pods.cidrBlocks anpassen können, kann das Pod-Netzwerk mithilfe dieser CNI-Plug-Ins nicht routingfähig sein. Weitere Informationen finden Sie unter TKGS-v1alpha2-API für die Bereitstellung von Tanzu Kubernetes-Clustern.

Die Tanzu Kubernetes Grid-Dienst-v1alpha2-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 Tanzu Kubernetes-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-Cluster verarbeitet wird.

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 Tanzu Kubernetes-Cluster-Pod und einem vSphere Pod in demselben vSphere-Namespace zulässig.
  • Der Datenverkehr wird zwischen einem Tanzu Kubernetes-Cluster-Pod und einem vSphere Pod in demselben vSphere-Namespaces gelöscht.
  • Knoten der Supervisor-Cluster-Steuerungsebene können Tanzu Kubernetes-Cluster-Pods erreichen.
  • Tanzu Kubernetes-Cluster-Pods können das externe Netzwerk erreichen.
  • Externes Netzwerk kann Tanzu Kubernetes-Cluster-Pods nicht erreichen. Der Datenverkehr wird von den Isolierungsregeln der verteilten Firewall (DFW) auf den Tanzu Kubernetes-Clusterknoten verworfen.

Systemvoraussetzungen für routingfähige Pods

Für die Netzwerke routingfähiger Pods muss der Supervisor-Cluster mit NSX-T Data Center konfiguriert werden. Sie können keine routingfähigen Pods mit nativem vSphere-vDS-Netzwerk verwenden.

Für routingfähige Pods ist die Tanzu Kubernetes Grid-Dienst-v1alpha2-API erforderlich. Weitere Informationen finden Sie unter Anforderungen für die Verwendung der TKGS v1alpha2-API.

NSX-T-Konfigurationsanforderungen für routingfähige Pods

Mit Ausnahme der Basisanforderungen ist keine spezielle NSX-T-Konfiguration erforderlich, um routingfähige Pod-Netzwerke mit Tanzu Kubernetes-Clustern zu verwenden. Eine vSphere with Tanzu-Umgebung, in der vSphere U3 mit NSX-T ausgeführt wird, enthält die NCP-Version zur Unterstützung routingfähiger Pods-Netzwerke. Es ist keine zusätzliche NSX-T Konfiguration erforderlich.

NCP erstellt einen IP-Pool für das Netzwerk routingfähiger Pods aus einer von zwei Quellen:
  • Wenn das Arbeitslastnetzwerk mit einem Namespace-Netzwerk konfiguriert ist, erstellt NCP einen oder mehrere IP-Pools aus IP-Blöcken, die für dieses Namespace-Netzwerk angegeben sind.
  • Wenn kein Namespace-Netzwerk für das Arbeitslastnetzwerk angegeben ist, erstellt NCP einen oder mehrere IP-Pools aus dem Supervisor-Cluster-Pod-CIDR.
Weitere Informationen finden Sie unter Hinzufügen von Arbeitslastnetzwerken zu einem mit vDS-Netzwerk konfigurierten Supervisor-Cluster und Ändern der Einstellungen für das Arbeitslastnetzwerk auf einem Supervisor-Cluster, der mit NSX-T Data Center konfiguriert ist.

Supervisor-Cluster-Konfigurationsanforderungen für routingfähige Pods

Mit Ausnahme der Basisanforderungen ist keine spezielle Supervisor-Cluster-Konfiguration erforderlich, um routingfähige Pod-Netzwerke mit Tanzu Kubernetes-Clustern zu verwenden.

Wenn das Netzwerk routingfähiger Pods wie unten beschrieben aktiviert ist, wird das CIDR der Tanzu Kubernetes-Cluster-Pods aus dem IP-Pool zugeteilt, der aus dem Namespace-Netzwerk erstellt wurde, oder, falls nicht, aus dem Supervisor-Cluster-Pod-CIDR.

Sie müssen sicherstellen, dass sich das Supervisor-Cluster-Dienst-CIDR, das die IP-Adressen für Clusterknoten zuweist, nicht mit dem Namespace-Netzwerk-CIDR oder mit dem Supervisor-Cluster-Pod-CIDR überschneidet.

Beispiel für eine Clusterkonfiguration für routingfähige Pods

Die folgende Beispiel-YAML zeigt, wie ein Cluster mit einem Netzwerk routingfähiger Pods konfiguriert wird. ist eine benutzerdefinierte Konfiguration zum Aufrufen des Tanzu Kubernetes Grid-Dienst und zum Bereitstellen eines Tanzu Kubernetes-Clusters mithilfe der v1alpha2-API.

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

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: