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.

Überlegungen zu VPC und Subnetzen

Der Betrieb eines EKS-Clusters erfordert neben Kubernetes-Netzwerken auch Kenntnisse über AWS-VPC-Netzwerke.

Wir empfehlen Ihnen, sich mit den Kommunikationsmechanismen der EKS-Steuerungsebene vertraut zu machen, bevor Sie mit dem Entwurf Ihrer VPC oder der Bereitstellung von Clustern in vorhandenen VPCs beginnen.

Weitere Informationen finden Sie unter Überlegungen zur Cluster-VPC und Überlegungen zu Amazon EKS-Sicherheitsgruppen bei der Architektur einer VPC und von Subnetzen, die mit EKS verwendet werden sollen.

-Übersicht

EKS-Cluster-Architektur

Ein EKS-Cluster besteht aus zwei VPCs:

Die Knoten in der Kunden-VPC müssen in der Lage sein, eine Verbindung zum verwalteten API-Serverendpunkt in der AWS-VPC herzustellen. Auf diese Weise können sich die Knoten bei der Kubernetes-Steuerebene registrieren und Anfragen zur Ausführung von Anwendungs-Pods empfangen.

Die Knoten stellen über (a) einen öffentlichen EKS-Endpunkt oder (b) über Cross-Account elastische Netzwerkschnittstellen (X-ENI), die von EKS verwaltet werden, eine Verbindung zur EKS-Steuerebene her. Wenn ein Cluster erstellt wird, müssen Sie mindestens zwei VPC-Subnetze angeben. EKS platziert a X-ENI in jedem Subnetz, das bei der Clustererstellung angegeben wurde (auch Cluster-Subnetze genannt). Der Kubernetes-API-Server verwendet diese Cross-Account ENIs, um mit Knoten zu kommunizieren, die in den vom Kunden verwalteten Cluster-VPC-Subnetzen bereitgestellt werden.

Beim Start des Knotens wird das EKS-Bootstrap-Skript ausgeführt und die Kubernetes-Knotenkonfigurationsdateien werden installiert. Als Teil des Startvorgangs auf jeder Instanz werden die Container-Runtime-Agents, Kubelet- und Kubernetes-Node-Agents gestartet.

Um einen Knoten zu registrieren, kontaktiert Kubelet den Kubernetes-Cluster-Endpunkt. Es stellt eine Verbindung entweder mit dem öffentlichen Endpunkt außerhalb der VPC oder dem privaten Endpunkt innerhalb der VPC her. Kubelet erhält API-Anweisungen und sendet regelmäßig Statusaktualisierungen und Heartbeats an den Endpunkt.

Kommunikation auf der EKS-Kontrollebene

EKS bietet zwei Möglichkeiten, den Zugriff auf den Cluster-Endpunkt zu kontrollieren. Mit der Endpoint Access Control können Sie wählen, ob der Endpunkt über das öffentliche Internet oder nur über Ihre VPC erreicht werden kann. Sie können den öffentlichen Endpunkt (was die Standardeinstellung ist), den privaten Endpunkt oder beide gleichzeitig aktivieren.

Die Konfiguration des Cluster-API-Endpunkts bestimmt den Pfad, den Knoten nehmen, um mit der Steuerungsebene zu kommunizieren. Beachten Sie, dass diese Endpunkteinstellungen jederzeit über die EKS-Konsole oder API geändert werden können.

Öffentlicher Endpunkt

Dies ist das Standardverhalten für neue Amazon-EKS-Cluster. Wenn nur der öffentliche Endpunkt für den Cluster aktiviert ist, verlassen Kubernetes-API-Anfragen, die aus der VPC Ihres Clusters stammen (z. B. der Worker-Node zur Steuerung der Ebenenkommunikation), die VPC, nicht jedoch das Amazon-Netzwerk. Damit Knoten eine Verbindung zur Steuerungsebene herstellen können, benötigen sie eine öffentliche IP-Adresse und eine Route zu einem Internet-Gateway oder eine Route zu einem NAT-Gateway, wo sie die öffentliche IP-Adresse des NAT-Gateways verwenden können.

Öffentlicher und privater Endpunkt

