Hilf mit, diese Seite zu verbessern
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.
Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.
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.
Bereiten Sie das Netzwerk für Hybridknoten vor
Dieses Thema bietet einen Überblick über die Netzwerkkonfiguration, die Sie konfiguriert haben müssen, bevor Sie Ihren Amazon EKS-Cluster erstellen und Hybridknoten anhängen. In diesem Leitfaden wird davon ausgegangen, dass Sie die Voraussetzungen für Hybrid-Netzwerkkonnektivität mit AWS Site-to-Site VPN, AWS Direct Connect oder Ihrer eigenen VPN-Lösung erfüllt haben.

Netzwerkkonfiguration vor Ort
Mindestanforderungen an das Netzwerk
Für ein optimales Nutzererlebnis wird eine zuverlässige Netzwerkkonnektivität von mindestens 100 Mbit/s und eine maximale Roundtrip-Latenz von 200 ms für die Verbindung der Hybridknoten mit der AWS Region AWS empfohlen. Die Anforderungen an Bandbreite und Latenz können je nach Anzahl der Hybridknoten und Ihren Workload-Merkmalen wie Größe des Anwendungsimages, Anwendungselastizität, Überwachungs- und Protokollierungskonfigurationen und Anwendungsabhängigkeiten beim Zugriff auf Daten, die in anderen AWS Diensten gespeichert sind, variieren.
Lokaler Knoten und Pod CIDRs
Identifizieren Sie den Knoten und den Pod, den CIDRs Sie für Ihre Hybridknoten und die darauf ausgeführten Workloads verwenden werden. Der Node-CIDR wird von Ihrem lokalen Netzwerk zugewiesen und der Pod-CIDR wird von Ihrem Container Network Interface (CNI) zugewiesen, wenn Sie ein Overlay-Netzwerk für Ihr CNI verwenden. Sie übergeben Ihren lokalen Knoten CIDRs und optional den Pod CIDRs als Eingaben, wenn Sie Ihren Amazon EKS-Cluster mit den RemotePodNetwork
Feldern RemoteNodeNetwork
und erstellen.
Die CIDR-Blöcke für den lokalen Knoten und den Pod müssen die folgenden Anforderungen erfüllen:
-
Innerhalb eines der folgenden
IPv4
RFC-1918-Bereiche liegen:10.0.0.0/8
,, oder.172.16.0.0/12
192.168.0.0/16
-
Überschneiden Sie sich nicht miteinander, mit dem VPC-CIDR für Ihren Amazon EKS-Cluster oder Ihrem Kubernetes-Service CIDR.
IPv4
Wenn Ihr CNI Network Address Translation (NAT) für Pod-Traffic durchführt, wenn er Ihre lokalen Hosts verlässt, müssen Sie Ihren Pod-CIDR nicht in Ihrem lokalen Netzwerk bekannt geben oder Ihren Amazon EKS-Cluster mit Ihrem Remote-Pod-Netzwerk konfigurieren, damit Hybridknoten für Workloads bereit sind. Wenn Ihr CNI NAT nicht für den Pod-Verkehr verwendet, wenn er Ihre lokalen Hosts verlässt, müssen Sie Ihren Pod-CIDR in Ihrem lokalen Netzwerk bekannt geben und Sie müssen Ihren Amazon EKS-Cluster mit Ihrem Remote-Pod-Netzwerk konfigurieren, damit Hybridknoten für Workloads bereit sind. Wenn Sie Webhooks auf Ihren Hybridknoten ausführen, müssen Sie Ihren Pod-CIDR in Ihrem lokalen Netzwerk bekannt geben und Ihren Amazon EKS-Cluster mit Ihrem Remote-Pod-Netzwerk konfigurieren, sodass die Amazon EKS-Steuerebene eine direkte Verbindung zu den Webhooks herstellen kann, die auf Hybridknoten ausgeführt werden.
Während der Installation und des Upgrades des Hybridknotens ist Zugriff erforderlich
Während des Installationsvorgangs, bei dem Sie die Abhängigkeiten der Hybridknoten auf Ihren Hosts installieren, müssen Sie Zugriff auf die folgenden Domänen haben. Dieser Vorgang kann einmal ausgeführt werden, wenn Sie Ihre Betriebssystem-Images erstellen, oder er kann auf jedem Host zur Laufzeit ausgeführt werden. Dazu gehören die Erstinstallation und das Upgrade der Kubernetes-Version Ihrer Hybridknoten.
Komponente | URL | Protokoll | Port |
---|---|---|---|
EKS-Knotenartefakte (S3) |
https://hybrid-assets.eks.amazonaws.com |
HTTPS |
443 |
https://eks. |
HTTPS |
443 |
|
EKS ECR-Endpunkte |
Informationen zu regionalen Amazon-Container-Image-Registrierungen für Amazon EKS-Add-Ons anzeigen Endpunkten finden Sie unter. |
HTTPS |
443 |
Binärer SSM-Endpunkt 1 |
https://amazon-ssm - |
HTTPS |
443 |
https://ssm. |
HTTPS |
443 |
|
Binärer IAM Anywhere-Endpunkt 2 |
https://rolesanywhere.amazonaws.com |
HTTPS |
443 |
https://rolesanywhere. |
HTTPS |
443 |
Anmerkung
1 Der Zugriff auf die AWS SSM-Endpunkte ist nur erforderlich, wenn Sie SSM-Hybrid-Aktivierungen für Ihren lokalen AWS IAM-Anmeldeinformationsanbieter verwenden.
2 Der Zugriff auf die AWS IAM-Endpunkte ist nur erforderlich, wenn Sie IAM Roles Anywhere für Ihren lokalen AWS IAM-Anmeldeinformationsanbieter verwenden.
Zugriff für den laufenden Clusterbetrieb erforderlich
Der folgende Netzwerkzugriff für Ihre lokale Firewall ist für den laufenden Clusterbetrieb erforderlich.
Wichtig
Je nachdem, für welches CNI Sie sich entscheiden, müssen Sie zusätzliche Netzwerkzugriffsregeln für die CNI-Ports konfigurieren. Einzelheiten finden Sie in der Cilium-Dokumentation
Typ | Protokoll | Richtung | Port | Quelle | Ziel | Verwendung |
---|---|---|---|---|---|---|
HTTPS |
TCP |
Ausgehend |
443 |
CIDR (s) für Remote-Knoten |
EKS-Cluster 1 IPs |
Kubelet-zu-Kubernetes-API-Server |
HTTPS |
TCP |
Ausgehend |
443 |
CIDR (s) für Remote-Pods |
EKS-Cluster 1 IPs |
Vom Pod zum Kubernetes-API-Server |
HTTPS |
TCP |
Ausgehend |
443 |
CIDR (s) für Remote-Knoten |
SSM-Hybrid-Aktivierungen, Aktualisierung der Anmeldeinformationen und SSM-Heartbeats alle 5 Minuten |
|
HTTPS |
TCP |
Ausgehend |
443 |
CIDR (s) für Remote-Knoten |
Aktualisierung der Anmeldeinformationen für IAM Roles Anywhere |
|
HTTPS |
TCP |
Ausgehend |
443 |
CIDR (s) für Remote-Pods |
Pod zum STS-Endpunkt, nur für IRSA erforderlich |
|
HTTPS |
TCP |
Ausgehend |
443 |
CIDR (s) für Remote-Knoten |
Knoten zum Amazon EKS Auth-Endpunkt, nur für Amazon EKS Pod Identity erforderlich |
|
HTTPS |
TCP |
Eingehend |
10250 |
EKS-Cluster 1 IPs |
CIDR (s) für Remote-Knoten |
Kubelet-zu-Kubernetes-API-Server |
HTTPS |
TCP |
Eingehend |
Webhook-Anschlüsse |
EKS-Cluster 1 IPs |
CIDR (s) für Remote-Pods |
Kubernetes-API-Server für Webhooks |
HTTPS |
TCP, UDP |
Eingehend, Ausgehend |
53 |
CIDR (s) für Remote-Pods |
CIDR (s) für Remote-Pods |
Pod zu CoreDNS. Wenn Sie mindestens ein CoreDNS-Replikat in der Cloud ausführen, müssen Sie DNS-Verkehr zur VPC zulassen, auf der CoreDNS ausgeführt wird. |
Benutzerdefiniert |
Benutzerdefiniert |
Eingehend, Ausgehend |
App-Ports |
CIDR (s) für Remote-Pods |
CIDR (s) für Remote-Pods |
Pod zu Pod |
Anmerkung
1 Der IPs des Amazon EKS-Clusters. Weitere Informationen finden Sie im folgenden Abschnitt über elastische Netzwerkschnittstellen von Amazon EKS.
Amazon EKS-Netzwerkschnittstellen
Amazon EKS fügt Netzwerkschnittstellen an die Subnetze in der VPC an, die Sie bei der Clustererstellung übergeben haben, um die Kommunikation zwischen der Amazon EKS-Steuerebene und Ihrer VPC zu ermöglichen. Die Netzwerkschnittstellen, die Amazon EKS erstellt, finden Sie nach der Clustererstellung in der EC2 Amazon-Konsole oder mit der AWS CLI. Die ursprünglichen Netzwerkschnittstellen werden gelöscht und neue Netzwerkschnittstellen werden erstellt, wenn Änderungen auf Ihren Amazon EKS-Cluster angewendet werden, z. B. Kubernetes-Versionsupgrades. Sie können den IP-Bereich für die Amazon EKS-Netzwerkschnittstellen einschränken, indem Sie eingeschränkte Subnetzgrößen für die Subnetze verwenden, die Sie bei der Clustererstellung passieren. Dies macht es einfacher, Ihre lokale Firewall so zu konfigurieren, dass eingehende/ausgehende Konnektivität zu dieser bekannten, eingeschränkten Gruppe von möglich ist. IPs Um zu kontrollieren, in welchen Subnetzen Netzwerkschnittstellen erstellt werden, können Sie die Anzahl der Subnetze einschränken, die Sie bei der Erstellung eines Clusters angeben, oder Sie können die Subnetze nach der Erstellung des Clusters aktualisieren.
Die von Amazon EKS bereitgestellten Netzwerkschnittstellen haben eine Beschreibung des FormatsAmazon EKS
. Im folgenden Beispiel finden Sie einen AWS CLI-Befehl, mit dem Sie die IP-Adressen der Netzwerkschnittstellen ermitteln können, die Amazon EKS bereitstellt. your-cluster-name
VPC_ID
Ersetzen Sie durch die ID der VPC, die Sie bei der Clustererstellung übergeben haben.
aws ec2 describe-network-interfaces \ --query 'NetworkInterfaces[?(VpcId ==
VPC_ID
&& contains(Description,Amazon EKS
))].PrivateIpAddress'
AWS VPC- und Subnetz-Setup
Die bestehenden VPC- und Subnetzanforderungen für Amazon EKS gelten für Cluster mit Hybridknoten. Darüber hinaus darf sich Ihr VPC-CIDR nicht mit Ihrem lokalen Knoten und Pod überschneiden. CIDRs Sie müssen Routen in Ihrer VPC-Routingtabelle für Ihren lokalen Knoten und optional den Pod konfigurieren. CIDRs Diese Routen müssen so eingerichtet werden, dass der Verkehr an das Gateway weitergeleitet wird, das Sie für Ihre hybride Netzwerkkonnektivität verwenden. Dabei handelt es sich in der Regel um ein Virtual Private Gateway (VGW) oder Transit Gateway (TGW). Wenn Sie TGW oder VGW verwenden, um Ihre VPC mit Ihrer lokalen Umgebung zu verbinden, müssen Sie einen TGW- oder VGW-Anhang für Ihre VPC erstellen. Ihre VPC muss DNS-Hostnamen und die DNS-Auflösung unterstützen.
Die folgenden Schritte verwenden die AWS CLI. Sie können diese Ressourcen auch in AWS Management Console oder mit anderen Schnittstellen wie AWS CloudFormation AWS CDK oder Terraform erstellen.
Schritt 1: VPC erstellen
-
Führen Sie den folgenden Befehl aus, um eine VPC zu erstellen.
VPC_CIDR
Ersetzen Sie es durch einen CIDR-BereichIPv4
gemäß RFC-1918 (privat) oder einen CIDR-Bereich außerhalb von RFC-1918 (öffentlich) (z. B.).10.0.0.0/16
Hinweis: Die DNS-Auflösung, die eine EKS-Anforderung ist, ist standardmäßig für die VPC aktiviert.aws ec2 create-vpc --cidr-block
VPC_CIDR
-
Aktivieren Sie DNS-Hostnamen für Ihre VPC. Beachten Sie, dass die DNS-Auflösung standardmäßig für die VPC aktiviert ist.
VPC_ID
Ersetzen Sie durch die ID der VPC, die Sie im vorherigen Schritt erstellt haben.aws ec2 modify-vpc-attribute --vpc-id
VPC_ID
--enable-dns-hostnames
Schritt 2: Subnetze erstellen
Erstellen Sie mindestens 2 Subnetze. Amazon EKS verwendet diese Subnetze für die Cluster-Netzwerkschnittstellen. Weitere Informationen finden Sie unter Anforderungen und Überlegungen zu Subnetzen.
-
Sie können die Verfügbarkeitszonen für eine AWS Region mit dem folgenden Befehl ermitteln. Ersetze es
us-west-2
durch deine Region.aws ec2 describe-availability-zones \ --query 'AvailabilityZones[?(RegionName ==
us-west-2
)].ZoneName' -
Erstellen Sie ein Subnetz.
VPC_ID
Ersetzen Sie durch die ID der VPC.SUBNET_CIDR
Ersetzen Sie durch den CIDR-Block für Ihr Subnetz (z. B. 10.0.1.0/24).AZ
Ersetzen Sie es durch die Availability Zone, in der das Subnetz erstellt wird (z. B. us-west-2a). Die von Ihnen erstellten Subnetze müssen sich in mindestens 2 verschiedenen Verfügbarkeitszonen befinden.aws ec2 create-subnet \ --vpc-id
VPC_ID
\ --cidr-blockSUBNET_CIDR
\ --availability-zoneAZ
(Optional) Schritt 3: Verbinden Sie VPC mit Amazon VPC Transit Gateway (TGW) oder AWS Direct Connect Virtual Private Gateway (VGW)
Wenn Sie ein TGW oder VGW verwenden, schließen Sie Ihre VPC an das TGW oder VGW an. Weitere Informationen finden Sie unter Amazon VPC-Anlagen in Amazon VPC Transit Gateways- oder AWS Direct Connect Virtual Private Gateway-Verknüpfungen.
Transit-Gateway
Führen Sie den folgenden Befehl aus, um ein Transit Gateway anzuhängen. VPC_ID
Ersetzen Sie durch die ID der VPC. Ersetzen Sie SUBNET_ID1
und SUBNET_ID2
durch die IDs der Subnetze, die Sie im vorherigen Schritt erstellt haben. TGW_ID
Ersetzen Sie es durch die ID Ihres TGW.
aws ec2 create-transit-gateway-vpc-attachment \ --vpc-id
VPC_ID
\ --subnet-idsSUBNET_ID1 SUBNET_ID2
\ --transit-gateway-idTGW_ID
Virtuelles privates Gateway
Führen Sie den folgenden Befehl aus, um ein Transit Gateway anzuhängen. VPN_ID
Ersetzen Sie es durch die ID Ihres VGW. VPC_ID
Ersetzen Sie durch die ID der VPC.
aws ec2 attach-vpn-gateway \ --vpn-gateway-id
VPN_ID
\ --vpc-idVPC_ID
(Optional) Schritt 4: Routentabelle erstellen
Sie können die Hauptroutentabelle für die VPC ändern oder eine benutzerdefinierte Routentabelle erstellen. Mit den folgenden Schritten erstellen Sie eine benutzerdefinierte Routing-Tabelle mit den Routen zum lokalen Knoten und Pod. CIDRs Weitere Informationen finden Sie unter Subnetz-Routentabellen. VPC_ID
Ersetzen Sie durch die ID der VPC.
aws ec2 create-route-table --vpc-id
VPC_ID
Schritt 5: Erstellen Sie Routen für lokale Knoten und Pods
Erstellen Sie Routen in der Routentabelle für jeden Ihrer lokalen Remote-Knoten. Sie können die Hauptroutentabelle für die VPC ändern oder die benutzerdefinierte Routentabelle verwenden, die Sie im vorherigen Schritt erstellt haben.
Die folgenden Beispiele zeigen, wie Sie Routen für Ihren lokalen Knoten und Pod erstellen. CIDRs In den Beispielen wird ein Transit Gateway (TGW) verwendet, um die VPC mit der lokalen Umgebung zu verbinden. Wenn Sie mehrere lokale Knoten und Pods haben CIDRs, wiederholen Sie die Schritte für jeden CIDR.
-
Wenn Sie ein Internet-Gateway oder ein Virtual Private Gateway (VGW) verwenden, ersetzen Sie es durch.
--transit-gateway-id
--gateway-id
-
RT_ID
Ersetzen Sie es durch die ID der Routing-Tabelle, die Sie im vorherigen Schritt erstellt haben. -
REMOTE_NODE_CIDR
Ersetzen Sie durch den CIDR-Bereich, den Sie für Ihre Hybridknoten verwenden werden. -
REMOTE_POD_CIDR
Ersetzen Sie es durch den CIDR-Bereich, den Sie für die Pods verwenden werden, die auf Hybridknoten ausgeführt werden. Der Pod-CIDR-Bereich entspricht der Container Networking Interface (CNI) -Konfiguration, bei der am häufigsten ein lokales Overlay-Netzwerk verwendet wird. Weitere Informationen finden Sie unter Konfigurieren Sie ein CNI für Hybridknoten. -
Ersetzen Sie es
TGW_ID
durch die ID Ihres TGW.
Netzwerk mit Remote-Knoten
aws ec2 create-route \ --route-table-id
RT_ID
\ --destination-cidr-blockREMOTE_NODE_CIDR
\ --transit-gateway-idTGW_ID
Remote-Pod-Netzwerk
aws ec2 create-route \ --route-table-id
RT_ID
\ --destination-cidr-blockREMOTE_POD_CIDR
\ --transit-gateway-idTGW_ID
(Optional) Schritt 6: Ordnen Sie Subnetze der Routentabelle zu
Wenn Sie im vorherigen Schritt eine benutzerdefinierte Routing-Tabelle erstellt haben, ordnen Sie jedes der Subnetze, die Sie im vorherigen Schritt erstellt haben, Ihrer benutzerdefinierten Routentabelle zu. Wenn Sie die VPC-Hauptroutentabelle ändern, werden die Subnetze automatisch der Hauptroutentabelle der VPC zugeordnet, und Sie können diesen Schritt überspringen.
Führen Sie den folgenden Befehl für jedes der Subnetze aus, die Sie in den vorherigen Schritten erstellt haben. RT_ID
Ersetzen Sie es durch die Routing-Tabelle, die Sie im vorherigen Schritt erstellt haben. SUBNET_ID
Ersetzen Sie durch die ID eines Subnetzes.
aws ec2 associate-route-table --route-table-id
RT_ID
--subnet-idSUBNET_ID
Konfiguration der Cluster-Sicherheitsgruppe
Der folgende Zugriff für Ihre Amazon EKS-Cluster-Sicherheitsgruppe ist für den laufenden Clusterbetrieb erforderlich.
Typ | Protokoll | Richtung | Port | Quelle | Ziel | Verwendung |
---|---|---|---|---|---|---|
HTTPS |
TCP |
Eingehend |
443 |
CIDR (s) für Remote-Knoten |
N/A |
Kubelet-zu-Kubernetes-API-Server |
HTTPS |
TCP |
Eingehend |
443 |
CIDR (s) für Remote-Pods |
N/A |
Pods, die Zugriff auf den API-Server von K8 benötigen, wenn das CNI kein NAT für den Pod-Verkehr verwendet. |
HTTPS |
TCP |
Ausgehend |
10250 |
N/A |
CIDR (s) für Remote-Knoten |
Kubernetes-API-Server zu Kubelet |
HTTPS |
TCP |
Ausgehend |
Webhook-Anschlüsse |
N/A |
CIDR (s) für Remote-Pods |
Vom Kubernetes-API-Server zum Webhook (wenn Webhooks auf Hybridknoten ausgeführt werden) |
Führen Sie die folgenden Befehle aus, um eine Sicherheitsgruppe mit den Regeln für den eingehenden Zugriff zu erstellen. Diese Sicherheitsgruppe muss übergeben werden, wenn Sie Ihren Amazon EKS-Cluster erstellen. Standardmäßig erstellt der folgende Befehl eine Sicherheitsgruppe, die den gesamten ausgehenden Zugriff ermöglicht. Sie können den ausgehenden Zugriff so einschränken, dass er nur die oben genannten Regeln einbezieht. Wenn Sie erwägen, die Regeln für ausgehenden Datenverkehr einzuschränken, empfehlen wir Ihnen, alle Ihre Anwendungen und die Pod-Konnektivität gründlich zu testen, bevor Sie Ihre geänderten Regeln auf einen Produktionscluster anwenden.
-
Ersetzen Sie im ersten Befehl SG_NAME durch einen Namen für Ihre Sicherheitsgruppe
-
Ersetzen Sie im ersten Befehl VPC_ID durch die ID der VPC, die Sie im vorherigen Schritt erstellt haben
-
Ersetzen Sie im zweiten Befehl SG_ID durch die ID der Sicherheitsgruppe, die Sie im ersten Befehl erstellt haben
-
Ersetzen Sie im zweiten Befehl REMOTE_NODE_CIDR und REMOTE_POD_CIDR durch die Werte für Ihre Hybridknoten und Ihr lokales Netzwerk.
aws ec2 create-security-group \ --group-name
SG_NAME
\ --description "security group for hybrid nodes" \ --vpc-idVPC_ID
aws ec2 authorize-security-group-ingress \ --group-id
SG_ID
\ --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]'