Pod- und Containernetzwerke

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.

Erstellen eines Clusters mit einer nicht standardmäßigen CNI

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.

Benutzerdefinierte CNI für vom eigenständigen Verwaltungscluster bereitgestellte Cluster

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:

• (Standard) 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.

Calico-CNI

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.

Benutzerdefinierte CNI

Führen Sie die folgenden Schritte aus, um einen anderen benutzerdefinierten CNI-Anbieter als Calico in einem Arbeitslastcluster zu aktivieren:

1. 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.

2. Nachdem der Cluster initialisiert wurde, wenden Sie Ihren CNI-Anbieter auf den Cluster an:

   1. Rufen Sie die admin-Anmeldedaten des Clusters ab. Beispiel:

      tanzu cluster kubeconfig get my-cluster --admin
      

   2. Legen Sie den Kontext von kubectl auf den Cluster fest. Beispiel:

      kubectl config use-context my-cluster-admin@my-cluster
      

   3. Wenden Sie den CNI-Anbieter auf den Cluster an:

      kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
      

3. Überwachen Sie den Status des Clusters mithilfe des Befehls 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.

Calico-CNI für Supervisor- oder klassenbasierte Arbeitslastcluster mit einem Knoten

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:

1. 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 oder
     • v1.25.7---vmware.1-tiny.1-tkg.1 für einen Einzelknotencluster, wie unter Einzelknotencluster auf vSphere (Tech Preview) beschrieben

2. Lö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.

3. 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.

4. 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
   

5. 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.

Calico-CNI für von Supervisor bereitgestellte TKC-basierte Cluster

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.

Aktivieren mehrerer CNI-Anbieter

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.

Bereitstellen von Pods mit routingfähigen No-NAT-IP-Adressen (NSX)

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:

• Verfolgen von ausgehenden Anforderungen an häufige gemeinsam genutzte Dienste, da ihre Quell-IP-Adresse die routingfähige Pod-IP-Adresse und keine NAT-Adresse ist.
• Unterstützen authentifizierter eingehender Anforderungen aus dem externen Internet direkt an Pods unter Umgehung von NAT.

Konfigurieren von NSX für Pods mit routingfähiger IP

So konfigurieren Sie NSX für die Unterstützung routingfähiger IP-Adressen für Worker-Pods:

1. Navigieren Sie zu Ihrem NSX-Server und öffnen Sie die Registerkarte Netzwerk (Networking).

