In diesem Thema wird beschrieben, wie Sie das Pod- und Containernetzwerk für Arbeitslastcluster anpassen, einschließlich der Verwendung einer anderen Cluster-Netzwerkschnittstelle (CNI) als der Antrea-Standardschnittstelle und der Unterstützung von öffentlich routingfähigen No-NAT-IP-Adressen für Arbeitslastcluster auf vSphere mit VMware NSX-Netzwerk.
Wenn Sie einen Arbeitslastcluster mit der Tanzu CLI bereitstellen, wird automatisch eine Antrea-Clusternetzwerkschnittstelle (CNI) im Cluster aktiviert. Alternativ können Sie die Calico-CNI oder Ihren eigenen CNI-Anbieter aktivieren.
Da automatisch verwaltete Pakete von Tanzu Kubernetes Grid verwaltet werden, müssen Sie deren Konfigurationen in der Regel nicht aktualisieren. Sie sollten jedoch einen Arbeitslastcluster erstellen, der eine benutzerdefinierte CNI wie z. B. Calico verwendet. Die folgenden Abschnitte enthalten die Schritte zum Konfigurieren einer benutzerdefinierten CNI wie Calico.
Für Arbeitslastcluster, die von einem eigenständigen Verwaltungscluster mit einer Tanzu Kubernetes Grid-Version vor 1.2.x bereitgestellt wurden und dann auf v1.3 aktualisiert werden, wird als CNI-Anbieter weiterhin Calico verwendet. Sie können den CNI-Anbieter für diese Cluster nicht ändern.
Durch Angabe der Variablen CNI
in der Konfigurationsdatei können Sie die Standard-CNI für einen Arbeitslastcluster ändern, den Sie aus einem eigenständigen Verwaltungscluster bereitstellen. Die Variable CNI
unterstützt die folgenden Optionen:
antrea
: Aktiviert Antrea.calico
: Aktiviert Calico. Siehe Calico-CNI. Diese Option wird auf Windows nicht unterstützt.none
: Ermöglicht Ihnen, einen benutzerdefinierten CNI-Anbieter zu aktivieren. Siehe Benutzerdefinierte CNI.Wenn Sie die Variable CNI
nicht festlegen, ist Antrea standardmäßig aktiviert.
Um Calico in einem Arbeitslastcluster zu aktivieren, geben Sie Folgendes in der Konfigurationsdatei an:
CNI: calico
Nach Abschluss des Clustererstellungsvorgangs können Sie den Cluster wie unter Herstellen einer Verbindung zu und Untersuchen von Arbeitslastclustern beschrieben untersuchen.
Führen Sie die folgenden Schritte aus, um einen anderen benutzerdefinierten CNI-Anbieter als Calico in einem Arbeitslastcluster zu aktivieren:
Geben Sie beim Erstellen des Clusters CNI: none
in der Konfigurationsdatei an. Beispiel:
CNI: none
Der Clustererstellungsvorgang ist erst erfolgreich, wenn Sie eine CNI auf den Cluster anwenden. Den Clustererstellungsprozess können Sie in den Cluster-API-Protokollen auf dem Verwaltungscluster überwachen. Anweisungen zum Zugriff auf die Cluster-API-Protokolle finden Sie unter Protokolle und Überwachung.
Nachdem der Cluster initialisiert wurde, wenden Sie Ihren CNI-Anbieter auf den Cluster an:
Rufen Sie die admin
-Anmeldedaten des Clusters ab. Beispiel:
tanzu cluster kubeconfig get my-cluster --admin
Legen Sie den Kontext von kubectl
auf den Cluster fest. Beispiel:
kubectl config use-context my-cluster-admin@my-cluster
Wenden Sie den CNI-Anbieter auf den Cluster an:
kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
tanzu cluster list
. Wenn die Clustererstellung abgeschlossen ist, ändert sich der Clusterstatus von creating
in running
. Weitere Informationen zur Untersuchung Ihres Clusters finden Sie unter Herstellen einer Verbindung zu und Untersuchen von Arbeitslastclustern.Um calico
anstelle von antrea
auf einem klassenbasierten Cluster zu installieren, der von einem Supervisor oder als Einzelknoten-Arbeitslastcluster durch einen eigenständigen Verwaltungscluster bereitgestellt wird, müssen Sie zuerst das Objekt ClusterBootstrap
des Clusters wie folgt anpassen:
Erstellen Sie eine YAML-Datei, die die folgenden Kubernetes-Objekte enthält:
apiVersion: cni.tanzu.vmware.com/v1alpha1
kind: CalicoConfig
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
calico:
config:
vethMTU: 0
---
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: ClusterBootstrap
metadata:
annotations:
tkg.tanzu.vmware.com/add-missing-fields-from-tkr: TKR-VERSION
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
additionalPackages: # Customize additional packages
- refName: metrics-server*
- refName: secretgen-controller*
- refName: pinniped*
cni:
refName: calico*
valuesFrom:
providerRef:
apiGroup: cni.tanzu.vmware.com
kind: CalicoConfig
name: CLUSTER-NAME
Dabei gilt:
CLUSTER-NAME
ist der Name des Arbeitslastclusters, den Sie erstellen möchten.CLUSTER-NAMESPACE
ist der Namespace des Arbeitslastclusters.TKR-VERSION
ist die Version des Tanzu Kubernetes-Release (TKr), das Sie für den Arbeitslastcluster verwenden möchten. Beispiel:
v1.23.5+vmware.1-tkg.1
für einen vom Supervisor bereitgestellten Cluster oderv1.25.7---vmware.1-tiny.1-tkg.1
für einen Einzelknotencluster, wie unter Einzelknotencluster auf vSphere (Tech Preview) beschriebenLöschen Sie bei Einzelknotenclustern den Block spec.additionalPackages
aus der Definition ClusterBootstrap
. Einzelknotencluster verfügen nicht über die zusätzlichen Pakete metrics-server
, secretgen-controller
und pinniped
.
Wenden Sie die Datei an, indem Sie den Befehl kubectl apply -f
für den Verwaltungscluster ausführen, unabhängig davon, ob es sich um einen Supervisor oder einen eigenständigen Verwaltungscluster handelt.
Erstellen Sie eine YAML-Datei mit der folgenden Konfiguration für das Cluster
-Objekt:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
clusterNetwork:
services:
cidrBlocks: ["SERVICES-CIDR"]
pods:
cidrBlocks: ["PODS-CIDR"]
serviceDomain: "SERVICE-DOMAIN"
topology:
class: tanzukubernetescluster
version: TKR-VERSION
controlPlane:
replicas: 1
workers:
machineDeployments:
- class: node-pool
name: NODE-POOL-NAME
replicas: 1
variables:
- name: vmClass
value: VM-CLASS
# Default storageClass for control plane and node pool
- name: storageClass
value: STORAGE-CLASS-NAME
Dabei gilt:
CLUSTER-NAME
ist der Name des Arbeitslastclusters, den Sie erstellen möchten.CLUSTER-NAMESPACE
ist der Namespace des Arbeitslastclusters.SERVICES-CIDR
ist der CIDR-Block für Dienste. Beispiel: 198.51.100.0/12
.PODS-CIDR
ist der CIDR-Block für Pods. Beispiel: 192.0.2.0/16
.SERVICE-DOMAIN
ist der Name der Dienstdomäne. Beispiel: cluster.local
.TKR-VERSION
ist die Version des TKr, das Sie für den Arbeitslastcluster verwenden möchten. Beispiel: v1.23.5+vmware.1-tkg.1
.NODE-POOL-NAME
ist der Name des Knotenpools für machineDeployments
.VM-CLASS
ist der Name der VM-Klasse, die Sie für Ihren Cluster verwenden möchten. Beispiel: best-effort-small
.STORAGE-CLASS-NAME
ist der Name der Speicherklasse, die Sie für Ihren Cluster verwenden möchten. Beispiel: wcpglobal-storage-profile
.Beispiel:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: my-workload-cluster
namespace: my-workload-cluster-namespace
spec:
clusterNetwork:
services:
cidrBlocks: ["198.51.100.0/12"]
pods:
cidrBlocks: ["192.0.2.0/16"]
serviceDomain: "cluster.local"
topology:
class: tanzukubernetescluster
version: v1.23.5+vmware.1-tkg.1
controlPlane:
replicas: 1
workers:
machineDeployments:
- class: node-pool
name: my-node-pool
replicas: 1
variables:
- name: vmClass
value: best-effort-small
# Default storageClass for control plane and node pool
- name: storageClass
value: wcpglobal-storage-profile
Erstellen Sie den Arbeitslastcluster, indem Sie die Cluster
-Objektdefinitionsdatei, die Sie im obigen Schritt erstellt haben, an die Option -f
des Befehls tanzu cluster create
übergeben.
So installieren Sie calico
anstelle von antrea
auf einem von Supervisor bereitgestellten Arbeitslastcluster vom Typ TanzuKubernetesCluster
: Legen Sie die CNI
-Konfigurationsvariable in der Clusterkonfigurationsdatei fest, die Sie zum Erstellen des Arbeitslastclusters verwenden möchten, und übergeben Sie die Datei dann an die -f
-Option des Befehls tanzu cluster create
. Beispiel: CNI: calico
.
Um mehrere CNI-Anbieter auf einem Arbeitslastcluster zu aktivieren, wie z. B. macvlan, ipvlan, SR-IOV oder DPDK, installieren Sie das Multus-Paket auf einem Cluster, auf dem bereits Antrea oder Calico CNI ausgeführt wird, und erstellen Sie zusätzliche NetworkAttachmentDefinition
-Ressourcen für CNIs. Dann können Sie neue Pods im Cluster erstellen, die unterschiedliche Netzwerkschnittstellen für verschiedene Adressbereiche verwenden.
Eine Anleitung hierzu finden Sie unter Bereitstellen von Multus auf Arbeitslastclustern.
Auf vSphere mit NSX-Netzwerken und der Antrea-Container-Netzwerkschnittstelle (CNI) können Sie Arbeitslastcluster mit routingfähigen IP-Adressen für ihre Worker-Pods konfigurieren. Dabei wird die Netzwerkadressübersetzung (Network Address Translation, NAT) für externe Anforderungen von und zu den Pods umgangen.
Mit routingfähigen IP-Adressen auf Pods haben Sie folgende Möglichkeiten:
So konfigurieren Sie NSX für die Unterstützung routingfähiger IP-Adressen für Worker-Pods:
Navigieren Sie zu Ihrem NSX-Server und öffnen Sie die Registerkarte Netzwerk (Networking).
Klicken Sie unter Verbindung (Connectivity) > Tier-1-Gateways (Tier-1 Gateways) auf Tier-1-Gateway hinzufügen (Add Tier-1 Gateway) und konfigurieren Sie ein neues Tier-1-Gateway für Pods mit routingfähiger IP:
Klicken Sie auf Speichern (Save), um das Gateway zu speichern.
Klicken Sie unter Verbindung (Connectivity) > Segmente (Segments) auf Segment hinzufügen (Add Segment) und konfigurieren Sie ein neues NSX-Segment, einen logischen Switch, für die Arbeitslastclusterknoten, die die routingfähigen Pods enthalten:
tz-overlay
.195.115.4.1/24
. Dieser Bereich darf sich nicht mit den Werten der Server-IP-Adresse des DHCP-Profils überschneiden.Klicken Sie auf Speichern (Save), um das Gateway zu speichern.
Informationen zum Bereitstellen eines TKC-Clusters mit Worker-Pods mit routingfähigen IP-Adressen ohne NAT finden Sie unter v1beta1-Beispiel: Cluster mit routingfähigem Pod-Netzwerk.
Um einen eigenständigen Verwaltungscluster für die Bereitstellung eines Arbeitslastclusters mit Worker-Pods mit routingfähigen IP-Adressen ohne NAT zu verwenden, gehen Sie wie folgt vor: Die Einstellung CLUSTER_CIDR
des Clusters konfiguriert den Bereich seiner öffentlich routingfähigen IP-Adressen.
Erstellen Sie eine Konfigurationsdatei für den Arbeitslastcluster, wie unter Erstellen einer Arbeitslastcluster-Konfigurationsdatei beschrieben. Gehen Sie dabei wie folgt vor:
CLUSTER_CIDR
in der Konfigurationsdatei des Arbeitslastclusters fest odertanzu cluster create
eine Einstellung CLUSTER_CIDR=
voran, wie im folgenden Schritt gezeigt.NSXT_POD_ROUTING_ENABLED
auf "true"
fest.NSXT_MANAGER_HOST
auf Ihre NSX Manager-IP-Adresse fest.NSXT_ROUTER_PATH
auf den Bestandspfad des neu hinzugefügten Tier-1-Gateways für routingfähige IPs fest. Rufen Sie diesen über NSX Manager > Verbindung (Connectivity) > Tier-1-Gateways (Tier-1 Gateways) ab, indem Sie links neben dem Gateway-Namen auf das Menüsymbol () klicken und auf Pfad in die Zwischenablage kopieren (Copy Path to Clipboard) klicken. Der Name beginnt mit "/infra/tier-1s/
NSXT_
-Zeichenfolgenvariablen für den Zugriff auf NSX fest, indem Sie die Tabelle NSX-Pod-Routing in der Variablenreferenz für Konfigurationsdatei verwenden. Pods können sich bei NSX auf vier Arten authentifizieren, wobei die am wenigsten sichere zuletzt aufgeführt ist:
NSXT_CLIENT_CERT_KEY_DATA
, NSXT_CLIENT_CERT_KEY_DATA
und für ein von einer Zertifizierungsstelle ausgestelltes Zertifikat NSXT_ROOT_CA_DATA_B64
fest.NSXT_VMC_AUTH_HOST
und NSXT_VMC_ACCESS_TOKEN
fest.NSXT_SECRET_NAMESPACE
, NSXT_SECRET_NAME
, NSXT_USERNAME
und NSXT_PASSWORD
fest.NSXT_USERNAME
und NSXT_PASSWORD
fest.Führen Sie tanzu cluster create
aus, wie in Erstellen von Arbeitslastclustern beschrieben. Beispiel:
$ CLUSTER_CIDR=100.96.0.0/11 tanzu cluster create my-routable-work-cluster -f my-routable-work-cluster-config.yaml
Validating configuration...
Creating workload cluster 'my-routable-work-cluster'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...
So testen Sie routingfähige IP-Adressen für Ihre Arbeitslast-Pods:
Stellen Sie einen Webserver für den routingfähigen Arbeitslastcluster bereit.
Führen Sie kubectl get pods --o wide
aus, um Werte für NAME
, INTERNAL-IP
und EXTERNAL-IP
für Ihre routingfähigen Pods abzurufen, und stellen Sie sicher, dass die aufgeführten IP-Adressen identisch sind und sich innerhalb des routingfähigen CLUSTER_CIDR
-Bereichs befinden.
Führen Sie kubectl get nodes --o wide
aus, um Werte für NAME
, INTERNAL-IP
und EXTERNAL-IP
für die Arbeitslastclusterknoten abzurufen, die die Pods mit routingfähiger IP enthalten.
Melden Sie sich beim Knoten der Steuerungsebene eines anderen Arbeitslastclusters an:
kubectl config use-context CLUSTER-CONTEXT
aus, um den Kontext in den anderen Cluster zu ändern.kubectl get nodes
aus, um die IP-Adresse des Knotens der Steuerungsebene für den aktuellen Cluster abzurufen.ssh capv@CONTROLPLANE-IP
mit der IP-Adresse aus, die Sie soeben abgerufen haben.ping
aus und senden Sie curl
-Anforderungen an die routingfähige IP-Adresse, an die Sie den Webserver bereitgestellt haben, und bestätigen Sie die Antworten.
ping
-Ausgabe sollte die routingfähige Pod-IP des Webservers als Quelladresse auflisten.Melden Sie sich in einem Browser bei NSX an und navigieren Sie zum Tier-1-Gateway, das Sie für Pods mit routingfähiger IP erstellt haben.
Klicken Sie auf Statische Routen (Static Routes) und bestätigen Sie, dass die folgenden Routen innerhalb des routingfähigen CLUSTER_CIDR
-Bereichs erstellt wurden:
Nachdem Sie einen Arbeitslastcluster gelöscht haben, der Pods mit routingfähiger IP enthält, müssen Sie die routingfähigen IP-Adressen möglicherweise freigeben, indem Sie sie vom T1-Router löschen:
Wählen Sie unter NSX Manager > Konnektivität (Connectivity) > Tier-1-Gateways (Tier-1 Gateways) Ihr routingfähiges IP-Gateway aus.
Klicken Sie unter Statische Routen (Static Routes) auf die Anzahl der Routen, um die Liste zu öffnen.
Suchen Sie nach Routen, die den Namen des gelöschten Clusters enthalten, und löschen Sie jede Route über das Menüsymbol () links neben dem Routennamen.
curl -i -k -u 'NSXT_USERNAME:NSXT_PASSWORD' -H 'Content-Type: application/json' -H 'X-Allow-Overwrite: true' -X DELETE https://NSXT_MANAGER_HOST/policy/api/v1/STATIC-ROUTE-PATH
aus, wobei gilt:
NSXT_MANAGER_HOST
, NSXT_USERNAME
und NSXT_PASSWORD
sind Ihre NSX Manager-IP-Adresse und -AnmeldedatenSTATIC_ROUTE_PATH
ist der Pfad, den Sie gerade in die Zwischenablage kopiert haben. Der Name beginnt mit /infra/tier-1s/
und enthält /static-routes/
.Um den Zugriff eines Arbeitslastclusters auf die Verwaltungsschnittstelle von VMware vCenter Server zu beschränken, legen Sie entsprechende Netzwerkrichtlinie für die Antrea- und die Calico-CNIs fest. Wenn Sie diese Richtlinien konfigurieren, wird nur der Datenverkehr gefiltert, der aus dem Containernetzwerk stammt. Die Richtlinien blockieren den Datenverkehr, der von allen Pods mit Ausnahme der Container Storage Interface (CSI)-Pods und der Cloud Provider Interface (CPI)-Pods ausgeht.
Legen Sie die Cluster-Netzwerkrichtlinien für Antrea über die Datei antrea-policy-csi-cpi.yaml
im Arbeitslastcluster fest. Gehen Sie dazu wie folgt vor:
Wechseln Sie in der Tanzu CLI zum Kontext des Arbeitslastclusters:
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
Erstellen Sie die Datei antrea-policy-csi-cpi.yaml
, wie im folgenden Beispiel gezeigt:
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
name: edit-system-tiers
spec:
permission: edit
tiers:
- emergency
- securityops
- networkops
- platform
# application and baseline Tiers are not restricted
---
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlementBinding
metadata:
name: admin-edit-system-tiers
spec:
# Allow only admin to attach Antrea ClusterNetworkPolicy and NetworkPolicy to system Tiers
subjects:
- kind: User
name: admin
tierEntitlement: edit-system-tiers
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
name: vc-ip
spec:
ipBlocks:
- cidr: VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/3.
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
name: csi-cpi-pods
spec:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchExpressions:
- key: k8s-app
operator: In
values: [vsphere-cloud-controller-manager]
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: allow-csi-cpi-egress-vc
spec:
priority: 5
tier: emergency
appliedTo:
- group: csi-cpi-pods
egress:
- action: Pass
to:
- group: vc-ip
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: drop-egress-vc
spec:
priority: 10
tier: emergency
appliedTo:
- namespaceSelector: {} # Selects all Namespaces in the cluster
egress:
- action: Drop
to:
- group: vc-ip
HinweisGeben Sie im Feld
cidr:
die IP-CIDR von vCenter Server ein, z. B.192.168.1.1/32
.
Wenden Sie die Datei an:
kubectl apply -f antrea-policy-csi-cpi.yaml
Legen Sie die Cluster-Netzwerkrichtlinien für Calico über die Datei gnp.yaml
im Arbeitslastcluster fest. Gehen Sie dazu wie folgt vor:
Laden Sie die Binärdatei des Dienstprogramms calicoctl
für Ihr Betriebssystem aus dem Github-Verzeichnis herunter.
Installieren Sie das Dienstprogramm in Ihrem System. Gehen Sie wie folgt vor, um beispielsweise das Dienstprogramm herunterzuladen und in einem Linux-System zu installieren:
wget https://github.com/projectcalico/calico/releases/download/CALICO-VERSION/calicoctl-linux-amd64
mv calicoctl-linux-amd64 calicoctl
chmod +x calicoctl
Wechseln Sie in der Tanzu CLI zum Kontext des Arbeitslastclusters:
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
Erstellen Sie die Datei gnp.yaml
, wie im folgenden Beispiel gezeigt:
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-deny-all
spec:
order: 1000
types:
- Egress
egress:
- action: Allow
destination:
notNets:
- VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.
---
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-allow-csi-cpi
spec:
order: 0
types:
- Egress
egress:
- action: Allow
source:
selector: app == 'vsphere-csi-node' || app == 'vsphere-csi-controller' || k8s-app == 'vsphere-cloud-controller-manager'
destination:
nets:
- VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.
HinweisGeben Sie in den Feldern
notNets:
undnets:
die IP-CIDR von vCenter Server ein. Beispiel:192.168.1.1/32
.
Wenden Sie die Datei an:
./calicoctl apply -f gnp.yaml
Weitere Informationen zu den Selektoroptionen in Calico finden Sie unter EntityRule in der Calico-Dokumentation.
Für Namespaces innerhalb von Clustern, auf denen Kubernetes v1.23 und höher ausgeführt wird, unterstützt TKG die Anwendung von Pod-Sicherheitsrichtlinien vom Typ privileged
, baseline
oder restricted
über den PSA-Controller (Pod Security Admission), wie in Pod-Sicherheitsstandards in der Kubernetes-Dokumentation beschrieben.
Pod-Sicherheitsrichtlinien (POD Security Policies, PSPs) für Knoten wurden in TKG v2.1 als veraltet eingestuft, um deren Veralten in Kubernetes widerzuspiegeln. Informationen zum Migrieren von Pods von PSPs auf den PSA-Controller finden Sie unter Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller.
Standardmäßig sind für Cluster-Namespaces in Kubernetes v1.24 die Pod-Sicherheitsmodi warn
und audit
auf baseline
festgelegt. Hierbei handelt es sich um eine Einstellung ohne Erzwingung. Dies bedeutet, dass bei der Migration auf den PSA-Controller möglicherweise Warnungen zu Pods generiert werden, die die Richtlinie verletzen, die Pods jedoch weiterhin ausgeführt werden.