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.
Amazon VPC CNI
Tipp
Lernen Sie in Amazon EKS-Workshops
Amazon EKS implementiert Cluster-Netzwerke über das Amazon VPC Container Network
Amazon VPC CNI besteht aus zwei Komponenten:
-
CNI Binary, mit dem das Pod-Netzwerk eingerichtet wird, um die Kommunikation zu ermöglichen. Pod-to-Pod Die CNI-Binärdatei läuft auf einem Node-Root-Dateisystem und wird vom Kubelet aufgerufen, wenn ein neuer Pod zum Knoten hinzugefügt oder ein vorhandener Pod aus dem Knoten entfernt wird.
-
ipamd, ein seit langem laufender Node-Local IP Address Management (IPAM) -Daemon, der verantwortlich ist für:
-
Verwaltung von ENIs auf einem Knoten und
-
Aufrechterhaltung eines Warm-Pools verfügbarer IP-Adressen oder Präfixe
-
Wenn eine Instance erstellt wird, erstellt EC2 eine primäre ENI, die einem primären Subnetz zugeordnet ist, und fügt sie an. Das primäre Subnetz kann öffentlich oder privat sein. Die Pods, die im HostNetwork-Modus ausgeführt werden, verwenden die primäre IP-Adresse, die dem primären ENI des Knotens zugewiesen ist, und verwenden denselben Netzwerk-Namespace wie der Host.
Das CNI-Plugin verwaltet Elastic Network Interfaces (ENI) auf dem Knoten. Wenn ein Knoten bereitgestellt wird, weist das CNI-Plugin dem primären ENI automatisch einen Pool von Steckplätzen (IPs oder Präfixe) aus dem Subnetz des Knotens zu. Dieser Pool wird als Warm Pool bezeichnet, und seine Größe wird durch den Instanztyp des Knotens bestimmt. Je nach CNI-Einstellungen kann es sich bei einem Slot um eine IP-Adresse oder ein Präfix handeln. Wenn ein Slot auf einer ENI zugewiesen wurde, kann das CNI den Knoten zusätzliche ENIs mit einem warmen Pool von Steckplätzen zuordnen. Diese zusätzlichen ENIs werden als sekundäre ENIs bezeichnet. Jede ENI kann je nach Instance-Typ nur eine bestimmte Anzahl von Steckplätzen unterstützen. Das CNI ordnet Instances je nach Anzahl der benötigten Steckplätze, die normalerweise der Anzahl der Pods entspricht, mehr ENIs zu. Dieser Vorgang wird fortgesetzt, bis der Knoten keine zusätzlichen ENI mehr unterstützen kann. Das CNI weist außerdem „warme“ ENIs und Steckplätze für einen schnelleren Pod-Start vorab zu. Beachten Sie, dass jeder Instance-Typ eine maximale Anzahl von ENIs hat, die angehängt werden können. Dies ist zusätzlich zu den Rechenressourcen eine Einschränkung der Pod-Dichte (Anzahl der Pods pro Knoten).
Die maximale Anzahl an Netzwerkschnittstellen und die maximale Anzahl an Steckplätzen, die Sie verwenden können, variieren je nach Typ der EC2-Instance. Da jeder Pod eine IP-Adresse an einem Steckplatz verbraucht, hängt die Anzahl der Pods, die Sie auf einer bestimmten EC2-Instance ausführen können, davon ab, wie viele ENIs an ihn angeschlossen werden können und wie viele Steckplätze jeder ENI unterstützt. Wir empfehlen, die maximale Anzahl von Pods pro EKS-Benutzerhandbuch festzulegen, um eine Erschöpfung der CPU- und Speicherressourcen der Instance zu vermeiden. Pods, hostNetwork die verwendet werden, sind von dieser Berechnung ausgeschlossen. Weitere Informationen finden Sie im Amazon EKS-Benutzerhandbuch unter So wird MaxPods bestimmt.
-Übersicht
Der sekundäre IP-Modus ist der Standardmodus für VPC CNI. Dieses Handbuch bietet einen allgemeinen Überblick über das VPC-CNI-Verhalten, wenn der sekundäre IP-Modus aktiviert ist. Die Funktionalität von ipamd (Zuweisung von IP-Adressen) kann je nach den Konfigurationseinstellungen für VPC CNI variieren, z. B., und. Präfix-Modus für Linux Sicherheitsgruppen pro Pod Benutzerdefiniertes Netzwerk
Das Amazon VPC CNI wird als Kubernetes-Daemonset mit dem Namen aws-node auf Worker-Knoten bereitgestellt. Wenn ein Worker-Knoten bereitgestellt wird, ist ihm eine Standard-ENI, die sogenannte primäre ENI, zugeordnet. Das CNI weist einen warmen Pool von ENIs und sekundären IP-Adressen aus dem Subnetz zu, das an die primäre ENI des Knotens angeschlossen ist. Standardmäßig versucht ipamd, dem Knoten eine zusätzliche ENI zuzuweisen. Die IPAMD weist zusätzliche ENI zu, wenn ein einzelner Pod geplant ist und ihm eine sekundäre IP-Adresse von der primären ENI zugewiesen wird. Dieses „warme“ ENI ermöglicht ein schnelleres Pod-Netzwerk. Wenn der Pool an sekundären IP-Adressen zur Neige geht, fügt das CNI eine weitere ENI hinzu, um weitere IP-Adressen zuzuweisen.
Die Anzahl der ENIs und IP-Adressen in einem Pool wird durch Umgebungsvariablen namens WARM_ENI_TARGET, WARM_IP_TARGET, MINIMUM_IP_TARGET konfiguriert. aws-node Eine ausreichende Anzahl von ENIs ist angeschlossen, wenn alle BedingungenWARM_ENI_TARGET, oder WARM_IP_TARGET und MINIMUM_IP_TARGET erfüllt sind. Wenn nicht genügend ENIs angeschlossen sind, sendet das CNI einen API-Aufruf an EC2, um weitere anzuhängen, bis MAX_ENI das Limit erreicht ist.
-
WARM_ENI_TARGET- Ganzzahl, Werte größer als 0 geben an, dass die Anforderung aktiviert ist-
Die Anzahl der Warm-ENIs, die beibehalten werden sollen. Ein ENI ist „warm“, wenn es als sekundäres ENI an einen Knoten angehängt ist, aber von keinem Pod verwendet wird. Genauer gesagt wurden keine IP-Adressen der ENI mit einem Pod verknüpft.
-
Beispiel: Stellen Sie sich eine Instanz mit 2 ENIs vor, wobei jede ENI 5 IP-Adressen unterstützt. WARM_ENI_TARGET ist auf 1 gesetzt. Wenn der Instanz genau 5 IP-Adressen zugeordnet sind, verwaltet das CNI 2 ENIs, die an die Instanz angehängt sind. Die erste ENI wird verwendet, und alle 5 möglichen IP-Adressen dieser ENI werden verwendet. Die zweite ENI ist „warm“, da sich alle 5 IP-Adressen im Pool befinden. Wenn ein weiterer Pod auf der Instance gestartet wird, wird eine sechste IP-Adresse benötigt. Das CNI weist diesem 6. Pod eine IP-Adresse aus dem zweiten ENI und 5 IP-Adressen aus dem Pool zu. Die zweite ENI wird jetzt verwendet und befindet sich nicht mehr im Status „warm“. Das CNI weist eine dritte ENI zu, um mindestens eine warme ENI aufrechtzuerhalten.
-
Anmerkung
Die warmen ENIs verbrauchen weiterhin IP-Adressen aus dem CIDR Ihrer VPC. IP-Adressen sind „unbenutzt“ oder „warm“, bis sie einer Arbeitslast zugeordnet werden, z. B. einem Pod.
-
WARM_IP_TARGET, Integer, Werte größer als 0 geben an, dass die Anforderung Aktiviert ist-
Die Anzahl der Warm-IP-Adressen, die beibehalten werden sollen. Eine Warm-IP ist auf einem aktiv angeschlossenen ENI verfügbar, wurde aber keinem Pod zugewiesen. Mit anderen Worten, die Anzahl der verfügbaren Warm-IPs ist die Anzahl der IPs, die einem Pod zugewiesen werden können, ohne dass eine zusätzliche ENI erforderlich ist.
-
Beispiel: Stellen Sie sich eine Instanz mit 1 ENI vor, wobei jede ENI 20 IP-Adressen unterstützt. WARM_IP_TARGET ist auf 5 gesetzt. WARM_ENI_TARGET ist auf 0 gesetzt. Es wird nur 1 ENI angehängt, bis eine 16. IP-Adresse benötigt wird. Dann hängt das CNI eine zweite ENI an, wodurch 20 mögliche Adressen aus dem Subnetz-CIDR verbraucht werden.
-
-
MINIMUM_IP_TARGET, Integer, Werte größer als 0 geben an, dass die Anforderung Aktiviert ist-
Die Mindestanzahl von IP-Adressen, die zu einem beliebigen Zeitpunkt zugewiesen werden müssen. Dies wird häufig verwendet, um die Zuweisung mehrerer ENIs beim Start der Instance vorab vorzunehmen.
-
Beispiel: Stellen Sie sich eine neu gestartete Instance vor. Sie hat 1 ENI und jede ENI unterstützt 10 IP-Adressen. MINIMUM_IP_TARGET ist auf 100 gesetzt. Die ENI fügt sofort 9 weitere ENIs hinzu, was insgesamt 100 Adressen ergibt. Dies geschieht unabhängig von WARM_IP_TARGET- oder WARM_ENI_TARGET-Werten.
-
Dieses Projekt beinhaltet ein Excel-Dokument für den Subnetzrechner. https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsxWARM_IP_TARGET und. WARM_ENI_TARGET
Wenn Kubelet eine Anfrage zum Hinzufügen eines Pods erhält, fragt die CNI-Binärdatei ipamd nach einer verfügbaren IP-Adresse ab, die ipamd dann dem Pod zur Verfügung stellt. Die CNI-Binärdatei verbindet den Host und das Pod-Netzwerk.
Auf einem Knoten bereitgestellte Pods werden standardmäßig denselben Sicherheitsgruppen zugewiesen wie die primäre ENI. Alternativ können Pods mit verschiedenen Sicherheitsgruppen konfiguriert werden.
Wenn der Pool von IP-Adressen aufgebraucht ist, fügt das Plugin automatisch eine weitere Elastic Network-Schnittstelle an die Instance an und weist dieser Schnittstelle einen weiteren Satz sekundärer IP-Adressen zu. Dieser Vorgang wird fortgesetzt, bis der Knoten keine zusätzlichen Elastic Network-Schnittstellen mehr unterstützen kann.
Wenn ein Pod gelöscht wird, platziert VPC CNI die IP-Adresse des Pods in einem 30-sekündigen Cooldown-Cache. Die IPs in einem Cooldown-Cache werden neuen Pods nicht zugewiesen. Wenn die Abkühlphase abgelaufen ist, verschiebt VPC CNI die Pod-IP zurück in den warmen Pool. Die Abkühlphase verhindert, dass Pod-IP-Adressen vorzeitig wiederverwendet werden, und ermöglicht Kube-Proxy auf allen Clusterknoten, die Aktualisierung der Iptables-Regeln abzuschließen. Wenn die Anzahl der IPs oder ENIs die Anzahl der Warm-Pool-Einstellungen überschreitet, gibt das ipamd-Plugin IPs und ENIs an die VPC zurück.
Wie oben im sekundären IP-Modus beschrieben, erhält jeder Pod eine sekundäre private IP-Adresse von einer der ENIs, die mit einer Instance verbunden sind. Da jeder Pod eine IP-Adresse verwendet, hängt die Anzahl der Pods, die Sie auf einer bestimmten EC2-Instance ausführen können, davon ab, wie viele ENIs an ihn angeschlossen werden können und wie viele IP-Adressen er unterstützt. Das VPC-CNI überprüft die https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/aws/vpc/limits.go
Sie können die folgende Formel verwenden, um die maximale Anzahl von Pods zu ermitteln, die Sie auf einem Knoten bereitstellen können.
(Number of network interfaces for the instance type * (the number of IP addresses per network interface - 1)) + 2
Die +2 gibt Pods an, die ein Host-Netzwerk benötigen, wie Kube-Proxy und VPC CNI. Amazon EKS erfordert, dass Kube-Proxy und VPC CNI auf jedem Knoten ausgeführt werden. Diese Anforderungen werden beim Max-Pods-Wert berücksichtigt. Wenn Sie zusätzliche Host-Netzwerk-Pods ausführen möchten, sollten Sie erwägen, den Max-Pods-Wert zu aktualisieren. Sie können in --kubelet-extra-args "—max-pods=110" der Startvorlage Benutzerdaten angeben.
Beispiel: In einem Cluster mit 3 c5.large-Knoten (3 ENIs und maximal 10 IPs pro ENI) verbraucht das CNI beim Start des Clusters mit 2 CoreDNS-Pods 50 IP-Adressen und speichert 43 IP-Adressen im Warmpool. Der warme Pool ermöglicht schnellere Pod-Starts, wenn die Anwendung bereitgestellt wird.
Knoten 1 (mit CoreDNS-Pod): 2 ENIs, 20 zugewiesene IPs
Knoten 2 (mit CoreDNS-Pod): 2 ENIs, 20 zugewiesene IPs
Knoten 3 (kein Pod): 1 ENI. 10 IPs zugewiesen.
Für Knoten 1 und Knoten 2 (identische Konfiguration):
-
2 ENIs × 10 IPs pro ENI = 20 IPs insgesamt
-
Subtrahieren Sie 2 primäre IPs (1 pro ENI) = 18 IPs
-
Subtrahieren Sie 1 IP für den CoreDNS-Pod = 17 verfügbare IPs
-
Jeder dieser Knoten hat also 17 IPs im warmen Pool
Für Knoten 3:
-
1 ENI × 10 IPs = 10 IPs insgesamt
-
Subtrahieren Sie 1 primäre IP = 9 IPs, die im warmen Pool verfügbar sind
Berechnung des gesamten warmen Pools: - 17 (Knoten 1) + 17 (Knoten 2) + 9 (Knoten 3) = 43 IPs
Denken Sie daran, dass Infrastruktur-Pods, die oft als Daemon-Sets ausgeführt werden, jeweils zur maximalen Pod-Anzahl beitragen. Diese können Folgendes beinhalten:
-
CoreDNS
-
Amazon Elastic LoadBalancer
-
Betriebsbereite Pods für den Metrics-Server
Wir empfehlen Ihnen, Ihre Infrastruktur zu planen, indem Sie die Kapazitäten dieser Pods kombinieren. Eine Liste der maximalen Anzahl von Pods, die von jedem Instance-Typ unterstützt werden, finden Sie unter eni-max-pods.txt
Empfehlungen
Stellen Sie den EKS-Cluster im automatischen Modus bereit
Wenn Sie den EKS-Automodus verwenden, um einen Cluster zu erstellen, verwaltet AWS die VPC Container Network Interface (CNI) -Konfiguration für Ihren Cluster. Mit Amazon EKS Auto Mode ist es nicht erforderlich, Netzwerk-Add-Ons zu installieren oder zu aktualisieren. Stellen Sie jedoch sicher, dass Ihre Workloads mit der verwalteten VPC-CNI-Konfiguration kompatibel sind.
Stellen Sie VPC CNI Managed bereit Add-On
Wenn Sie einen Cluster bereitstellen, installiert Amazon EKS VPC CNI automatisch. Amazon EKS unterstützt dennoch verwaltete Add-Ons, die es dem Cluster ermöglichen, mit den zugrunde liegenden AWS-Ressourcen wie Datenverarbeitung, Speicher und Netzwerk zu interagieren. Wir empfehlen dringend, Cluster mit verwalteten Add-Ons, einschließlich VPC CNI, bereitzustellen.
Das von Amazon EKS verwaltete Add-on bietet die Installation und Verwaltung von VPC CNI für Amazon EKS-Cluster. Die Amazon EKS-Add-Ons enthalten die neuesten Sicherheitspatches und Bugfixes und wurden von AWS für die Verwendung mit Amazon EKS validiert. Das VPC CNI-Add-on ermöglicht es Ihnen, die Sicherheit und Stabilität Ihrer Amazon EKS-Cluster kontinuierlich zu gewährleisten und den Aufwand für die Installation, Konfiguration und Aktualisierung von Add-Ons zu verringern. Darüber hinaus kann ein verwaltetes Add-on über die Amazon EKS-API, die AWS-Managementkonsole, die AWS-CLI und eksctl hinzugefügt, aktualisiert oder gelöscht werden.
Sie können die verwalteten Felder von VPC CNI finden, indem Sie das --show-managed-fields Flag mit dem Befehl verwenden. kubectl get
kubectl get daemonset aws-node --show-managed-fields -n kube-system -o yaml
Verwaltete Add-Ons verhindern Konfigurationsabweichungen, indem Konfigurationen automatisch alle 15 Minuten überschrieben werden. Das bedeutet, dass alle Änderungen an verwalteten Add-Ons, die nach der Erstellung des Add-Ons über die Kubernetes-API vorgenommen werden, durch den automatisierten Drift-Präventionsprozess überschrieben werden und auch während des Add-On-Aktualisierungsprozesses auf Standardwerte gesetzt werden.
Die von EKS verwalteten Felder sind unter ManagedFields mit Manager als EKS aufgeführt. Zu den von EKS verwalteten Feldern gehören Dienstkonto, Image, Bild-URL, Liveness Test, Readiness Test, Labels, Volumes und Volume Mounts.
Anmerkung
Die am häufigsten verwendeten Felder wie WARM_ENI_TARGET, WARM_IP_TARGET und MINIMUM_IP_TARGET werden nicht verwaltet und werden nicht abgeglichen. Die Änderungen an diesen Feldern bleiben bei der Aktualisierung des Add-ons erhalten.
Wir empfehlen, das Verhalten des Add-Ons in Ihren Nicht-Produktionsclustern für eine bestimmte Konfiguration zu testen, bevor Sie Produktionscluster aktualisieren. Folgen Sie außerdem den Schritten im EKS-Benutzerhandbuch für https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html Zusatzkonfigurationen.
Migrieren Sie zu Managed Add-On
Sie verwalten die Versionskompatibilität und aktualisieren die Sicherheitspatches der selbstverwalteten VPC CNI. Um ein selbstverwaltetes Add-on zu aktualisieren, müssen Sie die Kubernetes-APIs und Anweisungen verwenden, die im EKS-Benutzerhandbuch beschrieben sind. https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#updating-vpc-cni-add-on Wir empfehlen die Migration zu einem verwalteten Add-on für bestehende EKS-Cluster und empfehlen dringend, vor der Migration ein Backup Ihrer aktuellen CNI-Einstellungen zu erstellen. Um verwaltete Add-Ons zu konfigurieren, können Sie die Amazon EKS-API, die AWS-Managementkonsole oder die AWS-Befehlszeilenschnittstelle verwenden.
kubectl apply view-last-applied daemonset aws-node -n kube-system aws-k8s-cni-old.yaml
Amazon EKS ersetzt die CNI-Konfigurationseinstellungen, wenn das Feld als verwaltet mit Standardeinstellungen aufgeführt ist. Wir warnen davor, die verwalteten Felder zu ändern. Das Add-on gleicht Konfigurationsfelder wie die warmen Umgebungsvariablen und die CNI-Modi nicht ab. Die Pods und Anwendungen werden weiterhin ausgeführt, während Sie zu einem verwalteten CNI migrieren.
Sichern Sie die CNI-Einstellungen vor dem Update
VPC CNI wird auf der Kundendatenebene (Knoten) ausgeführt. Daher aktualisiert Amazon EKS das Add-on (verwaltet und selbstverwaltet) nicht automatisch, wenn neue Versionen veröffentlicht werden oder nachdem Sie Ihren Cluster auf eine neue Kubernetes-Nebenversion aktualisiert haben. Um das Add-on für einen vorhandenen Cluster zu aktualisieren, müssen Sie ein Update über die Update-Addon-API auslösen oder in der EKS-Konsole für Add-Ons auf den Link Jetzt aktualisieren klicken. Wenn Sie ein selbstverwaltetes Add-on bereitgestellt haben, folgen Sie den Schritten unter Aktualisierung des selbstverwalteten VPC-CNI-Add-ons.
Wir empfehlen dringend, dass Sie jeweils eine Nebenversion aktualisieren. Wenn Ihre aktuelle Nebenversion beispielsweise 1.9 ist und Sie auf 1.11 aktualisieren möchten, sollten Sie zuerst auf die neueste Patch-Version von 1.10 aktualisieren und dann auf die neueste Patch-Version von 1.11 aktualisieren.
Führen Sie eine Inspektion des AWS-Node Daemonset durch, bevor Sie Amazon VPC CNI aktualisieren. Erstellen Sie eine Sicherungskopie der vorhandenen Einstellungen. Wenn Sie ein verwaltetes Add-on verwenden, stellen Sie sicher, dass Sie keine Einstellungen aktualisiert haben, die Amazon EKS möglicherweise überschreibt. Wir empfehlen einen Hook nach dem Update in Ihrem Automatisierungsworkflow oder einen manuellen Anwendungsschritt nach einem Add-On-Update.
kubectl apply view-last-applied daemonset aws-node -n kube-system aws-k8s-cni-old.yaml
Bei einem selbstverwalteten Add-on vergleichen Sie das Backup mit einemreleases, GitHub um die verfügbaren Versionen zu sehen und sich mit den Änderungen in der Version vertraut zu machen, auf die Sie aktualisieren möchten. Wir empfehlen, Helm zu verwenden, um selbstverwaltete Add-Ons zu verwalten und Wertedateien zu nutzen, um Einstellungen anzuwenden. Alle Aktualisierungsvorgänge, bei denen Daemonset gelöscht wird, führen zu Ausfallzeiten der Anwendung und müssen vermieden werden.
Verstehen Sie den Sicherheitskontext
Wir empfehlen Ihnen dringend, die Sicherheitskontexte zu verstehen, die für die effiziente Verwaltung von VPC CNI konfiguriert sind. Amazon VPC CNI besteht aus zwei Komponenten: CNI-Binärdatei und ipamd (aws-node) Daemonset. Das CNI läuft als Binärdatei auf einem Knoten und hat Zugriff auf das Root-Dateisystem des Knotens. Außerdem hat es privilegierten Zugriff, da es sich um Iptables auf Knotenebene handelt. Die CNI-Binärdatei wird vom Kubelet aufgerufen, wenn Pods hinzugefügt oder entfernt werden.
Das aws-node Daemonset ist ein langwieriger Prozess, der für die IP-Adressverwaltung auf Knotenebene verantwortlich ist. Der AWS-Node wird im hostNetwork Modus ausgeführt und ermöglicht den Zugriff auf das Loopback-Gerät sowie die Netzwerkaktivität anderer Pods auf demselben Knoten. Der AWS-Node-Init-Container wird im privilegierten Modus ausgeführt und mountet den CRI-Socket, sodass das Daemonset die IP-Nutzung durch die auf dem Knoten laufenden Pods überwachen kann. Amazon EKS arbeitet daran, die privilegierte Anforderung des AWS-Node-Init-Containers zu entfernen. Darüber hinaus muss der aws-node die NAT-Einträge aktualisieren und die iptables-Module laden und wird daher mit NET_ADMIN-Rechten ausgeführt.
Amazon EKS empfiehlt, die im AWS-Node-Manifest definierten Sicherheitsrichtlinien für die IP-Verwaltung der Pods und Netzwerkeinstellungen bereitzustellen. Bitte erwägen Sie, auf die neueste Version von VPC CNI zu aktualisieren. Bitte erwägen Sie außerdem, ein GitHub Problem zu eröffnen,
Verwenden Sie eine separate IAM-Rolle für CNI
Das AWS VPC CNI erfordert AWS-Berechtigungen für Identity and Access Management (IAM). Die CNI-Richtlinie muss eingerichtet werden, bevor die IAM-Rolle verwendet werden kann. Sie können AmazonEKS_CNI_Policy
Standardmäßig erbt VPC CNI die Amazon EKS-Knoten-IAM-Rolle (sowohl verwaltete als auch selbstverwaltete Knotengruppen).
Es wird dringend empfohlen, eine separate IAM-Rolle mit den entsprechenden Richtlinien für Amazon VPC CNI zu konfigurieren. Andernfalls erhalten die Pods von Amazon VPC CNI die der Node-IAM-Rolle zugewiesene Berechtigung und haben Zugriff auf das Instance-Profil, das dem Knoten zugewiesen ist.
Das VPC CNI-Plugin erstellt und konfiguriert ein Dienstkonto namens aws-node. Standardmäßig ist das Servicekonto an die IAM-Rolle des Amazon EKS-Knotens gebunden, an die eine Amazon EKS-CNI-Richtlinie angehängt ist. Um die separate IAM-Rolle zu verwenden, empfehlen wir, ein neues Servicekonto zu erstellen, an das die Amazon EKS-CNI-Richtlinie angehängt ist. Um ein neues Dienstkonto zu verwenden, müssen Sie die CNI-Pods erneut bereitstellen. Erwägen Sie, bei der Erstellung neuer Cluster ein --service-account-role-arn für VPC von CNI verwaltetes Add-on anzugeben. Stellen Sie sicher, dass Sie die Amazon EKS-CNI-Richtlinie sowohl für IPv4 als auch für IPv6 aus der Amazon EKS-Knotenrolle entfernen.
Es wird empfohlen, die Metadaten der Access-Instance zu blockieren, um den Explosionsradius einer Sicherheitsverletzung zu minimieren.
Behandeln Sie Liveness/Readiness Sondenfehler
Wir empfehlen, die Test-Timeout-Werte für Verfügbarkeit und Bereitschaft (StandardtimeoutSeconds: 10) für EKS 1.20 und neuere Cluster zu erhöhen, um zu verhindern, dass Testausfälle dazu führen, dass der Pod Ihrer Anwendung im Zustand ContainerCreating hängen bleibt. Dieses Problem wurde bei datenintensiven Clustern und Clustern mit Batchverarbeitung beobachtet. Eine hohe CPU-Auslastung führt zu Funktionsstörungen bei der AWS-Node-Prüfung, was zu unerfüllten Pod-CPU-Anforderungen führt. Stellen Sie zusätzlich zur Änderung des Test-Timeouts sicher, dass die CPU-Ressourcenanforderungen (StandardCPU: 25m) für aws-node korrekt konfiguriert sind. Wir empfehlen nicht, die Einstellungen zu aktualisieren, es sei denn, Ihr Knoten hat Probleme.
Wir empfehlen Ihnen dringend, sudo bash /opt/cni/bin/aws-cni-support.sh auf einem Knoten auszuführen, während Sie den Amazon EKS-Support in Anspruch nehmen. Das Skript hilft bei der Auswertung von Kubelet-Protokollen und der Speicherauslastung auf dem Knoten. Bitte erwägen Sie, SSM Agent auf Amazon EKS-Worker-Knoten zu installieren, um das Skript auszuführen.
Konfigurieren Sie die IPTables Forward Policy auf AMI-Instances, die nicht für EKS optimiert sind
Wenn Sie ein benutzerdefiniertes AMI verwenden, stellen Sie sicher, dass die iptables-Forward-Richtlinie unter kubelet.service auf ACCEPT gesetzt ist. https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/rootfs/etc/systemd/system/kubelet.service
Aktualisieren Sie die CNI-Version regelmäßig
Das VPC CNI ist abwärtskompatibel. Die neueste Version funktioniert mit allen von Amazon EKS unterstützten Kubernetes-Versionen. Darüber hinaus wird das VPC CNI als EKS-Add-on angeboten (siehe „Deploy VPC CNI Managed“ oben). Add-On EKS-Add-Ons orchestriert zwar Upgrades von Add-Ons, aber Add-Ons wie das CNI werden nicht automatisch aktualisiert, da sie auf der Datenebene ausgeführt werden. Sie sind dafür verantwortlich, das VPC CNI-Add-on nach verwalteten und selbstverwalteten Worker-Node-Upgrades zu aktualisieren.