2. 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:

   • Name: Erstellen Sie einen Namen für das T1-Gateway Ihrer routingfähigen Pods.
   • Verknüpftes Tier-0-Gateway (Linked Tier-0 Gateway): Wählen Sie das Tier-0-Gateway aus, das Ihre anderen Tier-1-Gateways für Tanzu Kubernetes Grid verwenden.
   • Edge-Cluster (Edge Cluster): Wählen Sie einen vorhandenen Edge-Cluster aus.
   • Routenankündigung (Route Advertisement): Aktivieren Sie Alle statischen Routen (All Static Routes), Alle NAT-IPs (All NAT IP's) und Alle verbundenen Segmente und Dienstports (All Connected Segments & Service Ports).

   Klicken Sie auf Speichern (Save), um das Gateway zu speichern.

3. 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:

   • Name: Erstellen Sie einen Namen für das Netzwerksegment für die Arbeitslastclusterknoten.
   • Konnektivität (Connectivity): Wählen Sie das soeben erstellte Tier-1-Gateway aus.
   • Transportzone (Transport Zone): Wählen Sie eine Overlay-Transportzone aus, z. B. tz-overlay.
   • Subnetze (Subnets): Wählen Sie einen IP-Adressbereich für Clusterknoten aus, z. B. 195.115.4.1/24. Dieser Bereich darf sich nicht mit den Werten der Server-IP-Adresse des DHCP-Profils überschneiden.
   • Routenankündigung (Route Advertisement): Aktivieren Sie Alle statischen Routen (All Static Routes), Alle NAT-IPs (All NAT IP's) und Alle verbundenen Segmente und Dienstports (All Connected Segments & Service Ports).

   Klicken Sie auf Speichern (Save), um das Gateway zu speichern.

Von Supervisor bereitgestellte TKC-Pods mit routingfähigen IP-Adressen

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.

Vom eigenständigen Verwaltungscluster bereitgestellte Pods mit routingfähigen IP-Adressen

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.

1. Erstellen Sie eine Konfigurationsdatei für den Arbeitslastcluster, wie unter Erstellen einer Arbeitslastcluster-Konfigurationsdatei beschrieben. Gehen Sie dabei wie folgt vor:

   • Wenn Sie den Block von routingfähigen IP-Adressen festlegen, die Worker-Pods zugewiesen sind, können Sie folgende Aktionen ausführen:
     • Legen Sie CLUSTER_CIDR in der Konfigurationsdatei des Arbeitslastclusters fest oder
     • Stellen Sie Ihrem Befehl tanzu cluster create eine Einstellung CLUSTER_CIDR= voran, wie im folgenden Schritt gezeigt.
   • Legen Sie NSXT_POD_ROUTING_ENABLED auf "true" fest.
   • Legen Sie NSXT_MANAGER_HOST auf Ihre NSX Manager-IP-Adresse fest.
   • Legen Sie 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/
   • Legen Sie weitere 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:
     • Zertifikat: Legen Sie 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.
     • VMware Identity Manager-Token auf VMware Cloud (VMC): Legen Sie NSXT_VMC_AUTH_HOST und NSXT_VMC_ACCESS_TOKEN fest.
     • Benutzername/Kennwort, gespeichert in einem geheimen Kubernetes-Schlüssel: Legen Sie NSXT_SECRET_NAMESPACE, NSXT_SECRET_NAME, NSXT_USERNAME und NSXT_PASSWORD fest.
     • Benutzername/Kennwort, als Klartext in der Konfigurationsdatei: Legen Sie NSXT_USERNAME und NSXT_PASSWORD fest.

2. 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...
   

Validieren von routingfähigen IPs

So testen Sie routingfähige IP-Adressen für Ihre Arbeitslast-Pods:

1. Stellen Sie einen Webserver für den routingfähigen Arbeitslastcluster bereit.

2. 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.

3. 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.

4. Melden Sie sich beim Knoten der Steuerungsebene eines anderen Arbeitslastclusters an:

   1. Führen Sie kubectl config use-context CLUSTER-CONTEXT aus, um den Kontext in den anderen Cluster zu ändern.
   2. Führen Sie kubectl get nodes aus, um die IP-Adresse des Knotens der Steuerungsebene für den aktuellen Cluster abzurufen.
   3. Führen Sie ssh capv@CONTROLPLANE-IP mit der IP-Adresse aus, die Sie soeben abgerufen haben.
   4. Führen Sie 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.
      • Die ping-Ausgabe sollte die routingfähige Pod-IP des Webservers als Quelladresse auflisten.

5. 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.

6. Klicken Sie auf Statische Routen (Static Routes) und bestätigen Sie, dass die folgenden Routen innerhalb des routingfähigen CLUSTER_CIDR-Bereichs erstellt wurden:

   1. Eine Route für Pods im Knoten der Steuerungsebene des Arbeitslastclusters, wobei Nächste Hops (Next Hops) als Adresse des Knotens der Steuerungsebene selbst angezeigt wird.
   2. Eine Route für Pods in den Worker-Knoten des Arbeitslastclusters, wobei Nächste Hops (Next Hops) als Adressen der Worker-Knoten selbst angezeigt wird.

Löschen von routingfähigen IPs

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:

1. Wählen Sie unter NSX Manager > Konnektivität (Connectivity) > Tier-1-Gateways (Tier-1 Gateways) Ihr routingfähiges IP-Gateway aus.

2. Klicken Sie unter Statische Routen (Static Routes) auf die Anzahl der Routen, um die Liste zu öffnen.

3. 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.

   1. Wenn ein Berechtigungsfehler Sie daran hindert, die Route aus dem Menü zu löschen, was vorkommen kann, wenn die Route von einem Zertifikat erstellt wird, dann löschen Sie die Route über die API:
      1. Wählen Sie im Menü neben dem Routennamen Pfad in die Zwischenablage kopieren (Copy Path to Clipboard) aus.
      2. Führen Sie 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 -Anmeldedaten
         • STATIC_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/.

Festlegen von Netzwerkrichtlinien für die CNIs

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.

Festlegen von Cluster-Netzwerkrichtlinien für Antrea

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:

1. Wechseln Sie in der Tanzu CLI zum Kontext des Arbeitslastclusters:

   kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
   

2. 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 
   

   Hinweis

   Geben Sie im Feld cidr: die IP-CIDR von vCenter Server ein, z. B. 192.168.1.1/32.

3. Wenden Sie die Datei an:

   kubectl apply -f antrea-policy-csi-cpi.yaml
   

Festlegen von Netzwerkrichtlinien für Calico

Legen Sie die Cluster-Netzwerkrichtlinien für Calico über die Datei gnp.yaml im Arbeitslastcluster fest. Gehen Sie dazu wie folgt vor:

1. Laden Sie die Binärdatei des Dienstprogramms calicoctl für Ihr Betriebssystem aus dem Github-Verzeichnis herunter.

2. 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
   

3. Wechseln Sie in der Tanzu CLI zum Kontext des Arbeitslastclusters:

   kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
   

4. 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.
   

   Hinweis

   Geben Sie in den Feldern notNets: und nets: die IP-CIDR von vCenter Server ein. Beispiel: 192.168.1.1/32.

5. 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.

Zugangscontroller für Pod-Sicherheit (Tech Preview)

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.