Überlegungen Voraussetzungen Netzwerkrichtlinien konfigurieren Deaktivieren Sie Netzwerkrichtlinien Stars Policy-Demo Fehlerbehebung Kubernetes-Netzwerkrichtlinien

Helfen Sie mit, diese Seite zu verbessern

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Konfigurieren Ihres Clusters für Kubernetes-Netzwerkrichtlinien

Standardmäßig gibt es in Kubernetes keine Einschränkungen für IP-Adressen, Ports oder Verbindungen zwischen Pods in Ihrem Cluster oder zwischen Ihren Pods und Ressourcen in anderen Netzwerken. Sie können die Kubernetes-Netzwerkrichtlinie verwenden, um Netzwerkverkehr zu und von Ihren Pods einzuschränken. Weitere Informationen finden Sie unter Netzwerkrichtlinien in der Kubernetes-Dokumentation.

Wenn Sie 1.13 oder eine frühere Version des Amazon VPC CNI plugin for Kubernetes für Ihren Cluster verwenden, müssen Sie eine Drittanbieterlösung implementieren, um Kubernetes-Netzwerkrichtlinien auf Ihren Cluster anzuwenden. 1.14 oder eine höhere Version des Plug-ins kann Netzwerkrichtlinien implementieren, sodass Sie keine Drittanbieterlösung verwenden müssen. In diesem Thema erfahren Sie, wie Sie Ihren Cluster so konfigurieren, dass Sie Kubernetes-Netzwerkrichtlinien für Ihren Cluster nutzen können, ohne ein Drittanbieter-Add-on zu verwenden.

Netzwerkrichtlinien im Amazon VPC CNI plugin for Kubernetes werden in den folgenden Konfigurationen unterstützt.

Amazon-EKS-Cluster ab Version 1.25.
Version 1.14 oder höher von Amazon VPC CNI plugin for Kubernetes in Ihrem Cluster.
Für IPv4- oder IPv6-Adressen konfigurierter Cluster.
Sie können Netzwerkrichtlinien mit Sicherheitsgruppen für Pods verwenden. Mit Netzwerkrichtlinien können Sie die gesamte Kommunikation innerhalb eines Clusters steuern. Mit Sicherheitsgruppen für Pods können Sie den Zugriff auf AWS-Services Anwendungen innerhalb eines steuernPod.
Sie können Netzwerkrichtlinien mit benutzerdefinierten Netzwerken und Präfixdelegierung verwenden.

Überlegungen

Bei der Anwendung von Netzwerkrichtlinien des Amazon VPC CNI plugin for Kubernetes auf Ihren Cluster mit dem Amazon VPC CNI plugin for Kubernetes können die Richtlinien nur auf Amazon-EC2-Linux-Knoten angewendet werden. Sie können nicht auf Fargate- oder Windows-Knoten angewendet werden.
Wenn Ihr Cluster derzeit eine Drittanbieterlösung zur Verwaltung von Kubernetes-Netzwerkrichtlinien verwendet, können Sie dieselben Richtlinien mit dem Amazon VPC CNI plugin for Kubernetes verwenden. Sie müssen jedoch Ihre vorhandene Lösung entfernen, damit sie nicht dieselben Richtlinien verwaltet.
Sie können mehrere Netzwerkrichtlinien auf denselben Pod anwenden. Wenn zwei oder mehr Richtlinien konfiguriert werden, die denselben Pod auswählen, werden alle Richtlinien auf den Pod angewendet.
Die maximale Anzahl eindeutiger Kombinationen von Ports für jedes Protokoll in jedem Protokoll ingress: oder für jeden egress: Selektor in einer Netzwerkrichtlinie beträgt 24.
Für jeden Ihrer Kubernetes-Services muss der Port des Services mit dem Port des Containers identisch sein. Wenn Sie benannte Ports verwenden, verwenden Sie denselben Namen auch in der Servicespezifikation.
Durchsetzung von Richtlinien beim Start Pod

Das Amazon VPC CNI plugin for Kubernetes konfiguriert die Netzwerkrichtlinien für Pods parallel zur Pod-Bereitstellung. Bis alle Richtlinien für den neuen Pod konfiguriert sind, beginnen Container im neuen Pod mit einer standardmäßigen Zulassungsrichtlinie. Dies wird als Standardmodus bezeichnet. Eine standardmäßige Zulassungsrichtlinie bedeutet, dass der gesamte eingehende und ausgehende Datenverkehr zu und von den neuen Pods zugelassen ist. Für die Pods werden beispielsweise keine Firewallregeln durchgesetzt (der gesamte Datenverkehr ist zulässig), bis der neue Pod mit den aktiven Richtlinien aktualisiert wurde.

