Beispiele für Localnet-UDN bei der Virtualisierung von „ Red Hat OpenShift “

Verbinden Sie virtuelle Maschinen (VMs) der „ OpenShift “-Virtualisierung über CUDN-Localnet-Netzwerke mit „ IBM Cloud VPC “-Subnetzen, um VLAN-gestützten, namensraumisolierten Datenverkehr zu ermöglichen.

In diesem Tutorial wird gezeigt, wie Sie eine Beispielanwendung mit dreistufiger Architektur erstellen, indem Sie VPC-Subnetze (Virtual Private Cloud), benutzerdefinierte Cluster-Netzwerke (CUDNs), Localnets und Namespaces auf Red Hat OpenShift on IBM Cloud unter IBM Cloud nutzen. Das Beispiel veranschaulicht, wie virtuelle Server, die auf der Virtualisierungsplattform „ Red Hat OpenShift “ laufen, mithilfe von auf virtuellen lokalen Netzwerken (VLANs) basierenden „localnet“-Netzwerken direkt an VPC-Subnetze angebunden werden können. Weitere Informationen zu Netzwerktypen finden Sie unter „Open Virtual Network(OVN)– Netzwerkkonfiguration“ im Handbuch „ Red Hat OpenShift “ für Administratoren von „ vSphere® “.

Übersicht

In diesem Beispiel wird eine dreischichtige Anwendung mit separaten Netzwerksegmenten für die Web-, Datenbank- und Anwendungsschicht bereitgestellt. Jede Ebene nutzt ein eigenes VPC-Subnetz und ein Localnet-CUDN mit einer eindeutigen VLAN-ID. Die Web- und Datenbankebenen befinden sich in einem Namensraum (green), während die Anwendungsebene in einem separaten Namensraum (red) untergebracht ist, um die namensraumbasierte Isolation zu veranschaulichen.

Angaben zu Netzwerk, Namespace und virtuellem Server

Die folgende Tabelle fasst den Aufbau des Beispielnetzwerks zusammen.

Beispiel für die Struktur von Localnet CUDN, Namespace und virtuellen Servern
Localnet CUDN Namensbereich VLAN-ID VPC-Teilnetz Virtuelle Server
vlan20-prod green 20 198.18.0.0/24 plant-web00, plant-web01
vlan21-db green 21 198.18.1.0/24 plant-db00, plant-db01
vlan22-app red 22 198.18.2.0/24 plant-app00, plant-app01

Schematische Darstellung des endgültigen Aufbaus

Aufbau einer dreistufigen Localnet-Anwendung
Aufbau einer dreistufigen Localnet-Anwendung

Jeder Code-Block in der Anleitung kann in eine Datei kopiert und mit dem Befehl „ oc apply -f <file-name>.yml “ ausgeführt werden. Manche Codeblöcke können in den Formaten PDF und Word Seitengrenzen überschreiten, und manche langen Zeilen können in diesen Formaten umgebrochen werden.

In diesem Leitfaden wird „ ic “ als Kurzform für „ ibmcloud “ in den CLI-Befehlen von „ IBM Cloud “ verwendet. Definieren Sie „ alias ic=ibmcloud “ in Ihrer Shell oder ersetzen Sie in den folgenden Befehlen „ ic “ durch „ ibmcloud “.

Vorbereitende Schritte

Stellen Sie sicher, dass Sie über die folgenden Dinge verfügen:

  • Ein „ IBM Cloud “-Konto mit der Berechtigung zur Verwaltung von VPC- und „ Red Hat OpenShift “-Ressourcen.
  • Die CLI von „ IBM Cloud “ ist installiert.
  • Die Plug-ins „ container-service “ und „ vpc-infrastructure “ sind installiert.

Das Plug-in „ container-service “ stellt die Befehle „ ic ks “ bereit, mit denen der Assistent virtuelle VLAN-Netzwerkschnittstellen (VNIs) an den Cluster anfügt. Das Plug-in „ vpc-infrastructure “ stellt die Befehle „ ic is “ bereit, mit denen der Assistent VPC-Subnetze, virtuelle Netzwerkschnittstellen (VNIs) und andere Infrastrukturkomponenten erstellt.

