Freigeben über

Sichern Sie den Datenverkehr zwischen Pods mit Hilfe von Netzwerkrichtlinien in AKS

  • Artikel

Wenn Sie moderne, auf Microservices basierende Anwendungen in Kubernetes ausführen, können Sie steuern, welche Komponenten miteinander kommunizieren können. Auf den Flow des Datenverkehrs zwischen Pods in einem Azure Kubernetes Service -Cluster (AKS) sollte das Prinzip der geringsten Rechte angewendet werden. Nehmen wir an, Sie möchten den Datenverkehr direkt zu Back-End-Anwendungen blockieren. Mit dem Feature Netzwerkrichtlinie in Kubernetes können Sie Regeln für ein- und ausgehenden Datenverkehr zwischen Pods in einem Cluster definieren.

In diesem Artikel wird veranschaulicht, wie Sie das Modul für Netzwerkrichtlinien installieren und Kubernetes-Netzwerkrichtlinien erstellen, um den Datenverkehrsfluss zwischen Pods in AKS zu steuern. Netzwerkrichtlinien können für Linux-basierte oder Windows-basierte Knoten und Pods in AKS verwendet werden.

Übersicht über die Netzwerkrichtlinie

Standardmäßig können alle Pods in einem AKS-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Zur Verbesserung der Sicherheit können Sie Regeln definieren, die den Datenverkehrsfluss steuern. Back-End-Anwendungen werden häufig nur für erforderliche Front-End-Dienste verfügbar gemacht. Oder Datenbankkomponenten sind nur für die Anwendungsebenen zugänglich, die eine Verbindung damit herstellen.

Netzwerkrichtlinie ist eine Kubernetes-Spezifikation, die Zugriffsrichtlinien für die Kommunikation zwischen Pods definiert. Wenn Sie Netzwerkrichtlinien verwenden, definieren Sie einen geordneten Satz von Regeln zum Senden und Empfangen von Datenverkehr. Sie wenden die Regeln auf eine Sammlung von Pods an, die einer oder mehreren Bezeichnungsauswahlen entsprechen.

Die Regeln der Netzwerkrichtlinien werden als YAML-Manifeste definiert. Netzwerkrichtlinien können Teil eines umfassenderen Manifests sein, mit dem auch eine Bereitstellung oder ein Dienst erstellt wird.

Optionen für Netzwerkrichtlinien in AKS

Azure bietet drei Netzwerkrichtlinienmodule zum Erzwingen von Netzwerkrichtlinien:

  • Cilium für AKS-Cluster, die Azure CNI Powered by Cilium verwenden.
  • Azure-Netzwerkrichtlinien-Manager.
  • Calico: Eine Open-Source-Netzwerk- und Netzwerksicherheitslösung, die von Tigera gegründet wurde.

Cilium ist unser empfohlenes Netzwerkrichtlinienmodul. Cilium erzwingt Netzwerkrichtlinien für den Datenverkehr mit Linux Berkeley Packet Filter (BPF), was im Allgemeinen effizienter als "IPTables" ist. Weitere Details finden Sie in der Dokumentation zu Azure CNI Powered by Cilium.
Um die angegebenen Richtlinien zu erzwingen, verwendet Azure Network Policy Manager für Linux Linux IPTables. Azure Network Policy Manager für Windows verwendet Host Network Service (HNS) ACLPolicies. Aus den Richtlinien werden zulässige und unzulässige IP-Adresspaare gebildet. Diese Paare werden dann als IPTable- oder HNS ACLPolicy-Filterregeln programmiert.

Unterschiede zwischen Netzwerkrichtlinienmodulen: Cilium, Azure NPM und Calico

Funktion Azure-Netzwerkrichtlinien-Manager Calico Cilium
Unterstützte Plattformen Linux, Windows Server 2022 (Vorschauversion) Linux, Windows Server 2019 und 2022. Linux.
Unterstützte Netzwerkoptionen Azure Container Networking Interface (CNI). Azure CNI (Linux, Windows Server 2019 und 2022) und kubenet (Linux). Azure CNI.
Compliance mit Kubernetes-Spezifikation Alle Richtlinientypen werden unterstützt Alle Richtlinientypen werden unterstützt. Alle Richtlinientypen werden unterstützt.
Weitere Features Keine. Erweitertes Richtlinienmodell, das aus globaler Netzwerkrichtlinie, globalem Netzwerksatz und Hostendpunkt besteht. Weitere Informationen zur Verwendung der calicoctl-Befehlszeilenschnittstelle zum Verwalten dieser erweiterten Funktionen finden Sie in der calicoctl-Benutzerreferenz. Keine.
Unterstützung Unterstützt durch das Azure-Support- und Engineering-Team. Unterstützt durch das Azure-Support- und Engineering-Team. Unterstützt durch das Azure-Support- und Engineering-Team.