Sie können diese Standard-Netzwerkrichtlinie ändern, indem Sie die Umgebungsvariable NETWORK_POLICY_ENFORCING_MODE strict im aws-node Container der DaemonSet VPC-CNI auf setzen.
```
env:
  - name: NETWORK_POLICY_ENFORCING_MODE
    value: "strict"
```
Wenn die NETWORK_POLICY_ENFORCING_MODE Variable auf gesetzt iststrict, beginnen Pods, die das VPC-CNI verwenden, mit einer Standardverweigerungsrichtlinie. Anschließend werden die Richtlinien konfiguriert. Dies wird als strikter Modus bezeichnet. Im strikten Modus benötigen Sie eine Netzwerkrichtlinie für jeden Endpunkt, auf den Ihre Pods in Ihrem Cluster zugreifen müssen. Beachten Sie, dass diese Anforderung für die CoreDNS Pods gilt. Die standardmäßige Ablehnungsrichtlinie ist nicht für Pods mit Host-Netzwerk konfiguriert.
Das Netzwerkrichtlinienfeature erstellt und erfordert die Definition einer benutzerdefinierten PolicyEndpoint-Ressource (Custom Resource Definition, CRD) namens policyendpoints.networking.k8s.aws. PolicyEndpoint-Objekte der benutzerdefinierten Ressource werden von Amazon EKS verwaltet. Ändern oder löschen Sie diese Ressourcen nicht.
Wenn Sie Pods ausführen, die die IAM-Anmeldeinformationen der Instance-Rolle verwenden oder eine Verbindung mit EC2 IMDS herstellen, achten Sie auf Netzwerkrichtlinien, die den Zugriff auf EC2 IMDS blockieren würden. Möglicherweise müssen Sie eine Netzwerkrichtlinie hinzufügen, um den Zugriff auf EC2 IMDS zu ermöglichen. Weitere Informationen finden Sie unter Instance-Metadaten und Benutzerdaten im Amazon EC2-Benutzerhandbuch für Linux-Instances.

Pods, die IAM-Rollen für Servicekonten verwenden, haben keinen Zugriff auf EC2 IMDS.
Das Amazon VPC CNI plugin for Kubernetes wendet nur Netzwerkrichtlinien auf die primäre Schnittstelle für jeden Pod (eth0) an, nicht auf zusätzliche Netzwerkschnittstellen für die einzelnen Pods. Das hat Auswirkungen auf folgende Architekturen:
- IPv6-Pods, bei denen die Variable ENABLE_V4_EGRESS auf true festgelegt ist. Diese Variable ermöglicht es der IPv4-Ausgangsfunktion, eine Verbindung zwischen den IPv6-Pods und IPv4-Endpunkten (beispielsweise außerhalb des Clusters) herzustellen. Die IPv4-Ausgangsfunktion erstellt eine zusätzliche Netzwerkschnittstelle mit einer lokalen IPv4-Loopback-Adresse.
- Bei Verwendung verketteter Netzwerk-Plugins wieMultus. Da diese Plugins jedem Pod Netzwerkschnittstellen hinzufügen, werden Netzwerkrichtlinien nicht auf die verketteten Netzwerk-Plugins angewendet.
Das Netzwerkrichtlinien-Feature verwendet standardmäßig den Port 8162 auf dem Knoten für Metriken. Außerdem verwendete das Feature den Port 8163 für Zustandstests. Wenn Sie eine andere Anwendung auf die Knoten oder innerhalb von Pods ausführen, die diese Ports verwenden müssen, kann die App nicht ausgeführt werden. In der VPC-CNI-Version v1.14.1 oder höher können Sie diese Ports an den folgenden Stellen ändern:
AWS Management Console
Öffnen Sie die Amazon-EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.

Wählen Sie im linken Navigationsbereich die Option Cluster aus. Wählen Sie dann den Namen des Clusters aus, für den Sie das Amazon-VPC-CNI-Add-on konfigurieren möchten.

Wählen Sie die Registerkarte Add-ons.

Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann Edit (Bearbeiten).