Wenn Sie die erforderlichen CLI-Plug-ins installieren müssen, verwenden Sie die folgenden Befehle.

ibmcloud plugin install container-service
ibmcloud plugin install vpc-infrastructure

Netzwerkvoraussetzungen prüfen

Wenn Sie „ Red Hat OpenShift on IBM Cloud “ verwenden, lesen Sie bitte zunächst die Netzwerkvoraussetzungen für OVN UDN/CUDN unter Red Hat OpenShift on IBM Cloud durch, bevor Sie beginnen. Der Virtualisierungsdienst „ Red Hat OpenShift “ erfüllt diese Voraussetzungen standardmäßig.

Erstellen eines Namespace und eines sekundären CUDN-Localnet-Netzwerks für die „Green Tier“-Stufe

Localnet-Netzwerke können innerhalb eines Namensraums neben primären Netzwerken vom Typ „ Layer 2 “, sekundären Netzwerken vom Typ „ Layer 2 “ sowie anderen Localnets bestehen. Jedes lokale Netzwerk benötigt einen VLAN ID. Derzeit kann pro VLAN nur ein Subnetz verwendet werden.

Das VLAN schafft keine „ Layer 2 “-Domäne zwischen den Workern. Das VLAN wird innerhalb jedes Worker-Knotens verwendet, nicht innerhalb der VPC.

Erstellen Sie den Namespace „ green “ sowie die Netzwerke „ vlan20-prod “ und „ vlan21-db “. Wenden Sie das Manifest mit dem Befehl „ oc apply -f step1.yml “ an.

---
apiVersion: v1
kind: Namespace
metadata:
  name: green
---
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan20-prod"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "green"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 20
---
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan21-db"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "green"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 21

Beachten Sie bitte Folgendes:

  • Das Subnetz ist in der Konfiguration von „ Localnet “ nicht definiert.
  • Verwenden Sie „ VLAN 1 “ nicht.
  • Verwenden Sie VLANs im Bereich von 2 bis 500. Die VLANs 501 bis 4094 sind derzeit gesperrt.

Erstellen eines weiteren Namespace und eines sekundären CUDN-Localnet-Netzwerks für die rote Ebene

Erstellen Sie den Namespace „ red “ und das Netzwerk „ vlan22-app “. Wenden Sie das Manifest mit dem Befehl „ oc apply -f step2.yml “ an.

---
apiVersion: v1
kind: Namespace
metadata:
  name: red
---
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan22-app"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "red"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 22

Reservierte IP-Adressen und VNIs in Ihrem VPC-Konto erstellen

In diesem Schritt wird in jedem Subnetz eine reservierte IP-Adresse angelegt, anschließend wird anhand dieser reservierten IP-Adresse die VNI erstellt und jeder virtuellen Netzwerkschnittstelle eine „ MAC address “ zugewiesen (VNI).

Beachten Sie bitte Folgendes:

  • Die „ VLAN ID “ wird in diesem Schritt nicht beigefügt.
  • Sie müssen die Sicherheitsgruppe nachschlagen, die Sie in diesem Schritt verwenden möchten. Führen Sie den Befehl „ ic is sgs “ aus, um die verfügbaren Sicherheitsgruppen aufzulisten.
  • Sie können diesen Schritt in einem Sammelvorgang ausführen.
  • Die Obergrenze liegt bei 256 VNIs pro Host. Halten Sie die Auslastung unter 85 %, um Failover und Migrationen von anderen Hosts zu ermöglichen.

Reservierte IP-Adressen in jedem Subnetz anlegen

Erstellen Sie zunächst in jedem Subnetz eine reservierte IP-Adresse für Ihre virtuellen Server:

ic is subnet-reserved-ip-create zone1-vm-prod --address 198.18.0.20 --name zone1-web00 --auto-delete false
ic is subnet-reserved-ip-create zone1-vm-db --address 198.18.1.20 --name zone1-db00 --auto-delete false
ic is subnet-reserved-ip-create zone1-vm-app --address 198.18.2.20 --name zone1-app00 --auto-delete false

Erstellen von VNIs unter Verwendung der reservierten IP-Adressen