Einschränkungen des Azure-Netzwerkrichtlinien-Managers

Hinweis

Bei Azure NPM für Linux erlauben wir keine Skalierung über 250 Knoten und 20.000 Pods hinaus. Wenn Sie versuchen, über diese Grenzen hinaus zu skalieren, kann es zu „Out of Memory“-Fehlern (OOM) kommen. Für eine bessere Skalierbarkeit IPv6-Unterstützung und sofern die folgenden Einschränkungen für Sie problematisch sind, empfehlen wir die Verwendung oder ein Upgrade auf Azure CNI Powered by Cilium, um Cilium als Netzwerkrichtlinienmodul zu verwenden.

Azure NPM unterstützt IPv6 nicht. Ansonsten unterstützt es die Netzwerkrichtlinienspezifikationen in Linux vollständig.

In Windows unterstützt Azure NPM die folgenden Features der Netzwerkrichtlinienspezifikationen nicht:

  • Benannte Ports.
  • Stream Control Transmission Protocol (SCTP).
  • Negative Übereinstimmungsbezeichnung oder Namespaceselektoren. Beispielsweise werden alle Bezeichnungen mit Ausnahme von debug=true unterstützt.
  • Klassenlose domänenübergreifende except-Routingblöcke (CIDR mit Ausnahmen).

Hinweis

Podprotokolle von Azure Policy Network Manager zeichnen einen Fehler auf, wenn eine nicht unterstützte Netzwerkrichtlinie erstellt wird.

Bearbeiten/Löschen von Netzwerkrichtlinien

In seltenen Fällen besteht beim Bearbeiten oder Löschen einer „ausreichend großen“ Netzwerkrichtlinie die Möglichkeit, eine Racebedingung zu erreichen, die zu temporären, unerwarteten Verbindungen für neue Verbindungen zu/von Pods auf betroffenen Knoten führen kann. Das Erreichen dieser Racebedingung wirkt sich niemals auf aktive Verbindungen aus.

Wenn diese Racebedingung für einen Knoten auftritt, wechselt der Azure NPM-Pod auf diesem Knoten in einen Zustand, in dem er keine Sicherheitsregeln aktualisieren kann, was für den betroffenen Knoten zu unerwarteten Verbindungen für neue Verbindungen zu/von Pods führen kann. Um das Problem zu beheben, startet der Azure NPM-Pod nach dem Eintreten in diesen Zustand automatisch nach ca. 15 Sekunden neu. Während Azure NPM auf dem betroffenen Knoten neu gestartet wird, löscht es alle Sicherheitsregeln und wendet dann erneut Sicherheitsregeln für alle Netzwerkrichtlinien an. Während alle Sicherheitsregeln erneut angewendet werden, besteht die Möglichkeit einer temporären, unerwarteten Verbindung für neue Verbindungen zu/von Pods auf dem betroffenen Knoten.

Um die Wahrscheinlichkeit zu begrenzen, dass diese Racebedingung erreicht wird, können Sie die Größe der Netzwerkrichtlinie verringern. Dieses Problem tritt höchstwahrscheinlich für eine Netzwerkrichtlinie mit mehreren ipBlock-Abschnitten auf. Bei einer Netzwerkrichtlinie mit vier oder weniger ipBlock-Abschnitten ist es weniger wahrscheinlich, dass das Problem auftritt.

Voraussetzungen

Azure CLI-Version 2.0.61 oder höher muss installiert und konfiguriert sein. Führen Sie az --version aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Erstellen eines AKS-Clusters und Aktivieren der Netzwerkrichtlinie

Um die Netzwerkrichtlinien in Aktion zu sehen, erstellen Sie einen AKS-Cluster, der die Netzwerkrichtlinien unterstützt, und arbeiten dann daran, Richtlinien hinzuzufügen.

Um den Azure-Netzwerkrichtlinien-Manager zu nutzen, müssen Sie das Azure CNI-Plug-In verwenden. Calico kann entweder mit dem Azure CNI-Plug-In oder mit dem Kubenet CNI-Plug-In verwendet werden.