Gehen Sie auf der Seite Configure name of addon (Namen des Add-Ons konfigurieren) wie folgt vor:

Wählen Sie v1.14.0-eksbuild.3 oder eine neuere Version in der Dropdown-Liste aus.

Erweitern Sie Optionale Konfigurationseinstellungen.

Geben Sie den JSON-Schlüssel "enableNetworkPolicy": und den Wert "true" in Konfigurationswerte ein. Der resultierende Text muss ein gültiges JSON-Objekt sein. Wenn dieser Schlüssel und dieser Wert die einzigen Daten im Textfeld sind, setzen Sie den Schlüssel und den Wert in geschweifte Klammern {}.

Im folgenden Beispiel ist die Netzwerkrichtlinien-Funktion aktiviert und Metriken und Integritätstests sind auf die Standard-Portnummern eingestellt:

{ "enableNetworkPolicy": "true", "nodeAgent": { "healthProbeBindAddr": "8163", "metricsBindAddr": "8162" } }
Helm
Wenn Sie das Amazon VPC CNI plugin for Kubernetes über helm installiert haben, können Sie die Konfiguration aktualisieren, um die Ports zu ändern.

Führen Sie den folgenden Befehl aus, um die Ports zu ändern. Legen Sie die Portnummer im Wert für Schlüssel nodeAgent.metricsBindAddr bzw. Schlüssel nodeAgent.healthProbeBindAddr fest.

helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
kubectl
Öffnen Sie das DaemonSet aws-node in Ihrem Editor.

kubectl edit daemonset -n kube-system aws-node

Ersetzen Sie die Portnummern in den folgenden Befehlsargumenten im args: im aws-network-policy-agent-Container im aws-node-DaemonSet-Manifest von VPC CNI.

- args: - --metrics-bind-addr=:8162 - --health-probe-bind-addr=:8163

Voraussetzungen

Minimale Cluster-Version

Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter Erste Schritte mit Amazon EKS. Der Cluster muss Kubernetes Version 1.25 oder höher aufweisen. Auf dem Cluster muss eine der in der folgenden Tabelle aufgeführten Kubernetes-Versionen und Plattform-Versionen ausgeführt werden. Beachten Sie, dass alle Kubernetes- und Plattformversionen, die über die aufgeführten hinausgehen, ebenfalls unterstützt werden. Sie können Ihre aktuelle Kubernetes-Version überprüfen, indem Sie my-cluster im folgenden Befehl durch den Namen Ihres Clusters ersetzen und dann den geänderten Befehl ausführen:


aws eks describe-cluster
              --name my-cluster --query cluster.version --output
              text

Kubernetes-Version	Plattformversion
`1.27.4`	`eks.5`
`1.26.7`	`eks.6`
`1.25.12`	`eks.7`

VPC-CNI-Mindestversion

Version 1.14 oder höher von Amazon VPC CNI plugin for Kubernetes in Ihrem Cluster. Sie können Ihre aktuelle Version mit dem folgenden Befehl überprüfen:
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Wenn Ihre Version älter als 1.14 ist, finden Sie unter Aktualisieren des Amazon-EKS-Add-ons Informationen zum Aktualisieren des Plugins auf Version 1.14 oder höher.
Linux-Kernel-Mindestversion

Ihre Knoten müssen eine Linux-Kernelversion ab Version 5.10 haben. Sie können Ihre Kernelversion mit uname -r überprüfen. Wenn Sie die aktuellen Versionen der für Amazon EKS optimierten Amazon-Linux-, für Amazon EKS optimierten beschleunigten Amazon-Linux- und Bottlerocket-AMIs verwenden, verfügen diese bereits über die erforderliche Kernelversion.

Amazon-EKS-optimierte Amazon-Linux-AMI-Versionen ab v20231116 verfügen über Kernel-Version 5.10.

Konfigurieren Ihres Clusters für die Verwendung von Kubernetes-Netzwerkrichtlinien

Mounten des BPF-Dateisystems