Erstellen Sie nun die VNIs unter Verwendung der im vorherigen Schritt reservierten IP-Namen:

ic is virtual-network-interface-create --name zone1-web00 --allow-ip-spoofing false --auto-delete false --protocol-state-filtering-mode disabled --enable-infrastructure-nat true --subnet zone1-vm-prod --vpc my-vpc --rip zone1-web00 --sgs handclap-roundworm-clique-eccentric --resource-group-name Default
ic is virtual-network-interface-create --name zone1-db00 --allow-ip-spoofing false --auto-delete false --protocol-state-filtering-mode disabled --enable-infrastructure-nat true --subnet zone1-vm-db --vpc my-vpc --rip zone1-db00 --sgs handclap-roundworm-clique-eccentric --resource-group-name Default
ic is virtual-network-interface-create --name zone1-app00 --allow-ip-spoofing false --auto-delete false --protocol-state-filtering-mode disabled --enable-infrastructure-nat true --subnet zone1-vm-app --vpc my-vpc --rip zone1-app00 --sgs handclap-roundworm-clique-eccentric --resource-group-name Default

Zuordnung der VLAN-VNI zum Cluster

Rufen Sie die ID für jedes VNI ab, das Sie im vorherigen Schritt erstellt haben, und fügen Sie das VNI anschließend mithilfe des Plug-ins „ IBM Cloud “ ( container-service ) dem Cluster hinzu. Sie benötigen die Cluster-ID, die Sie durch Ausführen von „ ic ks cluster ls “ abrufen können.

Beachten Sie bitte Folgendes:

  • Wenn ein Worker seine VNI-Quote überschreitet, schlägt der zugehörige Vorgang fehl.
  • VNIs können dem Cluster (auch als „ floating “ bezeichnet) oder einem bestimmten Worker zugeordnet werden.

Schlagen Sie die VNI-IDs nach.

ic is vni zone1-web00 | awk '$1 ~ /^ID/ {print $NF}'
ic is vni zone1-db00 | awk '$1 ~ /^ID/ {print $NF}'
ic is vni zone1-app00 | awk '$1 ~ /^ID/ {print $NF}'

Ordnen Sie jede VNI dem Cluster mit der entsprechenden VLAN-ID zu. Ersetzen Sie die Cluster-ID und die VNI-IDs durch die Werte aus Ihrer Umgebung.

ic ks vni attach baremetal -c <CLUSTER_ID> --vni <VNI_ID_web00> --vlan 20
ic ks vni attach baremetal -c <CLUSTER_ID> --vni <VNI_ID_db00>  --vlan 21
ic ks vni attach baremetal -c <CLUSTER_ID> --vni <VNI_ID_app00> --vlan 22

Hinzufügen virtueller Server zu den Namespaces

Das folgende Manifest ist ein einfaches Beispiel für „ YAML “, mit dem ein virtueller Server erstellt wird. Sie können dieses Manifest für jeden Namensraum und jedes Netzwerk aktualisieren. Für jeden von Ihnen erstellten „ VNI “ benötigen Sie den „ MAC address “. Führen Sie den Befehl „ ic is vnis “ aus, um sie aufzulisten, und aktualisieren Sie das Feld „ macAddress “ in der Vorlage, damit „ DHCP “ korrekt funktioniert.

Verwenden Sie die folgenden Befehle, um die „ MAC address “ für jeden „ VNI “ zu ermitteln.

ic is vni zone1-web00 | awk '/^Mac Address/ {print $NF}'
ic is vni zone1-db00  | awk '/^Mac Address/ {print $NF}'
ic is vni zone1-app00 | awk '/^Mac Address/ {print $NF}'

Beispielausgabe für „ VNI “. Eure Werte unterscheiden sich:

02:00:01:00:98:A0
02:00:02:00:98:A5
02:00:02:00:98:AA

Beachten Sie bitte die folgenden Punkte, bevor Sie die Manifeste anwenden:

  • Aktualisieren Sie das Passwort in jedem Manifest.
  • Um sich anzumelden, müssen Sie im Feld „ ssh_authorized_keys “ einen echten öffentlichen SSH-Schlüssel eingeben.
  • Sie können SSH nicht mit einem Passwort verwenden.
  • Ersetzen Sie jeden Wert „ macAddress “ durch die MAC-Adresse der entsprechenden VNI, die Sie in den vorherigen Befehlen ermittelt haben. Der „ macAddress “ muss mit dem VNI übereinstimmen, damit „ DHCP “ die erwartete IP-Adresse zuweist.

