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-Kontrollebene vertraut zu machen, bevor Sie mit dem Entwurf Ihrer VPC oder der Bereitstellung von Clustern in bestehenden VPCs Systemen 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:
-
Eine von AWS verwaltete VPC, die die Kubernetes-Steuerebene hostet. Diese VPC erscheint nicht im Kundenkonto.
-
Eine vom Kunden verwaltete VPC, die die Kubernetes-Knoten hostet. Hier laufen Container sowie andere vom Kunden verwaltete AWS-Infrastrukturen wie Load Balancer, die vom Cluster verwendet werden. Diese VPC erscheint im Kundenkonto. Sie müssen eine vom Kunden verwaltete VPC erstellen, bevor Sie einen Cluster erstellen. Das eksctl erstellt eine VPC, wenn Sie keine angeben.
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) ein von EKS verwaltetes Cross-Account-Elastic Network Interfaces (X-ENI) eine Verbindung zur EKS-Steuerebene her. Wenn ein Cluster erstellt wird, müssen Sie mindestens zwei VPC-Subnetze angeben. EKS platziert eine X-ENI in jedem Subnetz, das bei der Clustererstellung angegeben wurde (auch Cluster-Subnetze genannt). Der Kubernetes-API-Server verwendet diese Cros-Accounts, um mit Knoten ENIs 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 über das X- ENIs innerhalb Ihrer VPC mit der Steuerungsebene. 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 Ihres Clusters oder einem verbundenen Netzwerk stammen. Die Knoten kommunizieren ENIs innerhalb Ihrer VPC über X- 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
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 adressiert. Amazon EKS unterstützt IPv4 standardmäßig. Einer VPC muss ein IPv4 CIDR-Block zugeordnet sein. Sie können Ihrer VPC optional mehrere IPv4 Classless Inter-Domain Routing/16 Präfix (65.536 IP-Adressen) und /28 einem Präfix (16 IP-Adressen).
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 von Amazon verwalteten IPv6 Adresspool anfordern. Weitere Informationen finden Sie im Abschnitt VPC CIDR-Blöcke des VPC-Benutzerhandbuchs.
Amazon EKS-Cluster unterstützen IPv4 sowohl als auch IPv6. Standardmäßig verwenden EKS-Cluster IPv4 IP. Wenn Sie dies IPv6 bei der Clustererstellung angeben, können Sie IPv6 Cluster verwenden. IPv6 Cluster benötigen 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 Konten (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 Subnetze ENIs in den Cluster-Subnetzen bereit. Wenn Ihr Cluster horizontal skaliert wird, verbrauchen Worker-Knoten und Pods möglicherweise die IPs im Cluster-Subnetz verfügbaren Ressourcen. Um sicherzustellen, dass genügend verfügbar sind, sollten IPs Sie daher die Verwendung von dedizierten Cluster-Subnetzen 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).
IPv6 Weltweit ist jede Adresse über das Internet routingfähig. Die IPv6 Adressen, die den Knoten und Pods zugeordnet sind, 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. Kennzeichnen Sie das öffentliche Subnetz mit, um Load Balancer kubernetes.io/role/elb
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-elb
Kommunikation zwischen VPCs
Es gibt viele Szenarien, in denen Sie mehrere VPCs und separate EKS-Cluster benötigen, die für diese bereitgestellt werden müssen VPCs.
Sie können Amazon VPC Lattice
Amazon VPC Lattice arbeitet im Link-Local-Adressraum in IPv4 und und bietet Konnektivität zwischen Diensten IPv6, die sich möglicherweise überschneiden. IPv4 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 überlappende IP-Bereiche 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 routingfähige IP-Adressen beizubehalten. RFC1918
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 haben Amazon VPCs gemeinsam genutzt, 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. Dies ermöglicht zentralen Netzwerkteams die Kontrolle über die Netzwerkkonstrukte wie VPCs Subnetze usw., während Anwendungs- oder Plattformteams gleichzeitig Amazon EKS-Cluster in ihren jeweiligen AWS-Konten bereitstellen können. Eine vollständige Anleitung dieses Szenarios ist in diesem Github-Repository verfügbar.
Überlegungen bei der Verwendung gemeinsam genutzter Subnetze
-
Amazon EKS-Cluster und Worker-Knoten können in gemeinsam genutzten Subnetzen erstellt werden, die alle Teil derselben VPC sind. Amazon EKS unterstützt nicht die Erstellung von Clustern über mehrere VPCs.
-
Amazon EKS verwendet AWS VPC Security Groups (SGs), um den Verkehr zwischen der Kubernetes-Steuerebene und den Worker-Knoten des Clusters zu kontrollieren. Sicherheitsgruppen werden auch verwendet, um den Verkehr zwischen Worker-Knoten und anderen VPC-Ressourcen sowie externen IP-Adressen zu kontrollieren. Sie müssen diese Sicherheitsgruppen im Anwendungs- oder Teilnehmerkonto erstellen. Stellen Sie sicher, dass sich die Sicherheitsgruppen, die Sie für Ihre Pods verwenden möchten, auch im Teilnehmerkonto befinden. Sie können die Regeln für eingehenden und ausgehenden Datenverkehr innerhalb Ihrer Sicherheitsgruppen so konfigurieren, dass der erforderliche Datenverkehr zu und von Sicherheitsgruppen im zentralen VPC-Konto zugelassen wird.
-
Erstellen Sie IAM-Rollen und zugehörige Richtlinien innerhalb des Teilnehmerkontos, in dem sich Ihr Amazon EKS-Cluster befindet. Diese IAM-Rollen und -Richtlinien sind unerlässlich, um den von Amazon EKS verwalteten Kubernetes-Clustern sowie den auf Fargate laufenden Knoten und Pods die erforderlichen Berechtigungen zu gewähren. Die Berechtigungen ermöglichen es Amazon EKS, in Ihrem Namen Anrufe an andere AWS-Services zu tätigen.
-
Sie können die folgenden Ansätze verfolgen, um den kontoübergreifenden Zugriff auf AWS-Ressourcen wie Amazon S3 S3-Buckets, Dynamodb-Tabellen usw. von k8s-Pods aus zu ermöglichen:
-
Ressourcenbasierter Richtlinienansatz: Wenn der AWS-Service Ressourcenrichtlinien unterstützt, können Sie entsprechende ressourcenbasierte Richtlinien hinzufügen, um kontoübergreifenden Zugriff auf IAM-Rollen zu ermöglichen, die den Kubernetes-Pods zugewiesen sind. In diesem Szenario sind OIDC-Anbieter, IAM-Rollen und Berechtigungsrichtlinien im Anwendungskonto vorhanden. AWS-Services, die ressourcenbasierte Richtlinien unterstützen, finden Sie unter AWS-Services, die mit IAM funktionieren, und suchen Sie in der Spalte Ressourcenbasiert nach den Services, für die Ja steht.
-
OIDC-Anbieter-Ansatz: IAM-Ressourcen wie OIDC-Anbieter, IAM-Rollen, Genehmigungs- und Vertrauensrichtlinien werden in den AWS-Konten anderer Teilnehmer erstellt, in denen die Ressourcen vorhanden sind. Diese Rollen werden den Kubernetes-Pods im Anwendungskonto zugewiesen, sodass sie auf kontoübergreifende Ressourcen zugreifen können. Eine vollständige Anleitung zu diesem Ansatz finden Sie im Blog Kontenübergreifende IAM-Rollen für Kubernetes-Dienstkonten
.
-
-
Sie können die Amazon Elastic Loadbalancer (ELB) -Ressourcen (ALB oder NLB) bereitstellen, um den Datenverkehr entweder in Anwendungs- oder zentralen Netzwerkkonten an k8s-Pods weiterzuleiten. Ausführliche Anweisungen zur Bereitstellung der ELB-Ressourcen im zentralen Netzwerkkonto finden Sie unter Expose Amazon EKS Pods Through Account Load Balancer
Walkthrough Walkthrough Expose Amazon EKS Pods Through Account Load Balancer. Diese Option bietet mehr Flexibilität, da sie dem Central Networking-Konto die volle Kontrolle über die Sicherheitskonfiguration der Load Balancer-Ressourcen gewährt. -
Wenn Sie Amazon VPC CNI verwenden
custom networking feature, müssen Sie die ID-Zuordnungen der Availability Zone (AZ) verwenden, die im zentralen Netzwerkkonto aufgeführt sind, um jede Zuordnung zu erstellen.ENIConfigDies ist auf die zufällige Zuordnung von physischen AZs und AZ-Namen in jedem AWS-Konto zurückzuführen.
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 einem Nameneks-cluster-sg-my-cluster-uniqueID. EKS ordnet diese Sicherheitsgruppen den verwalteten Knoten 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
Ziehen Sie eine Multi-AZ-Bereitstellung in Betracht
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
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
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
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 Umgebung (EIGW) unterstützt, die IPv6 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 und/oder Gateway-Endpunkte konfigurieren. Sie können interne Load Balancer einrichten, um den Datenverkehr mithilfe des AWS Load Balancer Controllers zu Pods umzuleiten. Die privaten Subnetze müssen mit (kubernetes.io/role/internal-elb: 1
Ziehen Sie den öffentlichen und privaten Modus für den Cluster-Endpunkt in Betracht
Amazon EKS bietet Cluster-Endpunktmodi public-and-private nur öffentlich und 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. node-to-control-plane Kommunikation) 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 (X-ENIs) an. Sie werden jedoch nicht sofort Knoten zugeordnet. Beim Erstellen von Knotengruppen wird dringend empfohlen, benutzerdefinierte Sicherheitsgruppen manuell zuzuordnen
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 in Betracht ziehen, 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 wird mit Redundanz implementiert.
Verwenden Sie Cloud9 für den Zugriff auf private Cluster
AWS Cloud9 ist eine webbasierte IDE, die mithilfe von AWS Systems Manager sicher in privaten Subnetzen ohne Eingangszugriff ausgeführt werden kann. Egress kann auch auf der Cloud9-Instanz deaktiviert werden. Erfahren Sie mehr über die Verwendung von Cloud9 für den Zugriff auf private Cluster und Subnetze.