Wenn sowohl der öffentliche als auch der private Endpunkt aktiviert sind, kommunizieren Kubernetes-API-Anfragen innerhalb der VPC mit der Steuerungsebene über die X-ENIs innerhalb Ihrer VPC. Ihr Cluster-API-Server ist über das Internet erreichbar.

Privater Endpunkt

Es gibt keinen öffentlichen Zugriff auf Ihren API-Server über das Internet, wenn nur der private Endpunkt aktiviert ist. Der gesamte Datenverkehr zu Ihrem Cluster-API-Server muss aus der VPC des Clusters oder einem verbundenen Netzwerk stammen. Die Knoten kommunizieren X-ENIs innerhalb Ihrer VPC mit dem API-Server. Beachten Sie, dass Clusterverwaltungstools Zugriff auf den privaten Endpunkt haben müssen. Erfahren Sie mehr darüber, wie Sie von außerhalb der Amazon VPC eine Verbindung zu einem privaten Amazon EKS-Cluster-Endpunkt herstellen können.

Beachten Sie, dass der API-Serverendpunkt des Clusters von öffentlichen DNS-Servern in eine private IP-Adresse von der VPC aufgelöst wird. In der Vergangenheit konnte der Endpunkt nur innerhalb der VPC aufgelöst werden.

VPC-Konfigurationen

Amazon VPC unterstützt IPv4- und IPv6-Adressen. Amazon EKS unterstützt standardmäßig IPv4. Einer VPC muss ein IPv4-CIDR-Block zugeordnet sein. Sie können Ihrer VPC optional mehrere IPv4 Classless Inter-Domain Routing (CIDR) -Blöcke und mehrere IPv6 CIDR-Blöcke zuordnen. Wenn Sie eine VPC erstellen, müssen Sie einen IPv4-CIDR-Block für die VPC aus den privaten IPv4-Adressbereichen angeben, wie in RFC 1918 angegeben. Die zulässige Blockgröße liegt zwischen einem /16 Präfix (65.536 IP-Adressen) und einem Präfix (16 IP-Adressen). /28

Wenn Sie eine neue VPC erstellen, können Sie einen einzelnen IPv6-CIDR-Block anhängen und bis zu fünf, wenn Sie eine bestehende VPC ändern. Die Präfixlänge der IPv6-CIDR-Blockgröße kann zwischen /44 und /60 und für die IPv6-Subnetze zwischen /44/ und /64 liegen. Sie können einen IPv6-CIDR-Block aus dem Pool von IPv6-Adressen anfordern, der von Amazon verwaltet wird. Weitere Informationen finden Sie im Abschnitt VPC CIDR-Blöcke des VPC-Benutzerhandbuchs.

Amazon EKS-Cluster unterstützen sowohl IPv4 als auch IPv6. Standardmäßig verwenden EKS-Cluster IPv4-IP. Die Angabe von IPv6 bei der Clustererstellung ermöglicht die Verwendung von IPv6-Clustern. IPv6-Cluster erfordern Dual-Stack-VPCs und Subnetze.

Amazon EKS empfiehlt, bei der Clustererstellung mindestens zwei Subnetze zu verwenden, die sich in unterschiedlichen Availability Zones befinden. Die Subnetze, die Sie bei der Clustererstellung übergeben, werden als Cluster-Subnetze bezeichnet. Wenn Sie einen Cluster erstellen, erstellt Amazon EKS bis zu 4 kontoübergreifende (X-Konto oder X-ENIs) ENIs in den von Ihnen angegebenen Subnetzen. Die X-ENIs werden immer bereitgestellt und für den Cluster-Administrationsdatenverkehr wie Protokollzustellung, Exec und Proxy verwendet. Vollständige Informationen zu den VPC- und Subnetzanforderungen finden Sie im EKS-Benutzerhandbuch.

Kubernetes-Worker-Knoten können in den Cluster-Subnetzen ausgeführt werden, dies wird jedoch nicht empfohlen. Während Cluster-Upgrades stellt Amazon EKS zusätzliche ENIs in den Cluster-Subnetzen bereit. Wenn Ihr Cluster horizontal skaliert wird, verbrauchen Worker-Knoten und Pods möglicherweise die verfügbaren IPs im Cluster-Subnetz. Um sicherzustellen, dass genügend IPs verfügbar sind, sollten Sie daher die Verwendung dedizierter Cluster-Subnetze mit der Netzmaske /28 in Betracht ziehen.

