Verwenden der Calico-Netzwerkrichtlinie zum Schützen des Poddatenverkehrs
Gilt für: AKS in Azure Stack HCI 22H2, AKS unter Windows Server
Verwenden Sie diese Schritt-für-Schritt-Anleitung, um die grundlegende Pod-zu-Pod-Konnektivität zu überprüfen und auszuprobieren und Calico-Netzwerkrichtlinien in einem Cluster in einem AKS zu verwenden, der durch die Azure Arc-Bereitstellung aktiviert ist. In diesem Artikel wird beschrieben, wie Sie Client- und Serverpods auf Linux- und Windows-Knoten erstellen, die Konnektivität zwischen den Pods überprüfen und dann eine grundlegende Netzwerkrichtlinie anwenden, um den Poddatenverkehr in AKS Arc zu isolieren.
Voraussetzungen
Führen Sie zum Bereitstellen von AKS Arc die Schritte zum Einrichten eines AKS-Hosts aus.
Um dieses Handbuch verwenden zu können, benötigen Sie Folgendes:
- Ein AKS-Workloadcluster.
- Mindestens einen im Cluster bereitgestellten Windows-Workerknoten.
- Mindestens einen im Cluster bereitgestellten Linux-Workerknoten.
- Das Calico-Netzwerk-Plug-In muss beim Erstellen des Workloadclusters aktiviert sein. Wenn das Plug-In nicht aktiviert wurde, nutzen Sie die Anweisungen unter
New-AksHciCluster.
Erstellen von Pods auf Linux-Knoten
Erstellen Sie auf den Linux-Knoten zunächst einen Clientpod, busybox, und einen Serverpod, nginx.
Erstellen einer YAML-Datei mit dem Namen „policy-demo-linux.yaml“
apiVersion: v1
kind: Namespace
metadata:
name: calico-demo
---
apiVersion: v1
kind: Pod
metadata:
labels:
app: busybox
name: busybox
namespace: calico-demo
spec:
containers:
- args:
- /bin/sh
- -c
- sleep 360000
image: busybox:1.28
imagePullPolicy: Always
name: busybox
nodeSelector:
beta.kubernetes.io/os: linux
---
apiVersion: v1
kind: Pod
metadata:
labels:
app: nginx
name: nginx
namespace: calico-demo
spec:
containers:
- name: nginx
image: nginx:1.8
ports:
- containerPort: 80
nodeSelector:
beta.kubernetes.io/os: linux
Anwenden der Datei „policy-demo-linux.yaml“ auf den Kubernetes-Cluster
Öffnen Sie ein PowerShell-Fenster, und laden Sie die Anmeldeinformationen für Ihren Zielcluster mit dem Get-AksHciCredential Befehl.
Verwenden Sie kubectl als Nächstes, um die policy-demo-linux.yaml Konfiguration wie folgt anzuwenden:
kubectl apply -f policy-demo-linux.yaml
Create Pods auf Windows-Knoten
Erstellen Sie einen Clientpod pwsh und einen Serverpod porter auf den Windows-Knoten.
Hinweis
Das Manifest der Pods verwendet Images, die auf mcr.microsoft.com/windows/servercore:1809 basieren. Wenn Sie eine neuere Version von Windows Server verwenden, aktualisieren Sie die Manifeste, um ein Server Core-Image zu verwenden, das Ihrer Windows Server-Version entspricht.
Erstellen von „policy-demo-windows.yaml“
apiVersion: v1
kind: Pod
metadata:
name: pwsh
namespace: calico-demo
labels:
app: pwsh
spec:
containers:
- name: pwsh
image: mcr.microsoft.com/windows/servercore:1809
args:
- powershell.exe
- -Command
- "Start-Sleep 360000"
imagePullPolicy: IfNotPresent
nodeSelector:
kubernetes.io/os: windows
---
apiVersion: v1
kind: Pod
metadata:
name: porter
namespace: calico-demo
labels:
app: porter
spec:
containers:
- name: porter
image: calico/porter:1809
ports:
- containerPort: 80
env:
- name: SERVE_PORT_80
value: This is a Calico for Windows demo.
imagePullPolicy: IfNotPresent
nodeSelector:
kubernetes.io/os: windows
Anwenden der Datei „policy-demo-windows.yaml“ auf den Kubernetes-Cluster
Öffnen Sie ein PowerShell-Fenster, und laden Sie die Anmeldeinformationen für Ihren Zielcluster mit dem Get-AksHciCredential Befehl.
Verwenden Sie als Nächstes kubectl zum Anwenden derpolicy-demo-windows.yaml-Konfiguration:
kubectl apply -f policy-demo-windows.yaml
Überprüfen, ob die vier Pods erstellt sind und ausgeführt werden
Hinweis
Abhängig von der Downloadgeschwindigkeit Ihres Netzwerks kann es eine Weile dauern, bis die Windows-Pods gestartet werden.
Öffnen Sie ein PowerShell-Fenster, und laden Sie die Anmeldeinformationen für Ihren Zielcluster mit dem Get-AksHciCredential Befehl.
Listen Sie als Nächstes mit kubectl die Pods im calico-demo-Namespace auf:
kubectl get pods --namespace calico-demo
Die Ausgabe sollte etwa folgendem Beispiel entsprechen:
NAME READY STATUS RESTARTS AGE
busybox 1/1 Running 0 4m14s
nginx 1/1 Running 0 4m14s
porter 0/1 ContainerCreating 0 74s
pwsh 0/1 ContainerCreating 0 2m9s
Wiederholen Sie den Befehl alle paar Minuten, bis in der Ausgabe alle vier Pods im Status „Wird ausgeführt“ angezeigt werden.
NAME READY STATUS RESTARTS AGE
busybox 1/1 Running 0 7m24s
nginx 1/1 Running 0 7m24s
porter 1/1 Running 0 4m24s
pwsh 1/1 Running 0 5m19s
Überprüfen der Konnektivität zwischen Pods auf Linux- und Windows-Knoten
Nachdem die Client- und Serverpods nun auf Linux- und Windows-Knoten ausgeführt werden, überprüfen Sie, ob Clientpods auf Linux-Knoten Serverpods auf Windows-Knoten erreichen können.
Öffnen Sie ein PowerShell-Fenster, und laden Sie die Anmeldeinformationen für Ihren Zielcluster mit dem
Get-AksHciCredentialBefehl.Bestimmen Sie mit
kubectldie IP-Adresse des porter-Pods:kubectl get pod porter --namespace calico-demo -o 'jsonpath={.status.podIP}'Melden Sie sich beim busybox-Pod an, und versuchen Sie, den Portierpod an Port 80 zu erreichen. Ersetzen Sie das Tag <porter_ip> durch die vom vorherigen Befehl zurückgegebene IP-Adresse.
kubectl exec --namespace calico-demo busybox -- nc -vz <porter_ip> 80Sie können auch die beiden oben aufgeführten Schritte kombinieren:
kubectl exec --namespace calico-demo busybox -- nc -vz $(kubectl get pod porter --namespace calico-demo -o 'jsonpath={.status.podIP}') 80Wenn die Verbindung zwischen dem busybox-Pod und dem Porterpod erfolgreich ist, erhalten Sie eine Ausgabe ähnlich dem folgenden Beispiel:
192.168.40.166 (192.168.40.166:80) openHinweis
Die zurückgegebenen IP-Adressen können je nach Umgebungseinrichtung variieren.
Vergewissern Sie sich, dass der pwsh-Pod den nginx-Pod erreichen kann:
kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po nginx -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5Wenn die Verbindung erfolgreich hergestellt wurde, wird eine Ausgabe ähnlich der folgenden angezeigt:
StatusCode : 200 StatusDescription : OK Content : <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> <...Vergewissern Sie sich, dass der pwsh-Pod den porter-Pod erreichen kann:
kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5Wenn dies erfolgreich ist, wird eine Ausgabe ähnlich dem folgenden Beispiel angezeigt:
StatusCode : 200 StatusDescription : OK Content : This is a Calico for Windows demo. RawContent : HTTP/1.1 200 OK Content-Length: 49 Content-Type: text/plain; charset=utf-8 Date: Fri, 21 Aug 2020 22:45:46 GMT This is a Calico for Windows demo. Forms : Headers : {[Content-Length, 49], [Content-Type, text/plain; charset=utf-8], [Date, Fri, 21 Aug 2020 22:45:46 GMT]} Images : {} InputFields : {} Links : {} ParsedHtml : RawContentLength : 49
Sie haben nun überprüft, ob die Kommunikation zwischen allen Pods in der Anwendung möglich ist.
Anwenden der Richtlinie auf den Windows-Clientpod
In einer realen Bereitstellung möchten Sie sicherstellen, dass nur Pods, die miteinander kommunizieren sollen, dazu berechtigt sind. Um dies zu erreichen, wenden Sie eine grundlegende Netzwerkrichtlinie an, die es nur dem busybox-Pod ermöglicht, den Porterpod zu erreichen.
Erstellen der Datei „network-policy.yaml“
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-busybox
namespace: calico-demo
spec:
podSelector:
matchLabels:
app: porter
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: busybox
ports:
- protocol: TCP
port: 80
Anwenden der Datei „network-policy.yaml“
Öffnen Sie ein PowerShell-Fenster.
Laden Sie die Anmeldeinformationen für den Zielcluster mit dem
Get-AksHciCredential-Befehl.Verwenden Sie
kubectl, um die Datei network-policy.yaml anzuwenden:kubectl apply -f network-policy.yaml
Überprüfen der Wirksamkeit der Richtlinie
Wenn die Richtlinie in Kraft ist, sollte der busybox-Pod weiterhin den porter-Pod erreichen können. Wie bereits erwähnt, können Sie die Schritte in der Befehlszeile kombinieren:
kubectl exec --namespace calico-demo busybox -- nc -vz $(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') 80
Der pwsh-Pod kann den Porterpod jedoch nicht erreichen:
kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5
Für die Anforderung wird ein Zeitüberschreitung mit einer Meldung wie der folgenden angezeigt:
Invoke-WebRequest : The operation has timed out.
At line:1 char:1
+ Invoke-WebRequest -Uri http://192.168.40.166 -UseBasicParsing -Timeout ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:Htt
pWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
command terminated with exit code 1
In dieser Demo haben wir Pods auf Linux- und Windows-Knoten konfiguriert, die grundlegende Podkonnektivität überprüft und eine grundlegende Netzwerkrichtlinie zum Isolieren von Pod-zu-Pod-Datenverkehr ausprobiert.
Im letzten Schritt können Sie alle Demoressourcen bereinigen:
kubectl delete namespace calico-demo
Nächste Schritte
In diesem Artikel haben Sie erfahren, wie Sie Datenverkehr zwischen Pods mithilfe von Netzwerkrichtlinien sichern. Als Nächstes haben Sie folgende Möglichkeiten:
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für