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
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
- oderIPv6
-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 können PodsSie den Zugriff auf AWS-Services von 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
ingress:
oderegress:
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 Pod Startup
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 Standard-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 wird.
Sie können diese Standardnetzwerkrichtlinie ändern, indem Sie die Umgebungsvariable
strict
imaws-node
Container der VPC CNINETWORK_POLICY_ENFORCING_MODE
auf setzenDaemonSet
.env: - name: NETWORK_POLICY_ENFORCING_MODE value: "strict"
Wenn die Variable auf
NETWORK_POLICY_ENFORCING_MODE
gesetzt iststrict
, beginnen Pods, die die VPC CNI verwenden, mit einer Standard-Verweigerungsrichtlinie und dann werden Richtlinien konfiguriert. Dies wird als strikter Modus bezeichnet. Im strikten Modus müssen Sie über eine Netzwerkrichtlinie für jeden Endpunkt verfügen, auf den Ihre Pods in Ihrem Cluster zugreifen müssen. Beachten Sie, dass diese Anforderung für die CoreDNS Pods gilt. Die Standard-Verweigerungsrichtlinie ist nicht für Pods mit Host-Netzwerk konfiguriert. -
Das Netzwerkrichtlinienfeature erstellt und erfordert die Definition einer benutzerdefinierten
PolicyEndpoint
-Ressource (Custom Resource Definition, CRD) namenspolicyendpoints.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 VariableENABLE_V4_EGRESS
auftrue
festgelegt ist. Diese Variable ermöglicht es derIPv4
-Ausgangsfunktion, eine Verbindung zwischen den IPv6-Pods undIPv4
-Endpunkten (beispielsweise außerhalb des Clusters) herzustellen. DieIPv4
-Ausgangsfunktion erstellt eine zusätzliche Netzwerkschnittstelle mit einer lokalen IPv4-Loopback-Adresse. -
Bei Verwendung von verketteten Netzwerk-Plugins wie Multus. 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 Port8163
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-Versionv1.14.1
oder höher können Sie diese Ports an den folgenden Stellen ändern:
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 Siemy-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 textKubernetes-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 Version1.14
oder höher. -
Linux-Kernel-Mindestversion
Ihre Knoten müssen eine Linux-Kernelversion ab Version
5.10
haben. Sie können Ihre Kernelversion mituname -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-Version5.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ür1.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 Versionv1.0.2
aktualisieren.-
Mounten Sie das Berkeley Packet Filter (BPF)-Dateisystem auf jedem Ihrer Knoten.
sudo mount -t bpf bpffs /sys/fs/bpf
-
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
-
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 textWenn 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.
-
-
Amazon-EKS-Add-On
-
Selbstverwaltetes Add-On
-
-
-
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) 24hWenn die Netzwerkrichtlinie aktiviert ist, 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 denaws-node
-Pods.Sie können jetzt Kubernetes-Netzwerkrichtlinien für Ihren Cluster bereitstellen. Weitere Informationen finden Sie unter Kubernetes-Netzwerkrichtlinien.
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 SpalteREADY
unterscheiden sich von den Angaben in der folgenden Ausgabe. Fahren Sie erst dann fort, wenn Pods mit ähnlichen Namen angezeigt werden und bei allenRunning
in der SpalteSTATUS
aufgeführt wird.NAMESPACE NAME READY STATUS RESTARTS AGE [...] client client-
xlffc
1/1
Running 05m19s
[...] management-ui management-ui-qrb2g
1/1
Running 05m24s
stars backend-sz87q
1/1
Running 05m23s
stars frontend-cscnf
1/1
Running 05m21s
[...] -
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 denclient
-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"}
Netzwerkrichtlinienprotokolle sind standardmäßig deaktiviert. Gehen Sie folgendermaßen vor, um die Netzwerkrichtlinienprotokolle zu aktivieren:
Anmerkung
Netzwerkrichtlinienprotokolle erfordern zusätzliche 1 vCPU für den aws-network-policy-agent
Container im VPC-CNI-aws-node
Daemonset-Manifest.
Amazon-EKS-Add-On
Selbstverwaltetes Add-On
Senden von Netzwerkrichtlinienprotokollen an Amazon CloudWatch Logs
Sie können die Netzwerkrichtlinienprotokolle mithilfe von Services wie Amazon CloudWatch Logs überwachen. Sie können die folgenden Methoden verwenden, um die Netzwerkrichtlinienprotokolle an CloudWatch -Protokolle zu senden.
Bei EKS-Clustern befinden sich die Richtlinienprotokolle unter /aws/eks/
und bei selbstverwalteten K8S-Clustern unter cluster-name
/cluster//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 Knotenagent kann die Netzwerkrichtlinienprotokolle an CloudWatch -Protokolle 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
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
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