Kubernetes-Worker-Knoten können entweder in einem öffentlichen oder einem privaten Subnetz ausgeführt werden. Ob ein Subnetz öffentlich oder privat ist, bezieht sich darauf, ob der Verkehr innerhalb des Subnetzes über ein Internet-Gateway geleitet wird. Öffentliche Subnetze haben einen Routing-Tabelleneintrag zum Internet über das Internet-Gateway, private Subnetze jedoch nicht.

Der Verkehr, der woanders entsteht und Ihre Knoten erreicht, wird als Ingress bezeichnet. Der Verkehr, der von den Knoten ausgeht und das Netzwerk verlässt, wird als Egress bezeichnet. Knoten mit öffentlichen oder elastischen IP-Adressen (EIPs) innerhalb eines Subnetzes, das mit einem Internet-Gateway konfiguriert ist, ermöglichen den Zugriff von außerhalb der VPC. Private Subnetze verfügen in der Regel über ein Routing zu einem NAT-Gateway, das eingehenden Datenverkehr zu den Knoten in den Subnetzen von außerhalb der VPC nicht zulässt, während der Datenverkehr von den Knoten die VPC verlassen kann (Egress).

In der IPv6-Welt ist jede Adresse über das Internet routbar. Die den Knoten und Pods zugewiesenen IPv6-Adressen sind öffentlich. Private Subnetze werden durch die Implementierung von nur ausgehenden Internet-Gateways (EIGW) in einer VPC unterstützt, die ausgehenden Datenverkehr zulassen und gleichzeitig den gesamten eingehenden Verkehr blockieren. Bewährte Methoden für die Implementierung von IPv6-Subnetzen finden Sie im VPC-Benutzerhandbuch.

Sie können VPC und Subnetze auf drei verschiedene Arten konfigurieren:

Nur öffentliche Subnetze verwenden

In denselben öffentlichen Subnetzen werden sowohl Knoten als auch Eingangsressourcen (wie Load Balancer) erstellt. Markieren Sie das öffentliche Subnetz mit, um Load Balancer kubernetes.io/role/elbzu erstellen, die mit dem Internet verbunden sind. In dieser Konfiguration kann der Cluster-Endpunkt als öffentlich, privat oder beides (öffentlich und privat) konfiguriert werden.

Verwendung von privaten und öffentlichen Subnetzen

Knoten werden in privaten Subnetzen erstellt, wohingegen Ingress-Ressourcen in öffentlichen Subnetzen instanziiert werden. Sie können öffentlichen, privaten oder beides (öffentlich und privat) Zugriff auf den Cluster-Endpunkt aktivieren. Abhängig von der Konfiguration des Cluster-Endpunkts wird der Knotenverkehr über das NAT-Gateway oder die ENI eingegeben.

Es werden nur private Subnetze verwendet

Sowohl Knoten als auch Ingress werden in privaten Subnetzen erstellt. Verwendung des kubernetes.io/role/internal-elbSubnetz-Tags zum Aufbau interner Load Balancer. Für den Zugriff auf den Endpunkt Ihres Clusters ist eine VPN-Verbindung erforderlich. Sie müssen AWS PrivateLink für EC2 und alle Amazon ECR- und S3-Repositorys aktivieren. Nur der private Endpunkt des Clusters sollte aktiviert werden. Wir empfehlen, die Anforderungen für private EKS-Cluster durchzugehen, bevor Sie private Cluster bereitstellen.

Kommunikation zwischen VPCs

Es gibt viele Szenarien, in denen Sie mehrere VPCs und separate EKS-Cluster benötigen, die auf diesen VPCs bereitgestellt werden.

Sie können Amazon VPC Lattice verwenden, um Services über mehrere VPCs und Konten hinweg konsistent und sicher zu verbinden (ohne dass zusätzliche Konnektivität durch Services wie VPC Peering, AWS PrivateLink oder AWS Transit Gateway bereitgestellt werden muss). Erfahren Sie hier mehr.