Anmerkung
Wenn Ihr Cluster Version 1.27 oder höher hat, können Sie diesen Schritt überspringen, da alle für Amazon EKS optimierten Amazon-Linux- und Bottlerocket-AMIs für 1.27 oder höher dieses Feature bereits haben.
Für alle anderen Clusterversionen können Sie diesen Schritt überspringen, wenn Sie das für Amazon EKS optimierte Amazon-Linux-AMI mindestens auf Version v20230703 aktualisieren oder das Bottlerocket-AMI mindestens auf Version v1.0.2 aktualisieren.
1. Mounten Sie das Berkeley Packet Filter (BPF)-Dateisystem auf jedem Ihrer Knoten.
```
sudo mount -t bpf bpffs /sys/fs/bpf
```
2. Fügen Sie dann denselben Befehl Ihren Benutzerdaten in Ihrer Startvorlage für Ihre Amazon-EC2-Auto-Scaling-Gruppen hinzu.
Aktivieren der Netzwerkrichtlinie in VPC CNI
1. Sehen Sie, welche Version des Container-Images derzeit auf Ihrem Cluster installiert ist. Je nachdem, mit welchem Tool Sie Ihr Cluster erstellt haben, ist der Add-on vom Typ Amazon EKS möglicherweise derzeit nicht auf Ihrem Cluster installiert. Ersetzen Sie my-cluster durch den Namen Ihres Clusters.
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query addon.addonVersion --output text
```
  Wenn Sie eine Versionsnummer zurückgeben, wird der Amazon-EKS-Typ des Add-Ons auf Ihrem Cluster installiert. Wenn Sie eine Versionsnummer zurückgeben, wird der Amazon-EKS-Typ des Add-Ons auf Ihrem Cluster installiert.
2. - Amazon-EKS-Add-On
    AWS Management Console
    
    Öffnen Sie die Amazon-EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.
    
    Wählen Sie im linken Navigationsbereich die Option Cluster aus. Wählen Sie dann den Namen des Clusters aus, für den Sie das Amazon-VPC-CNI-Add-on konfigurieren möchten.
    
    Wählen Sie die Registerkarte Add-ons.
    
    Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann Edit (Bearbeiten).
    
    Gehen Sie auf der Seite Configure name of addon (Namen des Add-Ons konfigurieren) wie folgt vor:
    
    Wählen Sie v1.14.0-eksbuild.3 oder eine neuere Version in der Dropdown-Liste aus.
    
    Erweitern Sie Optionale Konfigurationseinstellungen.
    
    Geben Sie den JSON-Schlüssel "enableNetworkPolicy": und den Wert "true" in Konfigurationswerte ein. Der resultierende Text muss ein gültiges JSON-Objekt sein. Wenn dieser Schlüssel und dieser Wert die einzigen Daten im Textfeld sind, setzen Sie den Schlüssel und den Wert in geschweifte Klammern {}. Das folgende Beispiel zeigt, dass die Netzwerkrichtlinie aktiviert ist:
    
    { "enableNetworkPolicy": "true" }
    
    Der folgende Screenshot zeigt ein Beispiel für dieses Szenario.
    
    AWS CLI
    
    Führen Sie den folgenden Befehl aus AWS CLI . Ersetzen Sie my-cluster durch den Namen Ihres Clusters und den IAM-Rollen-ARN durch die Rolle, die Sie verwenden.
    
    aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \ --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \ --resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
  - Selbstverwaltetes Add-On
    Helm
    
    Wenn Sie das Amazon VPC CNI plugin for Kubernetes über helm installiert haben, können Sie die Konfiguration aktualisieren, um die Netzwerkrichtlinie zu aktivieren.
    
    Führen Sie den folgenden Befehl aus, um die Netzwerkrichtlinie zu aktivieren.
    
    helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
    
    kubectl
    
    Öffnen Sie das ConfigMap amazon-vpc-cni in Ihrem Editor.
    
    kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
    
    Fügen Sie data in ConfigMap die folgende Zeile hinzu:
    
    enable-network-policy-controller: "true"
    
    Sobald Sie die Zeile hinzugefügt haben, sollte ConfigMap wie das folgende Beispiel aussehen:
    
    apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-network-policy-controller: "true"
    
    Öffnen Sie das DaemonSet aws-node in Ihrem Editor.
    
    kubectl edit daemonset -n kube-system aws-node
    
    Ersetzen Sie im Befehlsargument --enable-network-policy=false in args: im Container aws-network-policy-agent im DaemonSet-Manifest aws-node von VPC CNI den Wert false durch true.
    
    - args: - --enable-network-policy=true
Vergewissern Sie sich, dass die aws-node-Pods auf Ihrem Cluster ausgeführt werden.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
Eine Beispielausgabe sieht wie folgt aus.
```
aws-node-gmqp7                                          2/2     Running   1 (24h ago)   24h
aws-node-prnsh                                          2/2     Running   1 (24h ago)   24h
```
In den Versionen 1.14 und späteren Versionen befinden sich 2 Container in den aws-node Pods. In früheren Versionen und wenn die Netzwerkrichtlinie deaktiviert ist, gibt es nur einen einzigen Container in den aws-node-Pods.

Sie können jetzt Kubernetes-Netzwerkrichtlinien für Ihren Cluster bereitstellen. Weitere Informationen finden Sie unter Kubernetes-Netzwerkrichtlinien.

Deaktivieren Sie Netzwerkrichtlinien

Listet alle Kubernetes-Netzwerkrichtlinien auf.
```
kubectl get netpol -A
```
Löschen Sie jede Kubernetes-Netzwerkrichtlinie. Sie müssen alle Netzwerkrichtlinien löschen, bevor Sie Netzwerkrichtlinien deaktivieren können.
```
kubectl delete netpol <policy-name>
```
Öffnen Sie den aws-Node DaemonSet in Ihrem Editor.
```
kubectl edit daemonset -n kube-system aws-node
```
Ersetzen Sie im Befehlsargument --enable-network-policy=true in args: im Container aws-network-policy-agent im DaemonSet-Manifest aws-node von VPC CNI den Wert true durch false.
```
     - args:
        - --enable-network-policy=true
