Dieses Thema enthält eine Liste der Netzwerkobjekte, die für einen TKG-Cluster erstellt werden, wenn Sie den Supervisor mit einem NSX-Netzwerk verwenden.

NSX-Netzwerkobjekte für TKG-Cluster

Jeder TKG-Cluster sollte über die folgenden Netzwerkressourcen verfügen: ein virtuelles Netzwerk, eine virtuelle Netzwerkschnittstelle und einen VM-Dienst.

Das System stellt automatisch einen eingebetteten NSX-Lastausgleichsdienst bereit, wenn vSphere IaaS control plane aktiviert ist und eine Supervisor-Instanz bereitgestellt wird. Dieser Lastausgleichsdienst ist für die Supervisor-Steuerungsebene vorgesehen und bietet Zugriff auf den Kubernetes-API-Server.

Wenn Sie einen Kubernetes-Dienst vom Typ „LoadBalancer“ für einen TKG-Cluster erstellen, wird ein eingebetteter NSX-Lastausgleichsdienst für diesen Dienst bereitgestellt.
Netzwerkobjekt Netzwerkressourcen Beschreibung
VirtualNetwork Tier-1-Router und verknüpftes Segment Knotennetzwerk für den Cluster
VirtualNetworkInterface Logischer Port auf Segment Knotennetzwerkschnittstelle für Clusterknoten
VirtualMachineService Nicht verfügbar VirtualMachineService wird erstellt und in einen k8s-Dienst übersetzt.
Dienst Lastausgleichsserver mit VirtualServer-Instanz und zugeordneter Serverpool (Mitgliederpool) Der Kubebernetes-Dienst vom Typ „Lastausgleichsdienst“ wird für den Zugriff auf den TKG-Cluster-API-Server erstellt.
Endpoints Die Endpoint-Mitglieder (Knoten der Steuerungsebene des TKG-Clusters) sollten sich im Mitgliedspool befinden. Ein Endpoint wird erstellt, um alle Steuerungsebenenknoten des TKG-Clusters einzubeziehen.
VirtualMachineService in Supervisor Nicht verfügbar Ein VirtualMachineService wird im Supervisor erstellt und in einen Kubernetes-Dienst im Supervisor übersetzt
Lastausgleichsdienst im Supervisor VirtualServer im TKG-Cluster-Lastausgleichsdienst und ein zugehöriger Mitgliederpool. Der Lastausgleichsdienst wird im Supervisor für den Zugriff auf diesen LB-Diensttyp erstellt
Endpoints im Supervisor Die Endpoint-Mitglieder (TKG-Cluster-Worker-Knoten) sollten sich im Mitgliedspool in NSX befinden. Ein Endpoint wird erstellt, um alle Worker-Knoten des TKG-Clusters einzubeziehen
Lastausgleichsdienst im TKG-Cluster Nicht verfügbar Für den Lastausgleichsdienst im vom Benutzer bereitgestellten TKG-Cluster sollte der Status mit der Lastausgleichsdienst-IP aktualisiert werden

Knotennetzwerk

Für jeden TKG-Cluster müssen die folgenden Netzwerkobjekte und zugeordneten NSX-Ressourcen erstellt worden sein.

Netzwerkobjekt NSX-Ressourcen Beschreibung IPAM
VirtualNetwork Tier-1-Gateway und verknüpftes Segment Knotennetzwerk für den TKG-Cluster SNAT-IP ist zugewiesen
VirtualNetworkInterface Logischer Port auf dem verknüpften Segment Knotennetzwerkschnittstelle für TKG-Clusterknoten Jedem Knoten wird eine IP zugewiesen

Lastausgleichsdienst der Steuerungsebene

Netzwerkobjekt Netzwerkressourcen Beschreibung IPAM
VirtualMachineService Nicht verfügbar VirtualMachineService wird erstellt und in einen Kubernetes-Dienst übersetzt. Enthält die Lastausgleichsdienst-VIP
Dienst Lastausgleichsserver mit VirtualServer-Instanz und zugeordneter Serverpool (Mitgliederpool) Der Kubebernetes-Dienst vom Typ „Lastausgleichsdienst“ wird für den Zugriff auf den TKG-Cluster-API-Server erstellt.

Externe IP ist zugewiesen.
Endpoints Die Endpoint-Mitglieder sind die Knoten der Steuerungsebene des TKG-Clusters und sollten sich im Mitgliedspool befinden. Ein Endpoint wird erstellt, um alle Steuerungsebenenknoten des TKG-Clusters einzubeziehen. Nicht verfügbar

NSX Load Balancer

Für jeden erstellten TKG-Cluster erstellt das System eine einzelne Instanz eines kleinen NSX Load Balancers. Dieser Lastausgleichsdienst enthält die in der folgenden Tabelle aufgeführten Objekte:
Objektnummer Beschreibung
1 Virtueller Server (VS) für den Zugriff auf die Kubernetes-Steuerungsebenen-API auf Port 8443.
1 Serverpool mit den 3 Kubernetes-Steuerungsebenenknoten.
1 VS für HTTP-Ingress-Controller.
1 VS für HTTPS-Ingress-Controller.

NAT-Regeln

Für jeden erstellten TKG-Cluster definiert das System die folgenden NSX-NAT-Regeln auf dem logischen Tier-0-Router:

Objektnummer Beschreibung
1 Für jeden Kubernetes-Namespace erstellte SNAT-Regel, die 1 IP aus dem dynamischen IP-Pool als übersetzte IP-Adresse verwendet.
1 (Nur NAT-Topologie) Für jeden Kubernetes-Cluster erstellte SNAT-Regel, die 1 IP aus dem dynamischen IP-Pool als übersetzte IP-Adresse verwendet. Das Kubernetes-Cluster-Subnetz wird mithilfe einer /24-Netzmaske aus dem IP-Block der Knoten abgeleitet.

DFW-Regeln

Für jeden erstellten TKG-Cluster definiert das System die folgenden NSX Distributed Firewall-Regeln:

Objektnummer Beschreibung
1 DFW-Regel für kube-dns, angewendet auf den logischen CoreDNS-Pod-Port:
1 DFW-Regel für den Validator im Namespace, angewendet auf den logischen Validator-Pod-Port: