**Unterstützung für die Verbesserung dieser Seite beitragen** 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. Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet. 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. # Fehlerbehebung bei Kubernetes-Netzwerkrichtlinien für Amazon EKS Dies ist die Anleitung zur Fehlerbehebung für die Netzwerkrichtlinien-Feature von Amazon VPC CNI. Dieser Leitfaden behandelt: + Installationsinformationen, CRD- und RBAC-Berechtigungen [Neue `policyendpoints` CRD und Berechtigungen](#network-policies-troubleshooting-permissions) + Protokolle, die bei der Diagnose von Netzwerkrichtlinienproblemen [Netzwerkrichtlinien-Protokolle](#network-policies-troubleshooting-flowlogs) untersucht werden müssen + Ausführung der eBPF-SDK-Tool-Sammlung zur Fehlerbehebung + Bekannte Probleme und Lösungen [Bekannte Probleme und Lösungen](#network-policies-troubleshooting-known-issues) **Anmerkung** Beachten Sie, dass Netzwerkrichtlinien nur auf Pods angewendet werden, die von Kubernetes-*Bereitstellungen* erstellt werden. Weitere Einschränkungen der Netzwerkrichtlinien im VPC CNI finden Sie unter [Überlegungen](cni-network-policy.md#cni-network-policy-considerations). Sie können Fehler bei Netzwerkverbindungen, die Netzwerkrichtlinien verwenden, beheben und untersuchen, indem Sie die [Netzwerkrichtlinien-Protokolle](#network-policies-troubleshooting-flowlogs) lesen und Tools aus dem [eBPF-SDK](#network-policies-ebpf-sdk) ausführen. ## Neue `policyendpoints` CRD und Berechtigungen + CRD: `policyendpoints.networking.k8s.aws` + Kubernetes API: `apiservice` mit dem Namen `v1.networking.k8s.io` + Kubernetes-Ressource: `Kind: NetworkPolicy` + RBAC: `ClusterRole` mit dem Namen `aws-node` (VPC CNI), `ClusterRole` mit dem Namen `eks:network-policy-controller` (Netzwerkrichtlinien-Controller in der EKS-Cluster-Steuerebene) Für die Netzwerkrichtlinie erstellt das VPC CNI ein neues `CustomResourceDefinition` (CRD) mit dem Namen `policyendpoints.networking.k8s.aws`. Das VPC-CNI muss über Berechtigungen zum Erstellen der CRD und zum Erstellen CustomResources (CR) dieser und der anderen von der VPC CNI () installierten CRD verfügen. `eniconfigs.crd.k8s.amazonaws.com` [Beide CRDs sind in der Datei unter verfügbar. `crds.yaml`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) GitHub Insbesondere muss das VPC CNI über die Verb-Berechtigungen „get“, „list“ und „watch“ für `policyendpoints` verfügen. Die Kubernetes-*Netzwerkrichtlinie* ist Teil des `apiservice` mit dem Namen `v1.networking.k8s.io`, und dieser `apiversion: networking.k8s.io/v1` befindet sich in Ihren YAML-Richtliniendateien. Die VPC CNI `DaemonSet` muss über die erforderlichen Berechtigungen verfügen, um diesen Teil der Kubernetes-API nutzen zu können. Die VPC-CNI-Berechtigungen befinden sich in einem `ClusterRole` mit dem Namen `aws-node`. Beachten Sie, dass `ClusterRole`-Objekte nicht in Namespaces gruppiert sind. Nachfolgend wird der `aws-node` eines Clusters dargestellt: ``` kubectl get clusterrole aws-node -o yaml ``` ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: app.kubernetes.io/instance: aws-vpc-cni app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: aws-node app.kubernetes.io/version: v1.19.4 helm.sh/chart: aws-vpc-cni-1.19.4 k8s-app: aws-node name: aws-node rules: - apiGroups: - crd.k8s.amazonaws.com resources: - eniconfigs verbs: - list - watch - get - apiGroups: - "" resources: - namespaces verbs: - list - watch - get - apiGroups: - "" resources: - pods verbs: - list - watch - get - apiGroups: - "" resources: - nodes verbs: - list - watch - get - apiGroups: - "" - events.k8s.io resources: - events verbs: - create - patch - list - apiGroups: - networking.k8s.aws resources: - policyendpoints verbs: - get - list - watch - apiGroups: - networking.k8s.aws resources: - policyendpoints/status verbs: - get - apiGroups: - vpcresources.k8s.aws resources: - cninodes verbs: - get - list - watch - patch ``` Zudem wird in der Steuerebene jedes EKS-Clusters ein neuer Controller ausgeführt. Der Controller verwendet die Berechtigungen des `ClusterRole` mit dem Namen `eks:network-policy-controller`. Nachfolgend wird der `eks:network-policy-controller` eines Clusters dargestellt: ``` kubectl get clusterrole eks:network-policy-controller -o yaml ``` ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: app.kubernetes.io/name: amazon-network-policy-controller-k8s name: eks:network-policy-controller rules: - apiGroups: - "" resources: - namespaces verbs: - get - list - watch - apiGroups: - "" resources: - pods verbs: - get - list - watch - apiGroups: - "" resources: - services verbs: - get - list - watch - apiGroups: - networking.k8s.aws resources: - policyendpoints verbs: - create - delete - get - list - patch - update - watch - apiGroups: - networking.k8s.aws resources: - policyendpoints/finalizers verbs: - update - apiGroups: - networking.k8s.aws resources: - policyendpoints/status verbs: - get - patch - update - apiGroups: - networking.k8s.io resources: - networkpolicies verbs: - get - list - patch - update - watch ``` ## Netzwerkrichtlinien-Protokolle Jede Entscheidung des VPC CNI, ob Verbindungen durch Netzwerkrichtlinien zugelassen oder verweigert werden, wird in *Ablaufprotokollen* festgehalten. 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. Um die Netzwerkrichtlinien-Protokolle zu aktivieren, führen Sie die folgenden Schritte aus: **Anmerkung** Netzwerkrichtlinien-Protokolle erfordern eine zusätzliche 1 vCPU für den `aws-network-policy-agent`-Container im `aws-node`-`DaemonSet`-Manifest von VPC CNI. ### Amazon-EKS-Add-On ** AWS-Managementkonsole ** 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. 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. 1. Wählen Sie die Registerkarte **Add-ons**. 1. Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann **Edit** (Bearbeiten). 1. Auf der Seite **{{Amazon VPC CNI}} konfigurieren**: 1. Wählen Sie `v1.14.0-eksbuild.3` oder eine neuere **Version** in der Dropdown-Liste aus. 1. Erweitern Sie **Optionale Konfigurationseinstellungen**. 1. 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 CloudWatch Logs gesendet werden: ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true" } } ``` Der folgende Screenshot zeigt ein Beispiel für dieses Szenario. ![zeigt das VPC CNI-Add-on mit Netzwerkrichtlinien und CloudWatch Protokollen in der optionalen Konfiguration an.](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/console-cni-config-network-policy-logs.png) AWS CLI 1. Führen Sie den folgenden AWS CLI-Befehl aus. 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 Helm Wenn Sie das Amazon-VPC-CNI-Plugin für Kubernetes über `helm` installiert haben, können Sie die Konfiguration aktualisieren, um die Netzwerkrichtlinien-Protokolle zu schreiben. 1. Führen Sie den folgenden Befehl aus, um die Netzwerkrichtlinie zu aktivieren. ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` kubectl Wenn Sie das Amazon-VPC-CNI-Plugin für Kubernetes über `kubectl` installiert haben, können Sie die Konfiguration aktualisieren, um die Netzwerkrichtlinien-Protokolle zu schreiben. 1. Öffnen Sie das `DaemonSet` `aws-node` in Ihrem Editor. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Ersetzen Sie das `false` durch `true` im Befehlsargument `--enable-policy-event-logs=false` im `args:` im `aws-network-policy-agent`-Container im VPC CNI `aws-node` `DaemonSet`-Manifest. ``` - args: - --enable-policy-event-logs=true ``` ### 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 Richtlinien-Protokolle unter `/aws/eks/{{cluster-name}}/cluster/` und bei selbstverwalteten K8S-Clustern sind die Protokolle unter `/aws/k8s-cluster/cluster/` platziert. #### Senden von Netzwerkrichtlinien-Protokollen mit dem Amazon-VPC-CNI-Plugin für Kubernetes 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-Managementkonsole ** 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. 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. 1. Wählen Sie die Registerkarte **Add-ons**. 1. Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann **Edit** (Bearbeiten). 1. Auf der Seite **{{Amazon VPC CNI}} konfigurieren**: 1. Wählen Sie `v1.14.0-eksbuild.3` oder eine neuere **Version** in der Dropdown-Liste aus. 1. Erweitern Sie **Optionale Konfigurationseinstellungen**. 1. 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. ![zeigt das VPC CNI-Add-on mit Netzwerkrichtlinien und CloudWatch Protokollen in der optionalen Konfiguration an.](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png) ** AWS -CLI** 1. Führen Sie den folgenden AWS CLI-Befehl aus. 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 **Helm** Wenn Sie das Amazon VPC CNI-Plugin für Kubernetes über installiert haben, können Sie die Konfiguration aktualisieren`helm`, um Netzwerkrichtlinienprotokolle an Logs zu senden. CloudWatch 1. Führen Sie den folgenden Befehl aus, um Netzwerkrichtlinien-Protokolle zu aktivieren und sie an Logs zu senden. CloudWatch ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` **kubectl** 1. Öffnen Sie das `DaemonSet` `aws-node` in Ihrem Editor. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Ersetzen Sie das `false` durch `true` zwei Befehlsargumenten `--enable-policy-event-logs=false` im `--enable-cloudwatch-logs=false` im `args:` im `aws-network-policy-agent`-Container im VPC CNI `aws-node` `DaemonSet`-Manifest. ``` - args: - --enable-policy-event-logs=true - --enable-cloudwatch-logs=true ``` #### Netzwerkrichtlinien-Protokolle mit einem Fluent Bit-`DaemonSet` senden Wenn Sie Fluent Bit in einem `DaemonSet` zum Senden von Protokollen von Ihren Knoten verwenden, können Sie eine Konfiguration hinzufügen, um die Netzwerkrichtlinien-Protokolle aus den Netzwerkrichtlinien einzubeziehen. 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 ``` ## Enthaltenes eBPF-SDK Das Amazon-VPC-CNI-Plugin für Kubernetes installiert die eBPF-SDK-Tool-Sammlung 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. ## Bekannte Probleme und Lösungen In den folgenden Abschnitten werden bekannte Probleme mit dem Netzwerkrichtlinien-Feature von Amazon VPC CNI und deren Lösungen beschrieben. ### Netzwerkrichtlinien-Protokolle wurden generiert, obwohl sie auf enable-policy-event-logs „false“ gesetzt sind **Problem**: EKS VPC CNI generiert Netzwerkrichtlinien-Protokolle, auch wenn die `enable-policy-event-logs`-Einstellung auf `false` gesetzt ist. **Lösung**: Diese `enable-policy-event-logs`-Einstellung deaktiviert nur die Protokolle zur „Entscheidung“ über Richtlinien, jedoch nicht die gesamte Protokollierung des Netzwerkrichtlinien-Agenten. Dieses Verhalten ist in der [aws-network-policy-agent README-Datei](https://github.com/aws/aws-network-policy-agent/) unter GitHub dokumentiert. Um die Protokollierung vollständig zu deaktivieren, müssen Sie möglicherweise andere Protokollierungskonfigurationen anpassen. ### Probleme bei der Bereinigung der Netzwerk-Richtlinienzuordnung **Problem**: Probleme mit dem Netzwerk `policyendpoint` bestehen weiterhin und werden nicht bereinigt, nachdem Pods gelöscht wurden. **Lösung**: Dieses Problem wurde durch ein Problem mit dem VPC CNI-Add-on Version 1.19.3-eksbuild.1 verursacht. Aktualisieren Sie auf eine neuere Version des VPC-CNI-Add-Ons, um dieses Problem zu beheben. ### Netzwerkrichtlinien werden nicht angewendet **Problem**: Das Netzwerkrichtlinien-Feature ist im Amazon-VPC-CNI-Plugin aktiviert, aber die Netzwerkrichtlinien werden nicht korrekt angewendet. Wenn Sie eine Netzwerkrichtlinie `kind: NetworkPolicy` erstellen und diese keine Auswirkungen auf den Pod hat, überprüfen Sie, ob das Policyendpoint-Objekt im selben Namespace wie der Pod erstellt wurde. Wenn in den Namespaces keine `policyendpoint`-Objekte vorhanden sind, konnte der Netzwerkrichtlinien-Controller (Teil des EKS-Clusters) keine Netzwerkrichtlinien-Regeln für den Netzwerkrichtlinien-Agenten (Teil des VPC CNI) erstellen. **Lösung**: Die Lösung besteht darin, die Berechtigungen des VPC CNI (`ClusterRole` : `aws-node`) und des Netzwerkrichtlinien-Controllers (`ClusterRole` : `eks:network-policy-controller`) anzupassen und diese Aktionen in jedem Tool zur Durchsetzung von Richtlinien, wie beispielsweise Kyverno, zuzulassen. Stellen Sie sicher, dass Kyverno-Richtlinien die Erstellung von `policyendpoint`-Objekten nicht blockieren. Informationen zu den erforderlichen Berechtigungen in [Neue `policyendpoints` CRD und Berechtigungen](#network-policies-troubleshooting-permissions) finden Sie im vorherigen Abschnitt. ### Pods kehren nach dem Löschen der Richtlinie im strikten Modus nicht in den Standard-Verweigerungsstatus zurück **Problem**: Wenn Netzwerkrichtlinien im strikten Modus aktiviert sind, beginnen Pods mit einer Standard-Verweigerungsrichtlinie. Nachdem die Richtlinien angewendet wurden, wird der Datenverkehr zu den angegebenen Endpunkten zugelassen. Beim Löschen der Richtlinien kehrt der Pod jedoch nicht in den Standard-Verweigerungsstatus zurück, sondern in den Standard-Zulassungsstatus. **Problem**: Dieses Problem wurde in der VPC CNI-Version 1.19.3 behoben, welche die Version 1.2.0 des Netzwerkrichtlinien-Agenten enthielt. Nach der Korrektur und bei aktiviertem strengen Modus kehrt der Pod nach dem Entfernen der Richtlinien wie erwartet in den Standard-Verweigerungsstatus zurück. ### Sicherheitsgruppen für Startup-Verzögerung von Pods **Problem**: Bei Verwendung des Features „Sicherheitsgruppen für Pods“ in EKS kommt es zu einer erhöhten Startup-Verzögerung der Pods. **Lösung**: Die Latenz ist auf die Ratenbegrenzung im Resource Controller durch die API-Drosselung auf der `CreateNetworkInterface` API zurückzuführen, die der VPC-Ressourcencontroller verwendet, um Verzweigungen ENIs für die Pods zu erstellen. Überprüfen Sie die API-Limits Ihres Kontos für diesen Vorgang und beantragen Sie gegebenenfalls eine Limit-Erhöhung. ### FailedScheduling aufgrund unzureichender vpc.amazonaws.com/pod-eni **Problem**: Die Planung von Pods schlägt fehl mit folgendem Fehler: `FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.` **Lösung**: Wie beim vorherigen Problem erhöht die Zuweisung von Sicherheitsgruppen zu Pods die Latenz bei der Pod-Planung und kann über den CNI-Schwellenwert für die Zeit zum Hinzufügen jeder ENI hinausgehen, was zu Fehlern beim Starten von Pods führen kann. Dies ist das erwartete Verhalten bei der Verwendung von Sicherheitsgruppen für Pods. Berücksichtigen Sie beim Entwerfen Ihrer Workload-Architektur die Auswirkungen auf die Planung. ### IPAM-Konnektivitätsprobleme und Segmentierungsfehler **Problem**: Es treten mehrere Fehler auf, darunter Probleme mit der IPAM-Konnektivität, Drosselungsanfragen und Segmentierungsfehler: + `Checking for IPAM connectivity …​` + `Throttling request took 1.047064274s` + `Retrying waiting for IPAM-D` + `panic: runtime error: invalid memory address or nil pointer dereference` **Lösung**: Dieses Problem tritt auf, wenn Sie `systemd-udev` auf AL2 023 installieren, da die Datei neu geschrieben wird und eine Richtlinie verletzt wird. Dies kann bei der Aktualisierung auf ein anderes `releasever` mit einem aktualisierten Paket oder bei der manuellen Aktualisierung des Pakets selbst auftreten. Vermeiden Sie die Installation oder Aktualisierung `systemd-udev` auf AL2 023-Knoten. ### Fehler beim Auffinden des Geräts anhand des Namens **Problem**: Fehlermeldung: `{"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}` **Lösung**: Dieses Problem wurde in den neuesten Versionen des Amazon-VPC-CNI-Netzwerkrichtlinien-Agenten (v1.2.0) erkannt und behoben. Aktualisieren Sie auf die neueste Version von VPC CNI, um dieses Problem zu beheben. ### CVE-Schwachstellen im Multus-CNI-Image **Problem**: Der erweiterte EKS ImageScan CVE-Bericht identifiziert Sicherheitslücken in der Multus CNI-Image-Version v4.1.4-eksbuild.2\_thick. **Lösung**: Aktualisieren Sie auf die neue Version des Multus-CNI-Images und das neue Netzwerkrichtlinien-Controller-Image, die keine Schwachstellen aufweisen. Der Scanner kann aktualisiert werden, um die in der vorherigen Version gefundenen Schwachstellen zu beheben. ### Ablaufinformationen DENY-Urteile in Protokollen **Probleme**: Netzwerkrichtlinien-Protokolle zeigen DENY-Urteile an: `{"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}` **Lösung**: Dieses Problem wurde in der neuen Version des Netzwerkrichtlinien-Controllers behoben. Aktualisieren Sie auf die neueste EKS-Plattformversion, um Protokollierungsprobleme zu beheben. ### Pod-to-pod Kommunikationsprobleme nach der Migration von Calico **Problem**: Nach dem Upgrade eines EKS-Clusters auf Version 1.30 und dem Wechsel von Calico zu Amazon VPC CNI für Netzwerkrichtlinien schlägt die pod-to-pod Kommunikation fehl, wenn Netzwerkrichtlinien angewendet werden. Die Kommunikation wird wiederhergestellt, wenn die Netzwerkrichtlinien gelöscht werden. **Lösung**: Der Netzwerkrichtlinien-Agent im VPC CNI kann nicht so viele Ports wie Calico spezifizieren. Verwenden Sie stattdessen Port-Bereiche in den Netzwerkrichtlinien. Die Höchstzahl der eindeutigen Kombinationen von Ports für jedes Protokoll in jedem `ingress:`- oder `egress:`-Selektor in einer Netzwerkrichtlinie beträgt 24. Verwenden Sie Port-Bereiche, um die Anzahl der eindeutigen Ports zu reduzieren und diese Einschränkung zu vermeiden. ### Netzwerkrichtlinien-Agent unterstützt keine eigenständigen Pods **Problem**: Netzwerkrichtlinien, die auf eigenständige Pods angewendet werden, können zu inkonsistentem Verhalten führen. **Lösung**: Der Netzwerkrichtlinien-Agent unterstützt derzeit nur Pods, die als Teil einer Bereitstellung/eines Replikatsatzes bereitgestellt werden. Wenn Netzwerkrichtlinien auf eigenständige Pods angewendet werden, kann es zu Unstimmigkeiten im Verhalten kommen. [Dies ist oben auf dieser Seite, in und in der Ausgabe [Überlegungen](cni-network-policy.md#cni-network-policy-considerations) \#327 am dokumentiert. aws-network-policy-agent GitHub ](https://github.com/aws/aws-network-policy-agent/issues/327) GitHub Stellen Sie Pods als Teil einer Bereitstellung oder eines Replikatsatzes bereit, um ein konsistentes Verhalten der Netzwerkrichtlinien zu gewährleisten.