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 Subnetz
Tipp
Informieren Sie sich in Amazon EKS-Workshops über
Für den Betrieb eines EKS-Clusters sind zusätzlich zum Kubernetes-Netzwerk Kenntnisse im AWS-VPC-Netzwerk erforderlich.
Wir empfehlen Ihnen, die Kommunikationsmechanismen der EKS-Steuerungsebene zu verstehen, bevor Sie mit dem Entwurf Ihrer VPC oder der Bereitstellung von Clustern in vorhandenen VPCs beginnen.
Lesen Sie bei der Architektur einer VPC und Subnetze, die mit EKS verwendet werden sollen, die Hinweise zu Cluster-VPC und Überlegungen zur Amazon EKS-Sicherheitsgruppe.
-Übersicht
EKS-Cluster-Architektur
Ein EKS-Cluster besteht aus zwei VPCs:
-
Eine AWS-managed VPC, die die Kubernetes-Steuerungsebene hostet. Diese VPC erscheint nicht im Kundenkonto.
-
Eine vom Kunden verwaltete VPC, die die Kubernetes-Knoten hostet. Hier werden Container sowie andere vom Kunden verwaltete AWS-Infrastrukturen wie die vom Cluster verwendeten Load Balancer ausgeführt. Diese VPC erscheint im Kundenkonto. Sie müssen eine vom Kunden verwaltete VPC erstellen, bevor Sie einen Cluster erstellen. Das eksctl erstellt eine VPC, falls 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. Dadurch können sich die Knoten bei der Kubernetes-Steuerungsebene registrieren und Anfragen zur Ausführung von Anwendungs-Pods empfangen.
Die Knoten stellen über (a) einen öffentlichen EKS-Endpunkt oder (b) eine Cross-Account elastische Netzwerkschnittstelle (X-ENI), die von EKS verwaltet wird, eine Verbindung zur EKS-Steuerungsebene her. Wenn ein Cluster erstellt wird, müssen Sie mindestens zwei VPC-Subnetze angeben. EKS platziert ein Subnetz 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 Starten des Knotens wird das EKS-Bootstrap-Skript ausgeführt und die Kubernetes-Knotenkonfigurationsdateien werden installiert. Im Rahmen des Startvorgangs auf jeder Instance werden die Container Runtime Agents, Kubelet und Kubernetes Node Agents gestartet.
Um einen Knoten zu registrieren, kontaktiert Kubelet den Kubernetes-Cluster-Endpunkt. Es stellt entweder eine Verbindung mit dem öffentlichen Endpunkt außerhalb der VPC oder dem privaten Endpunkt innerhalb der VPC her. Kubelet empfängt API-Anweisungen und sendet regelmäßig Statusaktualisierungen und Heartbeats an den Endpunkt.
EKS-Kommunikation auf Steuerungsebene
EKS hat zwei Möglichkeiten, den Zugriff auf den Cluster-Endpunkt zu kontrollieren. Bei 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 (der Standard ist), den privaten Endpunkt oder beide gleichzeitig einschalten.
Die Konfiguration des Cluster-API-Endpunkts bestimmt den Pfad, den die Knoten zur Kommunikation mit der Steuerungsebene nehmen. Beachten Sie, dass diese Endpunkteinstellungen jederzeit über die EKS-Konsole oder die 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. die Kommunikation zwischen Worker Node und Control Plane), die VPC, aber nicht 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 aus der VPC über Ihre VPC mit der Steuerungsebene. X-ENIs 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 über X-ENIs Ihre VPC mit dem API-Server. Beachten Sie, dass Cluster-Management-Tools 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.
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 /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 vorhandene VPC ändern. Die Präfixlänge der IPv6-CIDR-Blockgröße kann zwischen /44 und /60 liegen, und für die IPv6-Subnetze kann sie zwischen /44/ und /64 liegen. Sie können einen IPv6-CIDR-Block aus dem Pool der von Amazon verwalteten IPv6-Adressen anfordern. Weitere Informationen finden Sie im Abschnitt VPC-CIDR-Blöcke im VPC-Benutzerhandbuch.
Amazon EKS-Cluster unterstützen sowohl IPv4 als auch IPv6. Standardmäßig verwenden EKS-Cluster IPv4-IP. Wenn Sie IPv6 bei der Clustererstellung angeben, können Sie IPv6-Cluster verwenden. IPv6-Cluster benötigen Dual-Stack-VPCs und -Subnetze.
Amazon EKS erfordert, dass Sie mindestens zwei Subnetze in zwei verschiedenen Availability Zones angeben, wenn Sie einen Cluster erstellen. Die von Ihnen angegebenen Subnetze werden als Cluster-Subnetze bezeichnet. Amazon EKS stellt zwei kontoübergreifende ENIs (X-ENIs) in verschiedenen Availability Zones bereit, um die Kommunikation mit Ihren Worker-Knoten zu ermöglichen. Wenn Sie einen Cluster erstellen, erstellt Amazon EKS 2—4 X-ENIs in Ihren angegebenen Subnetzen. Amazon EKS stellt die X-ENIs immer bereit und verwendet sie für den Cluster-Verwaltungsdatenverkehr wie Protokollzustellung, Exec und Proxy. Weitere Informationen zu VPC- und Subnetzanforderungen finden Sie unter VPC- und Subnetzanforderungen im Amazon EKS-Benutzerhandbuch.
Kubernetes-Worker-Knoten können in den Cluster-Subnetzen ausgeführt werden, dies wird jedoch nicht empfohlen. Bei Cluster-Upgrades stellt Amazon EKS zusätzliche ENIs in den Cluster-Subnetzen bereit. Wenn Ihr Cluster skaliert wird, verbrauchen Worker-Knoten und Pods möglicherweise die verfügbaren IPs im Cluster-Subnetz. Um sicherzustellen, dass genügend IP-Adressen verfügbar sind, sollten Sie daher erwägen, dedizierte Cluster-Subnetze mit /28-Netzmaske zu verwenden.
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. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html Öffentliche Subnetze haben einen Routing-Tabelleneintrag zum Internet über das Internet-Gateway, private Subnetze jedoch nicht.
Der Datenverkehr, der woanders entsteht und Ihre Knoten erreicht, wird als Ingress bezeichnet. 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 keinen eingehenden Verkehr von außerhalb der VPC zu den Knoten in den Subnetzen zulässt, während der Datenverkehr von den Knoten die VPC verlassen kann (Ausgang).
In der IPv6-Welt ist jede Adresse über das Internet routbar. Die IPv6-Adressen, die den Knoten und Pods zugeordnet sind, sind öffentlich. Private Subnetze werden durch die Implementierung von Internet-Gateways (EIGW) nur für ausgehenden Verkehr 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. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
Sie können VPC und Subnetze auf drei verschiedene Arten konfigurieren:
Verwenden Sie nur öffentliche Subnetze
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/elb zu konstruieren, die dem Internet zugewandt sind. In dieser Konfiguration kann der Cluster-Endpunkt so konfiguriert werden, dass er öffentlich, privat oder beides (öffentlich und privat) ist.
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. Je nach Konfiguration des Cluster-Endpunkts erfolgt der Knotenverkehr über das NAT-Gateway oder das ENI.
Es werden nur private Subnetze verwendet
Sowohl Knoten als auch Ingress werden in privaten Subnetzen erstellt. Verwendung des kubernetes.io/role/internal-elb Subnetz-Tags zur Erstellung 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 zu prüfen, bevor private Cluster bereitgestellt werden.
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,
Amazon VPC Lattice arbeitet in IPv4 und IPv6 im link-lokalen Adressraum und bietet Konnektivität zwischen Diensten, die sich 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 ausrichten. Wir empfehlen Private NAT Gateway oder VPC CNI im benutzerdefinierten Netzwerkmodus in Verbindung mit dem Transit Gateway, um Workloads auf EKS zu integrieren, um überlappende CIDR-Probleme zu lösen und gleichzeitig routingfähige RFC1918-IP-Adressen beizubehalten.
Erwägen Sie die Nutzung von AWS PrivateLink, auch bekannt als Endpoint Service, wenn Sie der Dienstanbieter sind und Ihren Kubernetes-Service und Ingress (entweder ALB oder NLB) mit Ihrer Kunden-VPC in separaten Konten teilen möchten.
Gemeinsame Nutzung der VPC für mehrere Konten
Viele Unternehmen nutzten gemeinsam genutzte Amazon VPCs, um die Netzwerkverwaltung zu optimieren, die Kosten zu senken und die Sicherheit mehrerer AWS-Konten in einer AWS-Organisation zu verbessern. Sie nutzen den AWS Resource Access Manager (RAM), um unterstützte AWS-Ressourcen sicher mit einzelnen AWS-Konten, Organisationseinheiten (OUs) oder der gesamten AWS-Organisation gemeinsam zu nutzen.
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 zu diesem Szenario ist in diesem Github-Repository verfügbar. https://github.com/aws-samples/eks-shared-subnets
Ü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 hinweg.
-
Amazon EKS verwendet AWS VPC Security Groups (SGs), um den Verkehr zwischen der Kubernetes-Steuerungsebene und den Worker-Knoten des Clusters zu steuern. Sicherheitsgruppen werden auch verwendet, um den Verkehr zwischen Worker-Knoten und anderen VPC-Ressourcen sowie externen IP-Adressen zu steuern. Sie müssen diese Sicherheitsgruppen im application/participant Konto 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 die zugehörigen 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 Knoten und Pods, die auf Fargate laufen, 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 den folgenden Ansätzen folgen, um den kontoübergreifenden Zugriff auf AWS-Ressourcen wie Amazon S3-Buckets, Dynamodb-Tabellen usw. von k8s-Pods aus zu ermöglichen:
-
Ressourcenbasierter Richtlinienansatz: Wenn der AWS-Service Ressourcenrichtlinien unterstützt, können Sie eine entsprechende ressourcenbasierte Richtlinie hinzufügen, um den kontoübergreifenden Zugriff auf die den Kubernetes-Pods zugewiesenen IAM-Rollen zu ermöglichen. In diesem Szenario sind der OIDC-Anbieter, die IAM-Rollen und die Berechtigungsrichtlinien im Anwendungskonto vorhanden. Informationen zu AWS-Services, die ressourcenbasierte Richtlinien unterstützen, finden Sie unter AWS-Services, die mit IAM funktionieren, und suchen Sie nach den Diensten, für die in der Spalte Ressourcenbasiert Ja steht.
-
OIDC-Anbieter-Ansatz: IAM-Ressourcen wie OIDC-Anbieter, IAM-Rollen, Genehmigungs- und Vertrauensrichtlinien werden in einem anderen AWS-Teilnehmerkonto erstellt, in dem 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
Kontoü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 zu k8s-Pods weiterzuleiten. Eine detaillierte Anleitung zur Bereitstellung der ELB-Ressourcen im zentralen Netzwerkkonto finden Sie unter Expose Amazon EKS Pods
Through Load Cross-Account 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 zu erstellen.ENIConfigDies ist auf die zufällige Zuordnung physischer AZs zu den 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 Steuerungsebene 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 hochredundanten Netzwerken miteinander verbunden sind. Mit Availability Zones können Sie Anwendungen entwerfen und betreiben, die automatisch und ohne Unterbrechung einen Failover zwischen Availability Zones durchführen. Amazon EKS empfiehlt dringend, EKS-Cluster in mehreren Availability Zones bereitzustellen. Bitte erwägen Sie, Subnetze in mindestens zwei Availability Zones anzugeben, wenn Sie den Cluster erstellen.
Kubelet, das auf Knoten ausgeführt wird, fügt dem Knotenobjekt automatisch Beschriftungen hinzu, 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 automatisch je nach verfügbarer Kapazität auf mehrere Verfügbarkeitszonen. Karpenter berücksichtigt
AWS Elastic Load Balancer 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 des Typs Loadbalancer bereit. Der Elastic Load Balancer-Controller verwendet Tags, um die Subnetze zu ermitteln. https://aws.amazon.com/premiumsupport/knowledge-center/eks-vpc-subnet-discovery/
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 verschiedenen Verfügbarkeitszonen einzurichten. Die zugehörige Routing-Tabelle 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 in der IPv6-Umgebung (EIGW) von Internet-Gateways unterstützt, die nur für ausgehenden Verkehr 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 effektiv. Eingangsressourcen (z. B. 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 Sicherheits- und Netzwerkisolierung verlangen. 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 Schnittstellen-Gateway-Endpunkte konfigurieren PrivateLink . and/or Sie können interne Load Balancer einrichten, um den Datenverkehr mithilfe des AWS Load Balancer Controller an Pods umzuleiten. Die privaten Subnetze müssen mit einem Tag (kubernetes.io/role/internal-elb: 1) versehen 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 sein. Die vollständigen Anforderungen und Überlegungen finden Sie im Leitfaden für private Cluster.
Erwägen Sie den öffentlichen und privaten Modus für Cluster-Endpunkte
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 von Knoten zu Steuerungsebene) den privaten VPC-Endpunkt nutzen und der Datenverkehr bleibt in 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 öffentlichen und privaten Endpunktzugriff 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-Steuerungsebene 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
Wir empfehlen dringend, eine Sicherheitsgruppe zu erstellen, um den gesamten Kommunikationsverkehr zwischen 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 externen Zugriff, z. B. die Verbindung vor Ort und den Zugriff auf die Container-Registrierung, und legen Sie die entsprechenden Regeln fest. Bevor Sie Änderungen in die Produktionsumgebung übernehmen, 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 zu erstellen, um eine zonenunabhängige Architektur sicherzustellen und die AZ-übergreifenden Ausgaben zu reduzieren. Jedes NAT-Gateway in einer AZ ist mit Redundanz implementiert.