Das folgende Beispielskript erstellt einen AKS-Cluster mit einer dem System zugewiesenen Identität und aktiviert die Netzwerkrichtlinie mithilfe des Azure Network Policy Manager.

Hinweis

Calico kann entweder mit den Parametern --network-plugin azure oder --network-plugin kubenet verwendet werden.

Statt einer systemseitig zugewiesenen Identität können Sie auch eine benutzerseitig zugewiesene Identität verwenden. Weitere Informationen finden Sie unter Verwenden verwalteter Identitäten.

Erstellen eines AKS-Clusters mit aktiviertem Azure-Netzwerkrichtlinien-Manager – nur Linux

In diesem Abschnitt erstellen Sie einen Cluster mit Linux-Knotenpools und aktiviertem Azure Network Policy Manager.

Zunächst ersetzen Sie die Werte für die $RESOURCE_GROUP_NAME und $CLUSTER_NAME-Variablen.

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$LOCATION=canadaeast

Erstellen Sie den AKS-Cluster, und geben Sie azure für das network-plugin und die network-policy an.

Um einen Cluster zu erstellen, verwenden Sie den folgenden Befehl:

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

Erstellen eines AKS-Clusters mit aktiviertem Azure-Netzwerkrichtlinien-Manager – Windows Server 2022 (Vorschau)

In diesem Abschnitt erstellen Sie einen Cluster mit Windows-Knotenpools und aktiviertem Azure Network Policy Manager.

Hinweis

Der Azure-Netzwerkrichtlinien-Manager mit Windows-Knoten ist nur unter Windows Server 2022 verfügbar.

Installieren der Azure CLI-Erweiterung „aks-preview“

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Führen Sie zum Installieren der aks-preview-Erweiterung den folgenden Befehl aus:

az extension add --name aks-preview

Führen Sie den folgenden Befehl aus, um ein Update auf die neueste veröffentlichte Version der Erweiterung durchzuführen:

az extension update --name aks-preview

Registrieren des Funktionsflags „WindowsNetworkPolicyPreview“

Registrieren Sie das Featureflag WindowsNetworkPolicyPreview mithilfe des Befehls WindowsNetworkPolicyPreview, wie im folgenden Beispiel gezeigt:

az feature register --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird. Überprüfen Sie den Registrierungsstatus mithilfe des Befehls az feature show:

az feature show --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

Wenn der Status Registriert lautet, aktualisieren Sie die Registrierung des Microsoft.ContainerService-Ressourcenanbieters, indem Sie den Befehl az provider register verwenden:

az provider register --namespace Microsoft.ContainerService

Erstellen des AKS-Clusters

Jetzt ersetzen Sie die Werte für die $RESOURCE_GROUP_NAME-, $CLUSTER_NAME- und $WINDOWS_USERNAME- Variablen.

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$WINDOWS_USERNAME=myWindowsUserName
$LOCATION=canadaeast

Erstellen Sie einen Benutzernamen, der für die Administratoranmeldeinformationen für Ihre Windows Server-Container in Ihrem Cluster verwendet wird. Mit dem folgenden Befehl werden Sie zur Eingabe eines Benutzernamens aufgefordert. Legen Sie hierfür $WINDOWS_USERNAME fest. Denken Sie daran, dass die Befehle in diesem Artikel in einer Bash-Shell eingegeben werden.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

Um einen Cluster zu erstellen, verwenden Sie den folgenden Befehl:

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

Die Erstellung des Clusters dauert einige Minuten. Ihr Cluster wird standardmäßig nur mit einem Linux-Knotenpool erstellt. Wenn Sie Windows-Knotenpools verwenden möchten, können Sie einen hinzufügen. Ein Beispiel:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Erstellen eines AKS-Clusters mit aktiviertem Calico

Erstellen Sie den AKS-Cluster und geben Sie --network-plugin azure, und --network-policy calico an. Die Angabe von --network-policy calico aktiviert Calico sowohl auf Linux- als auch auf Windows-Knotenpools.

Wenn Sie vorhaben, Ihrem Cluster Windows-Knotenpools hinzuzufügen, fügen Sie die windows-admin-username- und windows-admin-password-Parameter ein, die den Windows Server-Kennwortanforderungen entsprechen.

Wichtig

Derzeit ist die Verwendung von Calico-Netzwerkrichtlinien mit Windows-Knoten auf neuen Clustern verfügbar, wenn Sie Kubernetes Version 1.20 oder höher mit Calico 3.17.2 verwenden. Voraussetzung ist, dass Sie Azure CNI-Netzwerke verwenden. Windows-Knoten in AKS-Clustern, in denen Calico aktiviert ist, verfügen standardmäßig auch über eine unverankerte IP.