Wenden Sie jedes der folgenden Manifeste mit dem Befehl „ oc apply -f <file-name>.yml “ an. Über die folgenden Links gelangen Sie direkt zu den einzelnen Manifesten.

Virtueller Server „ plant-web00 “ im Namensraum „ green “ auf vlan20-prod

# Bare YAML to stand up a Red Hat OpenShift on IBM Cloud virtual machine
---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: "plant-web00"
  namespace: "green"
  annotations:
    description: "example vm plant-web00"
  labels:
    app: "plant-web00-green-server"
    kubevirt.io/dynamic-credentials-support: 'true'
    vm.kubevirt.io/template: "centos-stream9-server-small"
    vm.kubevirt.io/template.namespace: openshift
    vm.kubevirt.io/template.revision: '1'
    vm.kubevirt.io/template.version: v0.34.0
spec:
  dataVolumeTemplates:
    - apiVersion: cdi.kubevirt.io/v1beta1
      kind: DataVolume
      metadata:
        creationTimestamp: null
        name: "plant-web00-green-server"
      spec:
        sourceRef:
          kind: DataSource
          name: "centos-stream9"
          namespace: openshift-virtualization-os-images
        storage:
          resources:
            requests:
              storage: 30Gi
  runStrategy: RerunOnFailure
  template:
    metadata:
      annotations:
        vm.kubevirt.io/flavor: "small"
        vm.kubevirt.io/os: "centos-stream9"
        vm.kubevirt.io/workload: "server"
      labels:
        kubevirt.io/domain: example
        kubevirt.io/size: "small"
    spec:
      domain:
        cpu:
          cores: 1
          sockets: 1
          threads: 1
        devices:
          disks:
            - disk:
                bus: virtio
              name: rootdisk
            - disk:
                bus: virtio
              name: cloudinitdisk
          interfaces:
            - model: virtio
              name: default
              state: up
              bridge: {}
              macAddress: 02:00:01:00:98:A0 # <- replace with the MAC of VNI zone1-web00
          networkInterfaceMultiqueue: true
          rng: {}
        memory:
          guest: "2Gi"
      hostname: "plant-web00"
      networks:
        - name: default
          multus:
            networkName: vlan20-prod
      terminationGracePeriodSeconds: 180
      volumes:
        - dataVolume:
            name: "plant-web00-green-server"
          name: rootdisk
        - cloudInitNoCloud:
            userData: |-
              #cloud-config
              user: admin
              password: "aRandomPassword9292"
              ssh_authorized_keys:
                 - "ssh-ed25519 AAAA....BBBB....CCCCC.....DDDD put-your-key-here@example.local"
              chpasswd: { expire: False }
              runcmd:
                - [ dnf, install, -y, epel-release ]
                - [ dnf, install, -y, iperf3, nmap-ncat, darkhttpd ]
          name: cloudinitdisk

Virtueller Server „ plant-db00 “ im Namensraum „ green “ auf vlan21-db

---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: "plant-db00"
  namespace: "green"
  annotations:
    description: "example vm plant-db00"
  labels:
    app: "plant-db00-green-server"
    kubevirt.io/dynamic-credentials-support: 'true'
    vm.kubevirt.io/template: "centos-stream9-server-small"
    vm.kubevirt.io/template.namespace: openshift
    vm.kubevirt.io/template.revision: '1'
    vm.kubevirt.io/template.version: v0.34.0