Amazon VPC Lattice arbeitet im Link-Local-Adressraum in IPv4 und IPv6 und bietet Konnektivität zwischen Diensten, die möglicherweise überlappende IPv4-Adressen haben. Aus Gründen der betrieblichen Effizienz empfehlen wir dringend, EKS-Cluster und -Knoten in IP-Bereichen bereitzustellen, die sich nicht überschneiden. Falls Ihre Infrastruktur VPCs mit überlappenden IP-Bereichen umfasst, müssen Sie Ihr Netzwerk entsprechend gestalten. Wir empfehlen Private NAT Gateway oder VPC CNI im benutzerdefinierten Netzwerkmodus in Verbindung mit einem Transit-Gateway, um Workloads auf EKS zu integrieren, um überlappende CIDR-Herausforderungen zu lösen und gleichzeitig routbare RFC1918-IP-Adressen beizubehalten.

Erwägen Sie die Nutzung von AWS PrivateLink, auch bekannt als Endpunkt-Service, wenn Sie der Service Provider sind und Ihren Kubernetes-Service und Ingress (entweder ALB oder NLB) in separaten Konten mit Ihrer Kunden-VPC teilen möchten.

Gemeinsame Nutzung von VPC für mehrere Konten

Viele Unternehmen nutzten gemeinsam genutzte Amazon VPCs, um die Netzwerkadministration zu optimieren, Kosten zu senken und die Sicherheit mehrerer AWS-Konten in einer AWS-Organisation zu verbessern. Sie nutzen AWS Resource Access Manager (RAM), um unterstützte AWS-Ressourcen sicher mit einzelnen AWS-Konten, Organisationseinheiten (OUs) oder der gesamten AWS-Organisation zu teilen.

Sie können Amazon EKS-Cluster, verwaltete Knotengruppen und andere unterstützende AWS-Ressourcen (wie LoadBalancers Sicherheitsgruppen, Endpunkte usw.) in gemeinsam genutzten VPC-Subnetzen von einem anderen AWS-Konto aus mithilfe von AWS-RAM bereitstellen. Die folgende Abbildung zeigt ein Beispiel für eine High-Level-Architektur. Dadurch haben zentrale Netzwerkteams die Kontrolle über die Netzwerkkonstrukte wie VPCs, Subnetze usw. und gleichzeitig können Anwendungs- oder Plattformteams Amazon EKS-Cluster in ihren jeweiligen AWS-Konten bereitstellen. Eine vollständige Anleitung dieses Szenarios ist in diesem Github-Repository verfügbar.

Überlegungen bei der Verwendung gemeinsam genutzter Subnetze

Sicherheitsgruppen

Eine Sicherheitsgruppe steuert den Datenverkehr, der die Ressourcen erreichen und verlassen darf, mit denen er verknüpft ist. Amazon EKS verwendet Sicherheitsgruppen, um die Kommunikation zwischen der Kontrollebene und den Knoten zu verwalten. Wenn Sie einen Cluster erstellen, erstellt Amazon EKS eine Sicherheitsgruppe mit dem Namen eks-cluster-sg-my-cluster-uniqueID. EKS ordnet diese Sicherheitsgruppen den verwalteten ENIs und den Knoten zu. Die Standardregeln ermöglichen es, dass der gesamte Datenverkehr frei zwischen Ihrem Cluster und Ihren Knoten fließt. Außerdem lassen sie den gesamten ausgehenden Datenverkehr zu jedem Ziel zu.

Wenn Sie einen Cluster erstellen, können Sie Ihre eigenen Sicherheitsgruppen angeben. Bitte beachten Sie die Empfehlung für Sicherheitsgruppen, wenn Sie eigene Sicherheitsgruppen angeben.

Empfehlungen

Erwägen Sie die Multi-AZ Bereitstellung

AWS-Regionen bieten mehrere physisch getrennte und isolierte Availability Zones (AZ), die über Netzwerke mit niedriger Latenz, hohem Durchsatz und hoher Redundanz miteinander verbunden sind. Mit Availability Zones können Sie Anwendungen entwerfen und betreiben, die automatisch und ohne Unterbrechung ein Failover zwischen Availability Zones durchführen. Amazon EKS empfiehlt dringend, EKS-Cluster in mehreren Availability Zones bereitzustellen. Bitte erwägen Sie, bei der Erstellung des Clusters Subnetze in mindestens zwei Availability Zones anzugeben.

