Hilf mit, diese Seite 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.

Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, 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 der Leitfaden zur Fehlerbehebung für die Netzwerkrichtlinien-Funktion der Amazon VPC CNI.

Dieses Handbuch behandelt:

Sie können 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 die VPC-CNI eine neue CustomResourceDefinition (CRD) namens. 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 Verbberechtigungen „get“, „list“ und „watch“ für verfügen. policyendpoints

Die Kubernetes-Netzwerkrichtlinie ist Teil der apiservice v1.networking.k8s.io aufgerufenen und apiversion: networking.k8s.io/v1 in Ihren Policy-YAML-Dateien. Das VPC-CNI DaemonSet muss über Berechtigungen verfügen, um diesen Teil der Kubernetes-API zu verwenden.

Die VPC-CNI-Berechtigungen befinden sich in einem ClusterRole Aufruf. aws-node Beachten Sie, dass ClusterRole Objekte nicht in Namespaces gruppiert sind. Das Folgende zeigt die aws-node eines Clusters:

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

Außerdem wird in der Steuerungsebene jedes EKS-Clusters ein neuer Controller ausgeführt. Der Controller verwendet die Berechtigungen des ClusterRole Aufgerufeneneks:network-policy-controller. Das Folgende zeigt die eks:network-policy-controller eines Clusters:

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 der VPC-CNI, ob Verbindungen durch eine Netzwerkrichtlinie zugelassen oder verweigert werden, wird in Flow-Protokollen 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:

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 Netzwerkrichtlinien-Protokolle mithilfe von Diensten wie Amazon CloudWatch Logs überwachen. Sie können die folgenden Methoden verwenden, um die Netzwerkrichtlinien-Protokolle an Logs zu CloudWatch senden.

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

Netzwerkrichtlinienprotokolle mit dem Amazon VPC CNI-Plugin für 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 Netzwerkrichtlinien-Protokolle an Logs senden. CloudWatch

Voraussetzungen

Amazon-EKS-Add-On

Selbstverwaltetes Add-On

Netzwerkrichtlinien-Protokolle mit einem Fluent Bit senden DaemonSet

Wenn Sie Fluent Bit in a verwenden, um Protokolle von Ihren Knoten DaemonSet zu senden, können Sie eine Konfiguration hinzufügen, um die Netzwerkrichtlinien-Protokolle aus 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 eine eBPF-SDK-Sammlung von 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.

Bekannte Probleme und Lösungen

In den folgenden Abschnitten werden bekannte Probleme mit der Amazon VPC CNI-Netzwerkrichtlinien-Funktion und deren Lösungen beschrieben.

Netzwerkrichtlinien-Protokolle wurden generiert, obwohl sie auf enable-policy-event-logs „false“ gesetzt sind

Problem: EKS VPC CNI generiert Netzwerkrichtlinienprotokolle, auch wenn die enable-policy-event-logs Einstellung auf gesetzt ist. false

Lösung: enable-policy-event-logs Mit dieser Einstellung werden nur die „Entscheidungs“ -Protokolle der Richtlinien deaktiviert, nicht jedoch die gesamte Protokollierung des Netzwerkrichtlinien-Agents. Dieses Verhalten ist in der aws-network-policy-agent README-Datei unter dokumentiert. GitHub Um die Protokollierung vollständig zu deaktivieren, müssen Sie möglicherweise andere Protokollierungskonfigurationen anpassen.

Probleme bei der Bereinigung der Netzwerkrichtlinienübersicht

Problem: Probleme mit dem Netzwerk, das nach dem Löschen von Pods policyendpoint immer noch vorhanden ist und nicht bereinigt wird.

Lösung: Dieses Problem wurde durch ein Problem mit der 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: Die Netzwerkrichtlinien-Funktion ist im Amazon VPC CNI-Plugin aktiviert, aber die Netzwerkrichtlinien werden nicht korrekt angewendet.

Wenn Sie eine Netzwerkrichtlinie erstellen kind: NetworkPolicy und diese sich nicht auf den Pod auswirkt, überprüfen Sie, ob das Policyendpoint-Objekt im selben Namespace wie der Pod erstellt wurde. Wenn die Namespaces keine policyendpoint Objekte enthalten, konnte der Netzwerkrichtlinien-Controller (Teil des EKS-Clusters) keine Netzwerkrichtlinienregeln erstellen, die der Netzwerkrichtlinien-Agent (Teil des VPC-CNI) anwenden sollte.

