Bereiten Sie das Netzwerk für Hybridknoten vor - Amazon EKS

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.

Netzwerkkonnektivität mit hybriden Knoten.

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:

  1. 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

  2. Ü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

EKS-Dienstendpunkte

https://eks. region.amazonaws.com

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 - region .s3. region.amazonaws.com

HTTPS

443

SSM-Dienstendpunkt 1

https://ssm. region.amazonaws.com

HTTPS

443

Binärer IAM Anywhere-Endpunkt 2

https://rolesanywhere.amazonaws.com

HTTPS

443

IAM Anywhere-Dienstendpunkt 2

https://rolesanywhere. region.amazonaws.com

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 und der Calico-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-Dienstendpunkt

SSM-Hybrid-Aktivierungen, Aktualisierung der Anmeldeinformationen und SSM-Heartbeats alle 5 Minuten

HTTPS

TCP

Ausgehend

443

CIDR (s) für Remote-Knoten

IAM Anywhere-Dienstendpunkt

Aktualisierung der Anmeldeinformationen für IAM Roles Anywhere

HTTPS

TCP

Ausgehend

443

CIDR (s) für Remote-Pods

Regionaler STS-Endpunkt

Pod zum STS-Endpunkt, nur für IRSA erforderlich

HTTPS

TCP

Ausgehend

443

CIDR (s) für Remote-Knoten

Endpunkt des Amazon EKS-Authentifizierungsdienstes

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 your-cluster-name . Im folgenden Beispiel finden Sie einen AWS CLI-Befehl, mit dem Sie die IP-Adressen der Netzwerkschnittstellen ermitteln können, die Amazon EKS bereitstellt. VPC_IDErsetzen 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

  1. Führen Sie den folgenden Befehl aus, um eine VPC zu erstellen. VPC_CIDRErsetzen Sie es durch einen CIDR-Bereich IPv4 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
  2. Aktivieren Sie DNS-Hostnamen für Ihre VPC. Beachten Sie, dass die DNS-Auflösung standardmäßig für die VPC aktiviert ist. VPC_IDErsetzen 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.

  1. 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'
  2. Erstellen Sie ein Subnetz. VPC_IDErsetzen Sie durch die ID der VPC. SUBNET_CIDRErsetzen Sie durch den CIDR-Block für Ihr Subnetz (z. B. 10.0.1.0/24). AZErsetzen 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-block SUBNET_CIDR \ --availability-zone AZ

(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_IDErsetzen 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_IDErsetzen Sie es durch die ID Ihres TGW.

aws ec2 create-transit-gateway-vpc-attachment \ --vpc-id VPC_ID \ --subnet-ids SUBNET_ID1 SUBNET_ID2 \ --transit-gateway-id TGW_ID

Virtuelles privates Gateway

Führen Sie den folgenden Befehl aus, um ein Transit Gateway anzuhängen. VPN_IDErsetzen Sie es durch die ID Ihres VGW. VPC_IDErsetzen Sie durch die ID der VPC.

aws ec2 attach-vpn-gateway \ --vpn-gateway-id VPN_ID \ --vpc-id VPC_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_IDErsetzen 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_IDErsetzen Sie es durch die ID der Routing-Tabelle, die Sie im vorherigen Schritt erstellt haben.

  • REMOTE_NODE_CIDRErsetzen Sie durch den CIDR-Bereich, den Sie für Ihre Hybridknoten verwenden werden.

  • REMOTE_POD_CIDRErsetzen 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-block REMOTE_NODE_CIDR \ --transit-gateway-id TGW_ID

Remote-Pod-Netzwerk

aws ec2 create-route \ --route-table-id RT_ID \ --destination-cidr-block REMOTE_POD_CIDR \ --transit-gateway-id TGW_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_IDErsetzen Sie es durch die Routing-Tabelle, die Sie im vorherigen Schritt erstellt haben. SUBNET_IDErsetzen Sie durch die ID eines Subnetzes.

aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_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-id VPC_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"}]}]'