spec:
  dataVolumeTemplates:
    - apiVersion: cdi.kubevirt.io/v1beta1
      kind: DataVolume
      metadata:
        creationTimestamp: null
        name: "plant-db00-green-server"
      spec:
        sourceRef:
          kind: DataSource
          name: "centos-stream9"
          namespace: openshift-virtualization-os-images
        storage:
          resources:
            requests:
              storage: 30Gi
  runStrategy: RerunOnFailure
  template:
    metadata:
      annotations:
        vm.kubevirt.io/flavor: "small"
        vm.kubevirt.io/os: "centos-stream9"
        vm.kubevirt.io/workload: "server"
      labels:
        kubevirt.io/domain: example
        kubevirt.io/size: "small"
    spec:
      domain:
        cpu:
          cores: 1
          sockets: 1
          threads: 1
        devices:
          disks:
            - disk:
                bus: virtio
              name: rootdisk
            - disk:
                bus: virtio
              name: cloudinitdisk
          interfaces:
            - model: virtio
              name: default
              state: up
              bridge: {}
              macAddress: 02:00:01:00:98:A5 # <- replace with the MAC of VNI zone1-db00
          networkInterfaceMultiqueue: true
          rng: {}
        memory:
          guest: "2Gi"
      hostname: "plant-db00"
      networks:
        - name: default
          multus:
            networkName: vlan21-db
      terminationGracePeriodSeconds: 180
      volumes:
        - dataVolume:
            name: "plant-db00-green-server"
          name: rootdisk
        - cloudInitNoCloud:
            userData: |-
              #cloud-config
              user: admin
              password: "aRandomPassword9292"
              ssh_authorized_keys:
                 - "ssh-ed25519 AAAA....BBBB....CCCCC.....DDDD put-your-key-here@example.local"
              chpasswd: { expire: False }
              runcmd:
                - [ dnf, install, -y, epel-release ]
                - [ dnf, install, -y, iperf3, nmap-ncat, darkhttpd ]
          name: cloudinitdisk

Virtueller Server „ plant-app00 “ im Namensraum „ red “ auf vlan22-app

---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: "plant-app00"
  namespace: "red"
  annotations:
    description: "example vm plant-app00"
  labels:
    app: "plant-app00-red-server"
    kubevirt.io/dynamic-credentials-support: 'true'
    vm.kubevirt.io/template: "centos-stream9-server-small"
    vm.kubevirt.io/template.namespace: openshift
    vm.kubevirt.io/template.revision: '1'
    vm.kubevirt.io/template.version: v0.34.0
spec:
  dataVolumeTemplates:
    - apiVersion: cdi.kubevirt.io/v1beta1
      kind: DataVolume
      metadata:
        creationTimestamp: null
        name: "plant-app00-red-server"
      spec:
        sourceRef:
          kind: DataSource
          name: "centos-stream9"
          namespace: openshift-virtualization-os-images
        storage:
          resources:
            requests:
              storage: 30Gi
  runStrategy: RerunOnFailure
  template:
    metadata:
      annotations:
        vm.kubevirt.io/flavor: "small"
        vm.kubevirt.io/os: "centos-stream9"
        vm.kubevirt.io/workload: "server"
      labels:
        kubevirt.io/domain: example
        kubevirt.io/size: "small"
    spec:
      domain:
        cpu:
          cores: 1
          sockets: 1
          threads: 1
        devices:
          disks:
            - disk:
                bus: virtio
              name: rootdisk
            - disk:
                bus: virtio
              name: cloudinitdisk
          interfaces:
            - model: virtio
              name: default
              state: up
              bridge: {}
              macAddress: 02:00:01:00:98:AA # <- replace with the MAC of VNI zone1-app00
          networkInterfaceMultiqueue: true
          rng: {}
        memory:
          guest: "2Gi"
      hostname: "plant-app00"
      networks:
        - name: default
          multus:
            networkName: vlan22-app
      terminationGracePeriodSeconds: 180
      volumes:
        - dataVolume:
            name: "plant-app00-red-server"
          name: rootdisk
        - cloudInitNoCloud:
            userData: |-
              #cloud-config
              user: admin
              password: "aRandomPassword9292"
              ssh_authorized_keys:
                 - "ssh-ed25519 AAAA....BBBB....CCCCC.....DDDD put-your-key-here@example.local"
              chpasswd: { expire: False }
              runcmd:
                - [ dnf, install, -y, epel-release ]
                - [ dnf, install, -y, iperf3, nmap-ncat, darkhttpd ]
          name: cloudinitdisk

Überprüfung der Netzwerkkonfiguration