```

Stars-Demo der Netzwerkrichtlinie

Diese Demo erstellt einen Front-End-, Back-End- und Client-Service in Ihrem Amazon-EKS-Cluster. Außerdem wird in der Demo eine grafische Benutzeroberfläche für die Verwaltung erstellt, in der die verfügbaren Wege für ein- und ausgehenden Datenverkehr zwischen den einzelnen Services dargestellt werden. Wir empfehlen, die Demo in einem Cluster durchzuführen, in dem keine Produktions-Workloads ausgeführt werden.

Bevor Sie Netzwerkrichtlinien erstellen, können alle Services bidirektional kommunizieren. Nachdem Sie die Netzwerkrichtlinien angewendet haben, können Sie feststellen, dass der Client nur mit dem Front-End-Service kommuniziert und das Back-End nur Datenverkehr vom Front-End akzeptiert.

So führen Sie die Stars Policy-Demo aus

Wenden Sie die Services für Front-End, Back-End, Client und Verwaltungs-Benutzeroberfläche an:


kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml

Zeigen Sie alle Pods im Cluster an.


kubectl get pods -A

Eine Beispielausgabe sieht wie folgt aus.

In Ihrer Ausgabe sollten Pods in den Namespaces aufgeführt sein, die in der folgenden Ausgabe angezeigt werden. Die NAMEN Ihrer Pods und die Anzahl der Pods in der Spalte READY unterscheiden sich von den Angaben in der folgenden Ausgabe. Fahren Sie erst dann fort, wenn Pods mit ähnlichen Namen angezeigt werden und bei allen Running in der Spalte STATUS aufgeführt wird.


NAMESPACE         NAME                                       READY   STATUS    RESTARTS   AGE
[...]
client            client-xlffc                               1/1     Running   0          5m19s
[...]
management-ui     management-ui-qrb2g                        1/1     Running   0          5m24s
stars             backend-sz87q                              1/1     Running   0          5m23s
stars             frontend-cscnf                             1/1     Running   0          5m21s
[...]

Zum Herstellen einer Verbindung mit der Verwaltungsbenutzeroberfläche stellen Sie eine Verbindung mit der EXTERNAL-IP des Services her, der auf Ihrem Cluster ausgeführt wird.
```
kubectl get service/management-ui -n management-ui
```
Öffnen Sie den Pfad aus dem vorherigen Schritt in einem Browser. Die Verwaltungs-Benutzeroberfläche sollte angezeigt werden. Der C--Knoten ist der Client-Service, der F-Knoten ist der Front-End-Service und der B--Knoten ist der Back-End-Service. Jeder Knoten verfügt über vollständigen Kommunikationszugriff auf alle anderen Knoten, wie durch die fett markierten, farbigen Zeilen angegeben.

Wenden Sie die folgende Netzwerkrichtlinie sowohl in den stars- als auch in den client-Namespaces an, um die Services voneinander zu isolieren:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels: {}

Sie können die folgenden Befehle verwenden, um die Richtlinie auf beide Namespaces anzuwenden:


kubectl apply -n stars -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml

Aktualisieren Sie Ihren Browser. Wie Sie feststellen, kann nun keiner der Knoten mehr über die Verwaltungs-Benutzeroberfläche erreicht werden. Die Knoten werden daher nicht mehr in der Benutzeroberfläche angezeigt.

Wenden Sie die folgenden verschiedenen Netzwerkrichtlinien an, um der Verwaltungsbenutzeroberfläche den Zugriff auf die Services zu erlauben: Wenden Sie diese Richtlinie an, um die Benutzeroberfläche zuzulassen:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: allow-ui 
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: management-ui

Wenden Sie diese Richtlinie an, um den Client zuzulassen:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: client 
  name: allow-ui 
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: management-ui

Sie können die folgenden Befehle verwenden, um beide Richtlinien anzuwenden:


kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml

Aktualisieren Sie Ihren Browser. Wie Sie feststellen, können die Knoten nun wieder über die Verwaltungs-Benutzeroberfläche erreicht werden, sie können jedoch nicht miteinander kommunizieren.

Wenden Sie die folgende Netzwerkrichtlinie an, um Verkehr vom Front-End-Service zum Back-End-Service zuzulassen:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 6379

Aktualisieren Sie Ihren Browser. Wie Sie feststellen, kann das Front-End mit dem Back-End kommunizieren.

Wenden Sie die folgende Netzwerkrichtlinie an, um Datenverkehr vom Client zum Front-End-Service zuzulassen:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      role: frontend 
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: client
      ports:
        - protocol: TCP
          port: 80

Aktualisieren Sie Ihren Browser. Wie Sie feststellen, kann der Client mit dem Front-End-Service kommunizieren. Der Front-End-Service kann nach wie vor mit dem Back-End-Service kommunizieren.

(Optional) Wenn Sie die Demo abgeschlossen haben, können Sie die zugehörigen Ressourcen löschen.


kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml

Auch nach dem Löschen der Ressourcen können noch Netzwerkrichtlinien-Endpunkte auf den Knoten vorhanden sein, die die Vernetzung in Ihrem Cluster auf unerwartete Weise stören können. Die einzige sichere Möglichkeit, diese Regeln zu entfernen, besteht darin, die Knoten neu zu starten oder alle Knoten zu beenden und sie zu recyceln. Um alle Knoten zu beenden, legen Sie entweder die Anzahl der gewünschten Auto Scaling-Gruppen auf 0 und anschließend wieder auf die gewünschte Zahl fest oder beenden einfach die Knoten.

Fehlerbehebung bei Netzwerkrichtlinien

Sie können Netzwerkverbindungen, die Netzwerkrichtlinien verwenden, durch Lesen der Netzwerkrichtlinien-Protokolle und durch Ausführen von Tools aus dem eBPF-SDK untersuchen und Fehler beheben.

Netzwerkrichtlinien-Protokolle

Ob Verbindungen durch eine Netzwerkrichtlinie zugelassen oder verweigert werden, wird in Flussprotokollen protokolliert. Die Netzwerkrichtlinien-Protokolle auf jedem Knoten enthalten die Flussprotokolle für jeden Pod, der über eine Netzwerkrichtlinie verfügt. Netzwerkrichtlinien-Protokolle werden unter /var/log/aws-routed-eni/network-policy-agent.log gespeichert. Das folgende Beispiel stammt aus einer network-policy-agent.log-Datei:

{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}

Netzwerkrichtlinien-Protokolle sind standardmäßig deaktiviert. Gehen Sie wie folgt vor, um die Netzwerkrichtlinienprotokolle zu aktivieren:

Anmerkung

Netzwerkrichtlinienprotokolle erfordern eine zusätzliche vCPU für den aws-network-policy-agent Container im VPC aws-node CNI-Daemonset-Manifest.

Amazon-EKS-Add-On

AWS Management Console

Öffnen Sie die Amazon-EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.
Wählen Sie im linken Navigationsbereich die Option Cluster aus. Wählen Sie dann den Namen des Clusters aus, für den Sie das Amazon-VPC-CNI-Add-on konfigurieren möchten.
Wählen Sie die Registerkarte Add-ons.
Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann Edit (Bearbeiten).
Gehen Sie auf der Seite Configure name of addon (Namen des Add-Ons konfigurieren) wie folgt vor:
1. Wählen Sie v1.14.0-eksbuild.3 oder eine neuere Version in der Dropdown-Liste aus.
2. Erweitern Sie Optionale Konfigurationseinstellungen.
3. Geben Sie den JSON-Schlüssel der obersten Ebene "nodeAgent": ein, und der Wert ist ein Objekt mit dem Schlüssel "enablePolicyEventLogs": und dem Wert "true" in Konfigurationswerte. Der resultierende Text muss ein gültiges JSON-Objekt sein. Das folgende Beispiel zeigt, dass Netzwerkrichtlinien und Netzwerkrichtlinien-Protokolle aktiviert sind und die Netzwerkrichtlinien-Protokolle an Logs gesendet werden: CloudWatch
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true"
    }
}
```