Kubelet, das auf Knoten ausgeführt wird, fügt dem Knotenobjekt automatisch Labels hinzu, wie z. topology.kubernetes.io/region=us-west-2 Wir empfehlen, Node-Labels in Verbindung mit den Beschränkungen der Pod-Topologie zu verwenden, um zu kontrollieren, wie Pods über Zonen verteilt werden. Diese Hinweise ermöglichen es dem Kubernetes-Scheduler, Pods so zu platzieren, dass die erwartete Verfügbarkeit besser ist. Dadurch wird das Risiko verringert, dass sich ein korrelierter Ausfall auf Ihren gesamten Workload auswirkt. Beispiele für Node-Selector- und AZ-Spread-Beschränkungen finden Sie unter Zuweisen von Knoten zu Pods.

Sie können die Subnetze oder Verfügbarkeitszonen definieren, wenn Sie Knoten erstellen. Die Knoten werden in Cluster-Subnetzen platziert, wenn keine Subnetze konfiguriert sind. Die EKS-Unterstützung für verwaltete Knotengruppen verteilt die Knoten je nach verfügbarer Kapazität automatisch auf mehrere Availability Zones. Karpenter berücksichtigt die AZ-Spread-Platzierung, indem die Knoten auf bestimmte AZs skaliert werden, wenn die Arbeitslasten die Topologie-Spread-Grenzen definieren.

AWS Elastic Load Balancers werden vom AWS Load Balancer Controller für einen Kubernetes-Cluster verwaltet. Es stellt einen Application Load Balancer (ALB) für Kubernetes-Eingangsressourcen und einen Network Load Balancer (NLB) für Kubernetes-Dienste vom Typ Loadbalancer bereit. Der Elastic Load Balancer Balancer-Controller verwendet Tags, um die Subnetze zu erkennen. Der ELB-Controller benötigt mindestens zwei Availability Zones (AZs), um Eingangsressourcen erfolgreich bereitzustellen. Erwägen Sie die Einrichtung von Subnetzen in mindestens zwei AZs, um die Sicherheit und Zuverlässigkeit geografischer Redundanz zu nutzen.

Stellen Sie Knoten in privaten Subnetzen bereit

Eine VPC, die sowohl private als auch öffentliche Subnetze umfasst, ist die ideale Methode für die Bereitstellung von Kubernetes-Workloads auf EKS. Erwägen Sie, mindestens zwei öffentliche Subnetze und zwei private Subnetze in zwei unterschiedlichen Verfügbarkeitszonen einzurichten. Die zugehörige Routentabelle eines öffentlichen Subnetzes enthält eine Route zu einem Internet-Gateway. Pods können über ein NAT-Gateway mit dem Internet interagieren. Private Subnetze werden von Internet-Gateways in der IPv6-Umgebung (EIGW) unterstützt, die nur für ausgehenden Datenverkehr bestimmt sind.

Die Instanziierung von Knoten in privaten Subnetzen bietet maximale Kontrolle über den Datenverkehr zu den Knoten und ist für die überwiegende Mehrheit der Kubernetes-Anwendungen wirksam. Eingangsressourcen (wie Load Balancer) werden in öffentlichen Subnetzen instanziiert und leiten den Datenverkehr an Pods weiter, die in privaten Subnetzen betrieben werden.

Ziehen Sie den Modus „Nur privat“ in Betracht, wenn Sie strenge Sicherheitsvorkehrungen und Netzwerkisolierung benötigen. In dieser Konfiguration werden drei private Subnetze in unterschiedlichen Availability Zones innerhalb der VPC der AWS-Region bereitgestellt. Die in den Subnetzen bereitgestellten Ressourcen können nicht auf das Internet zugreifen, und das Internet kann auch nicht auf die Ressourcen in den Subnetzen zugreifen. Damit Ihre Kubernetes-Anwendung auf andere AWS-Services zugreifen kann, müssen Sie PrivateLink Schnittstellen, and/or Gateway-Endpunkte konfigurieren. Sie können interne Load Balancer einrichten, um den Datenverkehr mithilfe des AWS Load Balancer Controller zu Pods umzuleiten. Die privaten Subnetze müssen mit (kubernetes.io/role/internal-elb: 1) gekennzeichnet sein, damit der Controller Load Balancer bereitstellen kann. Damit sich Knoten beim Cluster registrieren können, muss der Cluster-Endpunkt auf den privaten Modus gesetzt werden. Vollständige Anforderungen und Überlegungen finden Sie im Leitfaden für private Cluster.