Bei Clustern mit ausschließlich Linux-Knotenpools, die Kubernetes 1.20 mit früheren Versionen von Calico ausführen, wird die Calico-Version automatisch auf 3.17.2 aktualisiert.

Erstellen Sie einen Benutzernamen, der für die Administratoranmeldeinformationen für Ihre Windows Server-Container in Ihrem Cluster verwendet wird. Mit dem folgenden Befehl werden Sie zur Eingabe eines Benutzernamens aufgefordert. Legen Sie hierfür $WINDOWS_USERNAME fest. Denken Sie daran, dass die Befehle in diesem Artikel in einer Bash-Shell eingegeben werden.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy calico \
    --generate-ssh-keys

Die Erstellung des Clusters dauert einige Minuten. Ihr Cluster wird standardmäßig nur mit einem Linux-Knotenpool erstellt. Wenn Sie Windows-Knotenpools verwenden möchten, können Sie einen hinzufügen. Zum Beispiel:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Installieren von Azure Network Policy Manager oder Calico in einem vorhandenen Cluster

Das Installieren von Azure Network Policy Manager oder Calico auf vorhandenen AKS-Clustern wird ebenfalls unterstützt.

Warnung

Durch den Upgradeprozess wird gleichzeitig für jeden Knotenpool das Durchführen eines Reimagings ausgelöst. Ein separates Upgrade jedes Knotenpools wird nicht unterstützt. Innerhalb jedes Knotenpools werden Knoten nach demselben Prozess wie bei einem standardmäßigen Kubernetes-Versionsupgradevorgang neu aufgesetzt, bei dem Pufferknoten vorübergehend hinzugefügt werden, um Unterbrechungen bei der Ausführung von Anwendungen zu minimieren, während der Knotenumstellungsprozess fortgesetzt wird. Daher sind alle Unterbrechungen, die auftreten können, ähnlich wie bei einem Upgrade des Knotenimages oder einem Kubernetes-Versionsupgrade-Vorgang.

Beispielbefehl zum Installieren von Azure Network Policy Manager:

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy azure

Beispielbefehl zum Installieren von Calico:

Warnung

Diese Warnung gilt für das Upgrade von Kubenet-Clustern mit aktiviertem Calico auf Azure CNI-Overlay mit aktiviertem Calico.This warning applies to upgrade Kubenet clusters with Calico enabled to Azure CNI Overlay.

  • In Kubenet-Clustern mit aktiviertem Calico wird Calico sowohl als CNI- als auch als Netzwerkrichtlinienmodul verwendet.
  • In Azure CNI-Clustern wird Calico nur für die Durchsetzung von Netzwerkrichtlinien verwendet, nicht als CNI. Dies kann zu einer kurzen Verzögerung zwischen dem Start des Pods und dem Zeitpunkt, an dem Calico ausgehenden Datenverkehr vom Pod zulässt.

Es wird empfohlen, Cilium anstelle von Calico zu verwenden, um dieses Problem zu vermeiden. Weitere Informationen zu Cilium bei Azure CNI Powered by Cilium

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy calico

Upgrade eines vorhandenen Clusters mit Azure NPM oder Calico auf Azure CNI Powered by Cilium

Informationen zum Upgrade eines vorhandenen Clusters mit installiertem Netzwerkrichtlinienmodul auf Azure CNI Powered by Cilium finden Sie unter Upgrade eines vorhandenen Clusters auf Azure CNI Powered by Cilium

Überprüfen der Einrichtung von Netzwerkrichtlinien

Wenn der Cluster bereit ist, können Sie kubectl mit dem Befehl az aks get-credentials konfigurieren, um die Verbindung mit Ihrem Kubernetes-Cluster herzustellen. Mit diesem Befehl werden die Anmeldeinformationen heruntergeladen, und die Kubernetes-Befehlszeilenschnittstelle wird für deren Verwendung konfiguriert:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Um mit der Überprüfung der Netzwerkrichtlinien zu beginnen, erstellen Sie eine Beispielanwendung und legen Verkehrsregeln fest.

Erstellen Sie zunächst einen Namespace namens demo, um die Beispiel-Pods auszuführen:

kubectl create namespace demo

Erstellen Sie nun zwei Pods im Cluster namens client und server.

Hinweis