Der folgende Screenshot zeigt ein Beispiel für dieses Szenario.

AWS Management Console zeigt das VPC CNI-Add-on mit Netzwerkrichtlinien und CloudWatch Protokollen in der optionalen Konfiguration an.

AWS CLI

Führen Sie den folgenden Befehl aus AWS CLI . Ersetzen Sie my-cluster durch den Namen Ihres Clusters und den IAM-Rollen-ARN durch die Rolle, die Sie verwenden.


aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
    --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'

Selbstverwaltetes Add-On

Netzwerkrichtlinien-Protokolle an Amazon CloudWatch Logs senden

Sie können die Netzwerkrichtlinienprotokolle mithilfe von Diensten wie Amazon CloudWatch Logs überwachen. Sie können die folgenden Methoden verwenden, um die Netzwerkrichtlinienprotokolle an Logs zu CloudWatch senden.

Bei EKS-Clustern befinden sich die Richtlinienprotokolle unter /aws/eks/cluster-name/cluster/ und bei selbstverwalteten K8S-Clustern unter /aws/k8s-cluster/cluster.

Netzwerkrichtlinien-Protokolle mit Amazon VPC CNI plugin for Kubernetes senden

Wenn Sie die Netzwerkrichtlinie aktivieren, wird den aws-node-Pods ein zweiter Container für einen Konten-Agent hinzugefügt. Dieser Node-Agent kann die CloudWatch Netzwerkrichtlinien-Protokolle an Logs senden.

