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:

Sie können Fehler bei Netzwerkverbindungen, die Netzwerkrichtlinien verwenden, beheben und untersuchen, indem Sie die Netzwerkrichtlinien-Protokolle lesen und Tools aus dem eBPF-SDK ausführen.

Neue policyendpoints CRD und Berechtigungen

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 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:

Amazon-EKS-Add-On

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

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 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.

Voraussetzungen

Amazon-EKS-Add-On

Selbstverwaltetes Add-On

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 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 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:

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 #327 am dokumentiert. aws-network-policy-agent GitHub GitHub Stellen Sie Pods als Teil einer Bereitstellung oder eines Replikatsatzes bereit, um ein konsistentes Verhalten der Netzwerkrichtlinien zu gewährleisten.