Lösung: Die Lösung besteht darin, die Berechtigungen des VPC-CNI (ClusterRole:aws-node) und des Netzwerkrichtlinien-Controllers (ClusterRole:eks:network-policy-controller) zu korrigieren und diese Aktionen in jedem Tool zur Durchsetzung von Richtlinien wie Kyverno zuzulassen. Stellen Sie sicher, dass die Kyverbo-Richtlinien die Erstellung von Objekten nicht blockieren. policyendpoint Informationen zu den erforderlichen Berechtigungen finden Sie im vorherigen Abschnitt unter. Neue policyendpoints CRD und Berechtigungen

Pods kehren nach dem Löschen der Richtlinie im strikten Modus nicht zum Standardstatus „Ablehnen“ zurück

Problem: Wenn Netzwerkrichtlinien im strikten Modus aktiviert sind, beginnen Pods mit einer standardmäßigen Ablehnungsrichtlinie. Nachdem die Richtlinien angewendet wurden, ist Datenverkehr zu den angegebenen Endpunkten zulässig. Wenn Richtlinien gelöscht werden, kehrt der Pod jedoch nicht in den Standardstatus „Ablehnen“ zurück, sondern in den Standardstatus „Zulassen“.

Lösung: Dieses Problem wurde in der Version 1.19.3 von VPC CNI behoben, zu der auch die Version 1.2.0 des Network Policy Agent gehörte. Nach dem Fix, bei aktiviertem strikten Modus, kehrt der Pod nach dem Entfernen der Richtlinien erwartungsgemäß in den standardmäßigen Ablehnungsstatus zurück.

Sicherheitsgruppen für die Startlatenz von Pods

Problem: Bei Verwendung der Funktion „Sicherheitsgruppen für Pods“ in EKS kommt es zu einer erhöhten Latenz beim Pod-Start.

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. Prüfen Sie die API-Grenzwerte Ihres Kontos für diesen Vorgang und erwägen Sie, falls erforderlich, eine Erhöhung des Limits zu beantragen.

FailedScheduling aufgrund unzureichender vpc.amazonaws.com/pod-eni

Problem: Pods können nicht geplant werden und es wird folgender Fehler angezeigt: 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 den CNI-Schwellenwert für das Hinzufügen der einzelnen ENI überschreiten, was zu Fehlern beim Starten von Pods führen kann. Dieses Verhalten ist bei der Verwendung von Sicherheitsgruppen für Pods zu erwarten. 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 IPAM-Konnektivitätsprobleme, Drosselungsanforderungen und Segmentierungsfehler:

Lösung: Dieses Problem tritt auf, wenn Sie systemd-udev auf AL2 023 installieren, da die Datei neu geschrieben wird, wobei die Richtlinie nicht eingehalten wird. Dies kann passieren, wenn Sie auf ein anderes Paket aktualisierenreleasever, das über ein aktualisiertes Paket verfügt, oder wenn Sie das Paket selbst manuell aktualisieren. Vermeiden Sie die Installation oder Aktualisierung systemd-udev auf AL2 023-Knoten.

Fehler beim Finden 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 Network Policy Agent (v1.2.0) identifiziert 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 des neuen Network Policy Controller-Images, die keine Sicherheitslücken aufweisen. Der Scanner kann aktualisiert werden, um die in der vorherigen Version gefundenen Sicherheitslücken zu beheben.

Flow Info DENY urteilt in Protokollen

Problem: In den Protokollen der Netzwerkrichtlinien werden DENY-Urteile angezeigt: {"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 Network Policy Controllers behoben. Aktualisieren Sie auf die neueste Version der EKS-Plattform, um Probleme mit der Protokollierung 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 Netzwerkrichtlinien gelöscht werden.

Lösung: Für den Netzwerkrichtlinien-Agenten in der VPC-CNI können nicht so viele Ports angegeben werden wie bei Calico. Verwenden Sie stattdessen Portbereiche in den Netzwerkrichtlinien. 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. Verwenden Sie Portbereiche, um die Anzahl der eindeutigen Ports zu reduzieren und diese Einschränkung zu umgehen.

Der Netzwerkrichtlinien-Agent unterstützt keine eigenständigen Pods

Problem: Netzwerkrichtlinien, die auf eigenständige Pods angewendet werden, verhalten sich möglicherweise inkonsistent.

Lösung: Der Network Policy Agent unterstützt derzeit nur Pods, die als Teil einer Bereitstellung/eines Replikats bereitgestellt werden. Wenn Netzwerkrichtlinien auf eigenständige Pods angewendet werden, kann es zu Inkonsistenzen im Verhalten kommen. Dies ist oben auf dieser Seite, in und in der Überlegungen aws-network-policy-agent GitHub Ausgabe #327 am dokumentiert. GitHub Stellen Sie Pods als Teil einer Bereitstellung oder eines Replikats bereit, um ein einheitliches Verhalten der Netzwerkrichtlinien zu gewährleisten.