IBM empfiehlt, für diese Tests einen „ Linux® “-Jump-Host in derselben VPC wie der Cluster zu verwenden. Stellen Sie vom Jump-Host aus über SSH eine Verbindung zu jedem virtuellen Server her, und zwar mit dem öffentlichen Schlüssel, den Sie bei der Einrichtung des virtuellen Servers angegeben haben.

Konfigurieren Sie die SSH-Agent-Weiterleitung oder verwenden Sie einen neuen Schlüssel, der auf dem Jump-Host gehostet wird. Kopieren Sie Ihren privaten Schlüssel nicht zwischen verschiedenen Systemen.

Stellen Sie von einer Terminalsitzung aus über SSH eine Verbindung zum virtuellen Server der Web-Ebene her:

ssh admin@198.18.0.20

Stellen Sie von einer anderen Terminalsitzung aus über SSH eine Verbindung zum virtuellen Server der Datenbankebene her:

ssh admin@198.18.1.20

Stellen Sie von einer anderen Terminalsitzung aus über SSH eine Verbindung zum virtuellen Server der Anwendungsschicht her:

ssh admin@198.18.2.20

Tests

Führen Sie die folgenden Tests durch, um die Netzwerkeinrichtung zu überprüfen.

  1. Starten Sie auf jedem virtuellen Server einen einfachen „ HTTP “-Server.

    • Führen Sie unter 198.18.0.20 die Datei „ darkhttpd /usr/share/doc/bash --daemon “ aus.
    • Führen Sie unter 198.18.1.20 die Datei „ darkhttpd /usr/share/doc/bash --daemon “ aus.
    • Führen Sie unter 198.18.2.20 die Datei „ darkhttpd /usr/share/doc/bash --daemon “ aus.
  2. Führen Sie unter 198.18.0.20 die Datei „ curl -v http://198.18.1.20:8080 “ aus.

  3. Führen Sie unter 198.18.1.20 die Datei „ curl -v http://198.18.0.20:8080 “ aus.

  4. Führen Sie auf dem virtuellen Server „jump“ den Befehl „ curl -v http://198.18.2.20:8080 “ aus.

  5. Starten Sie unter 198.18.1.20 einen „ iperf3 “-Server: iperf3 -s -p 9090.

  6. Stellen Sie von „ 198.18.0.20 “ aus eine Verbindung zum Server „ iperf3 “ im Namespace „ green “ her: iperf3 -c 198.18.1.20 -p 9090.

  7. Führe einen Ping von 198.18.1.20 an 198.18.0.20 und umgekehrt durch.

  8. Führen Sie die vorangegangenen Aufgaben erneut aus, indem Sie 198.18.2.20 und die IP-Adresse des virtuellen Jump-Servers verwenden.

Anwendung einer Multi-Netzwerk-Richtlinie und erneute Durchführung der Tests

Wenden Sie eine netzwerkübergreifende Richtlinie an, die für das Netzwerk „ vlan20-prod “ ausschließlich den Port 8080 für „ TCP “ zulässt. Speichern Sie das folgende Manifest in einer Datei mit dem Namen „ my-policy.yml “. Führen Sie anschließend den Befehl „ oc apply -f my-policy.yml “ aus, um die Änderung zu übernehmen.

---
apiVersion: k8s.ovn.org/v1alpha1
kind: MultiNetworkPolicy
metadata:
  name: allow-8080-tcp
  namespace: green
  annotations:
    k8s.v1.cni.cncf.io/policy-for: vlan20-prod
spec:
  podSelector: {}
  ingress:
    - ports:
        - protocol: TCP
          port: 8080
  egress:
    - ports:
        - protocol: TCP
          port: 8080
  policyTypes:
    - Ingress
    - Egress

Führen Sie die Tests erneut unter plant-web00 auf vlan20-prod durch. TCP Port 8080 funktioniert weiterhin, aber anderer Datenverkehr, wie beispielsweise ping und der Test unter iperf3 auf Port 9090, funktioniert über diesen Netzwerkanschluss nicht mehr.

Führen Sie den Befehl „ oc delete -f my-policy.yml “ aus, um die Richtlinie zu entfernen und die Verbindung wiederherzustellen. Die Tests sind wieder erfolgreich.