Anmerkung

Nur die Netzwerkrichtlinien-Protokolle werden vom Knoten-Agent gesendet. Andere von VPC CNI erstellte Protokolle sind nicht enthalten.

Voraussetzungen

Fügen Sie der IAM-Rolle, die Sie für VPC CNI verwenden, die folgenden Berechtigungen als Abschnitt oder separate Richtlinie hinzu.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Amazon-EKS-Add-On

AWS Management Console

Öffnen Sie die Amazon-EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.
Wählen Sie im linken Navigationsbereich die Option Cluster aus. Wählen Sie dann den Namen des Clusters aus, für den Sie das Amazon-VPC-CNI-Add-on konfigurieren möchten.
Wählen Sie die Registerkarte Add-ons.
Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann Edit (Bearbeiten).
Gehen Sie auf der Seite Configure name of addon (Namen des Add-Ons konfigurieren) wie folgt vor:
1. Wählen Sie v1.14.0-eksbuild.3 oder eine neuere Version in der Dropdown-Liste aus.
2. Erweitern Sie Optionale Konfigurationseinstellungen.
3. Geben Sie den JSON-Schlüssel der obersten Ebene "nodeAgent": ein, und der Wert ist ein Objekt mit dem Schlüssel "enableCloudWatchLogs": und dem Wert "true" in Konfigurationswerte. Der resultierende Text muss ein gültiges JSON-Objekt sein. Das folgende Beispiel zeigt, dass Netzwerkrichtlinien und Netzwerkrichtlinien-Protokolle aktiviert sind und die Protokolle an CloudWatch Logs gesendet werden:
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true",
        "enableCloudWatchLogs": "true",
    }
}
```

Der folgende Screenshot zeigt ein Beispiel für dieses Szenario.

AWS CLI

Führen Sie den folgenden Befehl aus AWS CLI . Ersetzen Sie my-cluster durch den Namen Ihres Clusters und den IAM-Rollen-ARN durch die Rolle, die Sie verwenden.


aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
    --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'

Selbstverwaltetes Add-On

Netzwerkrichtlinien-Protokolle mit einem Fluent Bit-DaemonSet senden

Wenn Sie Fluent Bit in einem Daemonset verwenden, um Protokolle von Ihren Knoten zu senden, können Sie eine Konfiguration hinzufügen, um die Netzwerkrichtlinien-Protokolle von Netzwerkrichtlinien einzuschließen. Sie können die folgende Beispielkonfiguration verwenden:


    [INPUT]
        Name              tail
        Tag               eksnp.*
        Path              /var/log/aws-routed-eni/network-policy-agent*.log
        Parser            json
        DB                /var/log/aws-routed-eni/flb_npagent.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Refresh_Interval  10

eBPF-SDK eingeschlossen

Das Amazon VPC CNI plugin for Kubernetes installiert eine Sammlung von eBPF-SDK-Tools auf den Knoten. Sie können die eBPF-SDK-Tools verwenden, um Probleme mit Netzwerkrichtlinien zu identifizieren. Der folgende Befehl listet zum Beispiel die Programme auf, die auf dem Knoten ausgeführt werden.


sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Zum Ausführen dieses Befehls können Sie eine beliebige Methode verwenden, um eine Verbindung mit dem Knoten herzustellen.

Kubernetes-Netzwerkrichtlinien

Zum Implementieren von Kubernetes-Netzwerkrichtlinien erstellen Sie Kubernetes NetworkPolicy-Objekte und stellen diese in Ihrem Cluster bereit. NetworkPolicy-Objekte sind auf einen Namespace beschränkt. Sie implementieren Richtlinien, um Datenverkehr zwischen Pods auf der Grundlage von Bezeichnungsselektoren, Namespaces und IP-Adressbereichen zuzulassen oder zu verweigern. Weitere Informationen zum Erstellen von NetworkPolicy-Objekten finden Sie unter Netzwerkrichtlinien in der Kubernetes-Dokumentation.

Die Durchsetzung von Kubernetes NetworkPolicy-Objekten wird mit dem Extended Berkeley Packet Filter (eBPF) implementiert. Im Vergleich zu iptables-basierten Implementierungen bietet er geringere Latenzzeiten und Leistungsmerkmale, einschließlich einer geringeren CPU-Auslastung und der Vermeidung sequenzieller Suchvorgänge. Darüber hinaus bieten eBPF-Probes Zugriff auf kontextreiche Daten, die bei der Fehlersuche in komplexen Problemen auf Kernel-Ebene helfen und die Beobachtbarkeit verbessern. Amazon EKS unterstützt einen eBPF-basierten Exporter, der die Probes nutzt, um Richtlinienergebnisse auf jedem Knoten zu protokollieren und die Daten an externe Protokollsammler zu exportieren, um bei der Fehlersuche zu helfen. Weitere Informationen finden Sie in der eBPF-Dokumentation.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

SNAT

Benutzerdefinierte Netzwerke

Konfigurieren Ihres Clusters für Kubernetes-Netzwerkrichtlinien

Überlegungen

Durchsetzung von Richtlinien beim Start Pod

Voraussetzungen

Minimale Cluster-Version

VPC-CNI-Mindestversion

Linux-Kernel-Mindestversion

Konfigurieren Ihres Clusters für die Verwendung von Kubernetes-Netzwerkrichtlinien

Mounten des BPF-Dateisystems

Anmerkung

Aktivieren der Netzwerkrichtlinie in VPC CNI

Deaktivieren Sie Netzwerkrichtlinien

Stars-Demo der Netzwerkrichtlinie

So führen Sie die Stars Policy-Demo aus

Fehlerbehebung bei Netzwerkrichtlinien

Netzwerkrichtlinien-Protokolle

Anmerkung

Amazon-EKS-Add-On

Selbstverwaltetes Add-On

Netzwerkrichtlinien-Protokolle an Amazon CloudWatch Logs senden

Netzwerkrichtlinien-Protokolle mit Amazon VPC CNI plugin for Kubernetes senden

Anmerkung

Voraussetzungen

Amazon-EKS-Add-On

Selbstverwaltetes Add-On

Netzwerkrichtlinien-Protokolle mit einem Fluent Bit-DaemonSet senden

eBPF-SDK eingeschlossen

Kubernetes-Netzwerkrichtlinien