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.
| 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
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“ aufvlan20-prod - Virtueller Server „
plant-db00“ im Namensraum „green“ aufvlan21-db - Virtueller Server „
plant-app00“ im Namensraum „red“ aufvlan22-app
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.
-
Starten Sie auf jedem virtuellen Server einen einfachen „ HTTP “-Server.
- Führen Sie unter
198.18.0.20die Datei „darkhttpd /usr/share/doc/bash --daemon“ aus. - Führen Sie unter
198.18.1.20die Datei „darkhttpd /usr/share/doc/bash --daemon“ aus. - Führen Sie unter
198.18.2.20die Datei „darkhttpd /usr/share/doc/bash --daemon“ aus.
- Führen Sie unter
-
Führen Sie unter
198.18.0.20die Datei „curl -v http://198.18.1.20:8080“ aus. -
Führen Sie unter
198.18.1.20die Datei „curl -v http://198.18.0.20:8080“ aus. -
Führen Sie auf dem virtuellen Server „jump“ den Befehl „
curl -v http://198.18.2.20:8080“ aus. -
Starten Sie unter
198.18.1.20einen „iperf3“-Server:iperf3 -s -p 9090. -
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. -
Führe einen Ping von
198.18.1.20an198.18.0.20und umgekehrt durch. -
Führen Sie die vorangegangenen Aufgaben erneut aus, indem Sie
198.18.2.20und 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.