Ziehen Sie den öffentlichen und privaten Modus für den Cluster-Endpunkt in Betracht

Amazon EKS bietet Cluster-Endpunktmodi nur öffentlich, öffentlich und privat sowie nur privat. Der Standardmodus ist nur öffentlich. Wir empfehlen jedoch, den Cluster-Endpunkt im öffentlichen und privaten Modus zu konfigurieren. Mit dieser Option können Kubernetes-API-Aufrufe innerhalb der VPC Ihres Clusters (z. B. Kommunikation zwischen Knoten und Steuerungsebene) den privaten VPC-Endpunkt nutzen und der Datenverkehr bleibt innerhalb der VPC Ihres Clusters. Ihr Cluster-API-Server kann dagegen über das Internet erreicht werden. Wir empfehlen jedoch dringend, die CIDR-Blöcke einzuschränken, die den öffentlichen Endpunkt verwenden können. Erfahren Sie, wie Sie den Zugriff auf öffentliche und private Endgeräte konfigurieren, einschließlich der Begrenzung von CIDR-Blöcken.

Wir empfehlen einen ausschließlich privaten Endpunkt, wenn Sie Sicherheit und Netzwerkisolierung benötigen. Wir empfehlen, eine der im EKS-Benutzerhandbuch aufgeführten Optionen zu verwenden, um eine private Verbindung zu einem API-Server herzustellen.

Konfigurieren Sie Sicherheitsgruppen sorgfältig

Amazon EKS unterstützt die Verwendung benutzerdefinierter Sicherheitsgruppen. Alle benutzerdefinierten Sicherheitsgruppen müssen die Kommunikation zwischen Knoten und der Kubernetes-Steuerebene ermöglichen. Bitte überprüfen Sie die Portanforderungen und konfigurieren Sie die Regeln manuell, wenn Ihre Organisation keine offene Kommunikation zulässt.

EKS wendet die benutzerdefinierten Sicherheitsgruppen, die Sie bei der Clustererstellung angeben, auf die verwalteten Schnittstellen an (X-ENIs). Es ordnet sie jedoch nicht sofort Knoten zu. Beim Erstellen von Knotengruppen wird dringend empfohlen, benutzerdefinierte Sicherheitsgruppen manuell zuzuordnen. Bitte erwägen Sie, die GroupSelectorTermsSicherheitseinstellungen zu aktivieren, um die Erkennung benutzerdefinierter Sicherheitsgruppen durch Karpenter bei der automatischen Skalierung von Knoten zu ermöglichen.

Wir empfehlen dringend, eine Sicherheitsgruppe zu erstellen, um den gesamten Kommunikationsverkehr zwischen den Knoten zuzulassen. Während des Bootstrap-Vorgangs benötigen Knoten eine ausgehende Internetverbindung, um auf den Cluster-Endpunkt zugreifen zu können. Bewerten Sie die Anforderungen für den ausgehenden Zugriff, z. B. die Verbindung vor Ort und den Zugriff auf die Container-Registry, und legen Sie die Regeln entsprechend fest. Bevor Sie Änderungen in der Produktionsumgebung vornehmen, empfehlen wir Ihnen dringend, die Verbindungen in Ihrer Entwicklungsumgebung sorgfältig zu überprüfen.

Stellen Sie NAT-Gateways in jeder Availability Zone bereit

Wenn Sie Knoten in privaten Subnetzen (IPv4 und IPv6) bereitstellen, sollten Sie erwägen, in jeder Availability Zone (AZ) ein NAT-Gateway einzurichten, um eine zonenunabhängige Architektur zu gewährleisten und die AZ-übergreifenden Ausgaben zu reduzieren. Jedes NAT-Gateway in einer AZ ist redundant implementiert.