Wenn Sie den Client oder Server auf einem bestimmten Knoten einplanen möchten, fügen Sie das folgende Bit vor dem --command-Argument im Befehl kubectl run zur Pod-Erstellung hinzu:

--overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux|windows"}}}'

Erstellen eines server-Pods. Dieser Pod dient am TCP-Port 80:

kubectl run server -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --labels="app=server" --port=80 --command -- /agnhost serve-hostname --tcp --http=false --port "80"

Erstellen eines client-Pods. Der folgende Befehl führt Bash auf dem client-Pod aus:

kubectl run -it client -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --command -- bash

Führen Sie jetzt in einem separaten Fenster den folgenden Befehl aus, um die Server-IP-Adresse abzurufen:

kubectl get pod --output=wide -n demo

Die Ausgabe sollte wie folgt aussehen:

NAME     READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
server   1/1     Running   0          30s   10.224.0.72   akswin22000001   <none>           <none>

Testen der Konnektivität ohne Netzwerkrichtlinie

Führen Sie in der Shell des Clients den folgenden Befehl aus, um die Verbindung mit dem Server zu überprüfen. Ersetzen Sie server-ip mithilfe der IP-Adresse, die in der Ausgabe enthalten ist, indem Sie den vorherigen Befehl ausführen. Wenn die Verbindung erfolgreich ist, gibt es keine Ausgabe.

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

Testen der Konnektivität mit Netzwerkrichtlinie

Zum Hinzufügen von Netzwerkrichtlinien erstellen Sie eine Datei namens demo-policy.yaml und fügen das folgende YAML-Manifest ein:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: demo-policy
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app: server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: client
    ports:
    - port: 80
      protocol: TCP

Geben Sie den Namen Ihres YAML-Manifests an und wenden Sie es mithilfe von kubectl apply an:

kubectl apply –f demo-policy.yaml

Überprüfen Sie nun in der Shell des Clients die Verbindung mit dem Server, indem Sie den folgenden /agnhost-Befehl ausführen:

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

Die Verbindung mit dem Datenverkehr wird blockiert, weil der Server mit app=server gekennzeichnet ist, der Client aber nicht. Der obige Verbindungsbefehl liefert diese Ausgabe:

TIMEOUT

Führen Sie den folgenden Befehl aus, um client zu bezeichnen und die Konnektivität mit dem Server zu überprüfen. Die Ausgabe sollte nichts zurückgeben.

kubectl label pod client -n demo app=client

Deinstallieren von Azure Network Policy Manager oder Calico (Vorschau)

Anforderungen:

  • Azure CLI, Version 2.63 oder höher.

Hinweis

  • Der Deinstallationsprozess entfernt keine benutzerdefinierten Ressourcendefinitionen (CRDs) und benutzerdefinierte Ressourcen (CRs), die von Calico verwendet werden. Diese CRDs und CRs haben alle Namen, die mit "projectcalico.org" oder "tigera.io" enden. Diese CRDs und zugehörigen CRs können manuell gelöscht werden, nachdem Calico erfolgreich deinstalliert wurde (löschen Sie die CRDs, bevor Calico den Cluster entfernt).
  • Durch das Upgrade werden keine NetworkPolicy-Ressourcen im Cluster entfernt, aber nach der Deinstallation werden diese Richtlinien nicht mehr erzwungen.

Warnung

Durch den Upgradeprozess wird gleichzeitig für jeden Knotenpool das Durchführen eines Reimagings ausgelöst. Ein separates Upgrade jedes Knotenpools wird nicht unterstützt. Alle Unterbrechungen des Clusternetzwerks ähneln einem Knotenimageupgrade oder einem Kubernetes-Versionsupgrade, bei dem für jeden Knoten in einem Knotenpool ein Reimaging durchgeführt wird.

Um Azure Network Policy Manager oder Calico aus einem Cluster zu entfernen, führen Sie den folgenden Befehl aus:

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy none

Bereinigen von Ressourcen

In diesem Artikel haben Sie einen Namespace und zwei Pods erstellt und eine Netzwerkrichtlinie angewendet. Verwenden Sie zur Bereinigung dieser Ressourcen den Befehl kubectl delete, und geben Sie den Ressourcennamen an:

kubectl delete namespace demo

Nächste Schritte

Weitere Informationen zu Netzwerkressourcen in Kubernetes finden Sie unter Netzwerkkonzepte für Anwendungen in Azure Kubernetes Service (AKS).

Weitere Informationen zu Richtlinien finden Sie unter Network Policies (Netzwerkrichtlinien).