Vorbereitung der Vernetzung für Hybridknoten - Amazon EKS
Konfiguration des On-Premises-NetzwerksAWS-VPC- und Subnetz-EinrichtungKonfiguration der Cluster-Sicherheitsgruppe

Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Vorbereitung der Vernetzung für Hybridknoten

Dieses Thema bietet einen Überblick über die Netzwerkkonfiguration, die Sie vor der Erstellung Ihres Amazon-EKS-Clusters und dem Hinzufügen von Hybridknoten konfigurieren müssen. In diesem Leitfaden wird davon ausgegangen, dass Sie die Voraussetzungen für die hybride Netzwerkkonnektivität mithilfe von AWS Site-to-Site VPN, AWS Direct Connect oder Ihrer eigenen VPN-Lösung erfüllt haben.

Netzwerkkonnektivität für Hybridknoten.

Konfiguration des On-Premises-Netzwerks

Mindestanforderungen an das Netzwerk

Für eine optimale Leistung empfehlen wir Ihnen eine zuverlässige Netzwerkverbindung mit einer Geschwindigkeit von mindestens 100 Mbit/s und einer maximalen Rundlauf-Latenz von 200 ms für die Verbindung der Hybridknoten mit der AWS-Region. Dies sind allgemeine Leitlinien, die für die meisten Anwendungsfälle geeignet sind, jedoch keine strengen Anforderungen darstellen. Die Bandbreiten- und Latenzanforderungen können je nach Anzahl der Hybridknoten und Ihren Workload-Eigenschaften variieren, z. B. Größe der Anwendungs-Images, Anwendungselastizität, Überwachungs- und Protokollierungskonfigurationen und Anwendungsabhängigkeiten beim Zugriff auf in anderen AWS-Services gespeicherte Daten. Wir empfehlen Ihnen, vor der Bereitstellung in der Produktionsumgebung Tests mit Ihren eigenen Anwendungen und Umgebungen durchzuführen, um sicherzustellen, dass Ihre Netzwerkkonfiguration den Anforderungen Ihrer Workloads entspricht.

On-premises-Knoten- und Pod-CIDRs

Identifizieren Sie die Knoten- und Pod-CIDRs, die Sie für Ihre Hybridknoten und die darauf ausgeführten Workloads verwenden werden. Die Knoten-CIDR wird aus Ihrem On-Premises-Netzwerk zugewiesen, und die Pod-CIDR wird aus Ihrer Container Network Interface (CNI) zugewiesen, wenn Sie ein Überlagerungsnetzwerk für Ihre CNI verwenden. Sie übergeben Ihre On-Premises-Knoten-CIDRs und Pod-CIDRs als Eingaben, wenn Sie Ihren EKS-Cluster mit den Feldern RemoteNodeNetwork und RemotePodNetwork erstellen. Die CIDRs Ihrer On-Premises-Knoten müssen in Ihrem On-Premises-Netzwerk routingfähig sein. Informationen zur CIDR-Routing-Fähigkeit des On-Premises-Pods finden Sie im folgenden Abschnitt.

Die CIDR-Blöcke für den On-Premises-Knoten und den Pod müssen die folgenden Anforderungen erfüllen:

  1. Muss innerhalb eines der folgenden IPv4-RFC-1918-Bereiche liegen: 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16.

  2. Beachten Sie, dass sich die VPC-CIDR für Ihren EKS-Cluster und die IPv4 CIDR Ihres Kubernetes-Service nicht überschneiden dürfen.

On-premises-Pod-Netzwerk-Routing

Bei der Verwendung von EKS-Hybridknoten empfehlen wir generell, die CIDRs Ihrer On-Premises-Pods in Ihrem On-Premises-Netzwerk routingfähig zu machen, um eine vollständige Cluster-Kommunikation und Funktionalität zwischen Cloud- und On-Premises-Umgebungen zu ermöglichen.

Routingfähige Pod-Netzwerke

Wenn Sie Ihr Pod-Netzwerk in Ihrem lokalen Netzwerk routingfähig machen können, befolgen Sie die nachstehenden Anweisungen.

  1. Konfigurieren Sie das RemotePodNetwork-Feld für Ihren EKS-Cluster mit Ihrer On-Premises-Pod-CIDR, Ihre VPC-Routing-Tabellen mit Ihrer On-Premises-Pod-CIDR und Ihre EKS-Cluster-Sicherheitsgruppe mit Ihrer On-Premises-Pod-CIDR.

  2. Es gibt mehrere Techniken, mit denen Sie Ihren On-Premises-Pod CIDR in Ihrem On-Premises-Netzwerk routingfähig machen können, darunter Border Gateway Protocol (BGP), statische Routen oder andere benutzerdefinierte Routing-Lösungen. BGP ist die empfohlene Lösung, da es skalierbarer und einfacher zu verwalten ist als alternative Lösungen, die eine benutzerdefinierte oder manuelle Routing-Konfiguration erfordern. AWS unterstützt die BGP-Funktionen von Cilium und Calico für die Bekanntmachung für Pod-CIDRs. Weitere Informationen finden Sie unter CNI für Hybridknoten konfigurieren und Routingfähige Fern-Pod-CIDRs.

  3. Webhooks können auf Hybridknoten ausgeführt werden, da die EKS-Steuerebene mit den Webhooks zugewiesenen Pod-IP-Adressen kommunizieren kann.

  4. In Cloud-Knoten ausgeführte Workloads können direkt mit Workloads kommunizieren, die auf Hybridknoten im selben EKS-Cluster ausgeführt werden.

  5. Andere AWS-Services, wie AWS Application Load Balancers und Amazon Managed Service for Prometheus, können mit Workloads kommunizieren, die auf Hybridknoten ausgeführt werden, um den Netzwerkverkehr auszugleichen und Pod-Metriken zu erfassen.

Nicht routingfähige Pod-Netzwerke

Wenn Sie Ihre Pod-Netzwerke in Ihrem On-Premises-Netzwerk nicht routingfähig machen können, befolgen Sie die nachstehenden Anweisungen.

  1. Webhooks können nicht in Hybridknoten ausgeführt werden, da Webhooks eine Verbindung von der EKS-Steuerebene zu den den Webhooks zugewiesenen Pod-IP-Adressen erfordern. In diesem Fall empfehlen wir, Webhooks auf Cloud-Knoten im selben EKS-Cluster wie Ihre Hybridknoten auszuführen. Weitere Informationen finden Sie unter Konfiguration von Webhooks für Hybridknoten.

  2. Workloads auf Cloud-Knoten können nicht direkt mit Workloads auf Hybridknoten kommunizieren, wenn VPC CNI für Cloud-Knoten und Cilium oder Calico für Hybridknoten verwendet werden.

  3. Verwenden Sie Verteilung des Service-Datenverkehrs, um den Datenverkehr auf die Zone zu beschränken, aus der er stammt. Weitere Informationen zur Verteilung des Service-Datenverkehrs finden Sie unter Verteilung des Service-Datenverkehrs konfigurieren.

  4. Konfigurieren Sie Ihr CNI so, dass es ausgehende Maskierung oder Network Address Translation (NAT) für den Pod-Datenverkehr verwendet, wenn dieser Ihre On-Premises-Hosts verlässt. Dies ist in Cilium standardmäßig aktiviert. Calico erfordert, dass natOutgoing auf true festgelegt ist.

  5. Andere AWS-Services wie AWS Application Load Balancer und Amazon Managed Service für Prometheus können nicht mit Workloads kommunizieren, die in Hybridknoten ausgeführt werden.

Zugriff während der Installation und Aktualisierung von Hybridknoten erforderlich

Während der Installation, bei der Sie die Abhängigkeiten der Hybridknoten auf Ihren Hosts installieren, müssen Sie Zugriff auf die folgenden Domains haben. Dieser Vorgang kann einmalig beim Erstellen Ihrer Betriebssystem-Images oder zur Laufzeit auf jedem Host durchgeführt werden. Dies gilt sowohl für die Erstinstallation als auch für das Upgrade der Kubernetes-Version Ihrer Hybridknoten.

Einige Pakete werden mit dem Standard-Paket-Manager des Betriebssystems installiert. Für AL2023 und RHEL wird der yum-Befehl für die Installation von containerd, ca-certificates, iptables und amazon-ssm-agent verwendet. Für Ubuntu, apt wird für die Installation von containerd, ca-certificates und iptables und snap wird für die Installation von amazon-ssm-agent verwendet.

Komponente URL Protokoll Port

EKS-Knoten-Artefakte (S3)

https://hybrid-assets.eks.amazonaws.com

HTTPS

443

EKS-Service-Endpunkte

https://eks.region.amazonaws.com

HTTPS

443

ECR-Service-Endpunkte

https://api.ecr.region.amazonaws.com

HTTPS

443

EKS-ECR-Endpunkte

Informationen zu regionalen Endpunkten finden Sie unter Amazon-Container-Image-Registries für Amazon-EKS-Add-Ons anzeigen.

HTTPS

443

SSM-Binärendpunkt 1

https://amazon-ssm-region.s3.region.amazonaws.com

HTTPS

443

SSM-Service-Endpunkt 1

https://ssm.region.amazonaws.com

HTTPS

443

IAM-Anywhere-Binärendpunkt 2

https://rolesanywhere.amazonaws.com

HTTPS

443

IAM-Anywhere-Service-Endpunkt 2

https://rolesanywhere.region.amazonaws.com

HTTPS

443

Endpunkte des Paket-Managers des Betriebssystems

Die Endpunkte des Paket-Repositorys sind betriebssystemspezifisch und können je nach geografischer Region variieren.

HTTPS

443
Anmerkung

1 Der Zugriff auf die AWS-SSM-Endpunkte ist nur erforderlich, wenn Sie AWS-SSM-Hybridaktivierungen für Ihren On-Premises-IAM-Anmeldeinformationsanbieter verwenden.

2 Der Zugriff auf die AWS-IAM-Endpunkte ist nur erforderlich, wenn Sie AWS IAM Roles Anywhere für Ihren On-Premises-IAM-Anmeldeinformationsanbieter verwenden.

Zugriff für den fortlaufenden Cluster-Betrieb erforderlich

Für den kontinuierlichen Cluster-Betrieb ist der folgende Netzwerkzugang für Ihre On-Premises-Firewall erforderlich.

Wichtig

Je nach Ihrer Wahl des CNI müssen Sie zusätzliche Netzwerk-Zugriffsregeln für die CNI-Ports konfigurieren. Weitere Informationen finden Sie in der Cilium-Dokumentation und der Calico-Dokumentation.

Typ Protokoll Richtung Port Quelle Ziel Verwendung

HTTPS

TCP

Ausgehend

443

Fern-Knoten-CIDR(s)

EKS-Cluster-IPs 1

kubelet zum Kubernetes-API-Server

HTTPS

TCP

Ausgehend

443

Fern-Pod-CIDR(s)

EKS-Cluster-IPs 1

Pod zum Kubernetes-API-Server

HTTPS

TCP

Ausgehend

443

Fern-Knoten-CIDR(s)

SSM-Service-Endpunkt

Aktualisierung der Anmeldeinformationen für SSM-Hybridaktivierungen und SSM-Heartbeats alle 5 Minuten

HTTPS

TCP

Ausgehend

443

Fern-Knoten-CIDR(s)

IAM-Anywhere-Service-Endpunkt

Aktualisierung der Anmeldeinformationen für IAM Roles Anywhere

HTTPS

TCP

Ausgehend

443

Fern-Pod-CIDR(s)

Regionales STS-Endpunkt

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

HTTPS

TCP

Ausgehend

443

Fern-Knoten-CIDR(s)

Service-Endpunk für Amazon EKS Auth

Knoten zum Amazon-EKS-Auth-Endpunkt, nur für Amazon EKS Pod Identity erforderlich

HTTPS

TCP

Eingehend

10250

EKS-Cluster-IPs 1

Fern-Knoten-CIDR(s)

Kubernetes-API-Server zu Kubelet

HTTPS

TCP

Eingehend

Webhook-Ports

EKS-Cluster-IPs 1

Fern-Pod-CIDR(s)

Kubernetes-API-Server zu Webhooks

HTTPS

TCP, UDP

Eingehend, ausgehend

53

Fern-Pod-CIDR(s)

Fern-Pod-CIDR(s)

Pod zu CoreDNS. Wenn Sie mindestens eine Replik von CoreDNS in der Cloud ausführen, müssen Sie DNS-Datenverkehr zum VPC zulassen, auf dem CoreDNS ausgeführt wird.

Benutzerdefiniert

Benutzerdefiniert

Eingehend, ausgehend

App-Ports

Fern-Pod-CIDR(s)

Fern-Pod-CIDR(s)

Pod zu Pod
Anmerkung

1 Die IPs des EKS-Clusters. Weitere Informationen finden Sie im folgenden Abschnitt zu elastischen Netzwerkschnittstellen von Amazon EKS.

Amazon-EKS-Netzwerkschnittstellen

Amazon EKS fügt Netzwerkschnittstellen an die Subnetze in der VPC an, die Sie bei der Cluster-Erstellung übergeben, um die Kommunikation zwischen der EKS-Steuerebene und Ihrer VPC zu ermöglichen. Die von Amazon EKS erstellten Netzwerkschnittstellen finden Sie nach der Cluster-Erstellung in der Amazon-EC2-Konsole oder mit der AWS CLI. Die ursprünglichen Netzwerkschnittstellen werden gelöscht und neue Netzwerkschnittstellen erstellt, wenn Änderungen an Ihrem EKS-Cluster vorgenommen werden, z. B. Upgrades der Kubernetes-Version. 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 während der Cluster-Erstellung übergeben. Dadurch wird es einfacher, Ihre On-Premises-Firewall so zu konfigurieren, dass eingehende/ausgehende Konnektivität zu diesem bekannten, eingeschränkten Satz von IPs zugelassen wird. Um zu steuern, in welchen Subnetzen Netzwerkschnittstellen erstellt werden, können Sie die Anzahl der Subnetze begrenzen, die Sie beim Erstellen eines Clusters angeben, oder Sie können die Subnetze nach dem Erstellen des Clusters aktualisieren.

Die von Amazon EKS bereitgestellten Netzwerkschnittstellen verfügen über eine Beschreibung im Format Amazon EKS your-cluster-name . Im folgenden Beispiel finden Sie einen AWS-CLI-Befehl, mit dem Sie die IP-Adressen der von Amazon EKS bereitgestellten Netzwerkschnittstellen ermitteln können. Ersetzen Sie VPC_ID durch die ID der VPC, die Sie bei der Cluster-Erstellung übergeben haben.

aws ec2 describe-network-interfaces \
--query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress'

AWS-VPC- und Subnetz-Einrichtung

Die vorhandenen VPC- und Subnetz-Anforderungen für Amazon EKS gelten für Cluster mit Hybridknoten. Darüber hinaus darf sich Ihr VPC-CIDR nicht mit den CIDRs Ihrer On-Premises-Knoten und Pods überschneiden. Sie müssen in Ihrer VPC-Routing-Rabelle Routen für Ihre On-Premises-Knoten und optional Pod-CIDRs konfigurieren. Diese Routen müssen so eingerichtet werden, dass der Datenverkehr an das Gateway weitergeleitet wird, das Sie für Ihre Hybridnetzwerkkonnektivität verwenden. Dabei handelt es sich üblicherweise um ein Virtual Private Gateway (VGW) oder ein Transit Gateway (TGW). Wenn Sie TGW oder VGW verwenden, um Ihre VPC mit Ihrer On-Premises-Umgebung zu verbinden, müssen Sie eine TGW- oder VGW-Anbindung für Ihre VPC erstellen. Ihre VPC muss DNS-Hostnamen und die DNS-Auflösung unterstützen.

Die folgenden Schritte werden über die AWS CLI ausgeführt. Sie können diese Ressourcen auch im AWS-Managementkonsole 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. Ersetzen Sie VPC_CIDR durch einen IPv4-RFC-1918-CIDR-Bereich (privat) oder einen Nicht-RFC-1918-CIDR-Bereich (öffentlich) (zum Beispiel 10.0.0.0/16). Hinweis: Die DNS-Auflösung, eine EKS-Anforderung, ist für die VPC standardmäßig aktiviert.

    aws ec2 create-vpc --cidr-block VPC_CIDR

  2. Aktivieren Sie DNS-Host-Namen für Ihre VPC. Beachten Sie, dass die DNS-Auflösung für die VPC standardmäßig aktiviert ist. Ersetzen Sie VPC_ID 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. Mit dem folgenden Befehl können Sie die Availability Zones für eine AWS-Region ermitteln. Ersetzen Sie us-west-2 durch Ihre Region.

    aws ec2 describe-availability-zones \
     --query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName'

  2. Erstellen Sie ein Subnetz. Ersetzen Sie VPC_ID durch die ID der VPC. Ersetzen Sie SUBNET_CIDR durch den CIDR-Block für Ihr Subnetz (z. B. 10.0.1.0/24 ). Ersetzen Sie AZ durch die Availability Zone, in der das Subnetz erstellt werden soll (z. B. „us-west-2a“). Die von Ihnen erstellten Subnetze müssen sich in mindestens zwei verschiedenen Availability Zones befinden.

    aws ec2 create-subnet \
    --vpc-id VPC_ID \
    --cidr-block SUBNET_CIDR \
    --availability-zone AZ

(Optional) Schritt 3: VPC mit Amazon VPC Transit Gateway (TGW) oder AWS Direct Connect Virtual Private Gateway (VGW) verbinden

Wenn Sie ein TGW oder VGW verwenden, fügen Sie Ihr VPC an das TGW oder VGW an. Weitere Informationen finden Sie unter Amazon-VPC-Anhänge in Amazon VPC Transit Gateways oder Zuordnungen von AWS Direct Connect Virtual Private Gateway.

Transit-Gateway

Führen Sie den folgenden Befehl aus, um ein Transit Gateway anzufügen. Ersetzen Sie VPC_ID durch die ID der VPC. Ersetzen Sie SUBNET_ID1 und SUBNET_ID2 durch die IDs der Subnetze, die Sie im vorherigen Schritt erstellt haben. Ersetzen Sie TGW_ID 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

Virtual Private Gateway

Führen Sie den folgenden Befehl aus, um ein Transit Gateway anzufügen. Ersetzen Sie VPN_ID durch die ID Ihres VGW. Ersetzen Sie VPC_ID durch die ID der VPC.

aws ec2 attach-vpn-gateway \
    --vpn-gateway-id VPN_ID \
    --vpc-id VPC_ID

(Optional) Schritt 4: Routing-Tabelle erstellen

Sie können die Haupt-Routing-Tabelle für die VPC ändern oder eine benutzerdefinierte Routing-Tabelle erstellen. Mit den folgenden Schritten erstellen Sie eine benutzerdefinierte Routing-Tabelle mit den Routen zu On-Premises-Knoten und Pod-CIDRs. Weitere Informationen finden Sie unter Subnetz-Routing-Tabellen. Ersetzen Sie VPC_ID durch die ID der VPC.

aws ec2 create-route-table --vpc-id VPC_ID

Schritt 5: Routen für On-Premises-Knoten und -Pods erstellen

Erstellen Sie Routen in der Routing-Tabelle für jeden Ihrer On-Premises-Fern-Knoten. Sie können die Haupt-Routing-Tabelle für die VPC ändern oder die benutzerdefinierte Routing-Tabelle verwenden, die Sie im vorherigen Schritt erstellt haben.

Die nachfolgenden Beispiele veranschaulichen, wie Sie Routen für Ihre On-Premises-Knoten- und Pod-CIDRs erstellen. In den Beispielen wird ein Transit Gateway (TGW) verwendet, um die VPC mit der On-Premises-Umgebung zu verbinden. Wenn Sie über mehrere On-Premises-Knoten- und Pod-CIDRs verfügen, wiederholen Sie die Schritte für jede CIDR.

  • Wenn Sie ein Internet-Gateway oder ein Virtual Private Gateway (VGW) verwenden, ersetzen Sie --transit-gateway-id durch --gateway-id.

  • Ersetzen Sie RT_ID durch die ID der Routing-Tabelle, die Sie im vorherigen Schritt erstellt haben.

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

  • Ersetzen Sie REMOTE_POD_CIDR durch den CIDR-Bereich, den Sie für die auf Hybridknoten ausgeführten Pods verwenden. Der Pod-CIDR-Bereich entspricht der Container Networking Interface (CNI)-Konfiguration, die in der Regel ein Überlagerungsnetzwerk On-Premises verwendet. Weitere Informationen finden Sie unter CNI für Hybridknoten konfigurieren.

  • Ersetzen Sie TGW_ID durch die ID Ihres TGW.

Fern-Knoten-Netzwerk 

aws ec2 create-route \
    --route-table-id RT_ID \
    --destination-cidr-block REMOTE_NODE_CIDR \
    --transit-gateway-id TGW_ID

Fern-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: Subnetze der Routing-Tabelle zuordnen

Wenn Sie im vorherigen Schritt eine benutzerdefinierte Routing-Tabelle erstellt haben, ordnen Sie jede der im vorherigen Schritt erstellten Subnetze Ihrer benutzerdefinierten Routing-Tabelle zu. Wenn Sie die VPC-Haupt-Routing-Tabelle ändern, werden die Subnetze automatisch der Haupt-Routing-Tabelle 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. Ersetzen Sie RT_ID durch die Routing-Tabelle, die Sie im vorherigen Schritt erstellt haben. Ersetzen Sie SUBNET_ID durch die ID eines Subnetzes.

aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID

Konfiguration der Cluster-Sicherheitsgruppe

Für den fortlaufenden Cluster-Betrieb ist der folgende Zugriff für Ihre EKS-Cluster-Sicherheitsgruppe erforderlich. Amazon EKS erstellt automatisch die erforderlichen Regeln für eingehende Sicherheitsgruppen für Hybridknoten, wenn Sie Ihren Cluster mit konfigurierten Fern-Knoten- und Pod-Netzwerken erstellen oder aktualisieren. Da Sicherheitsgruppen standardmäßig den gesamten ausgehenden Datenverkehr zulassen, ändert Amazon EKS die ausgehenden Regeln der Cluster-Sicherheitsgruppe für Hybridknoten nicht automatisch. Wenn Sie die Cluster-Sicherheitsgruppe anpassen möchten, können Sie den Datenverkehr auf die Regeln in der folgenden Tabelle beschränken.

Typ Protokoll Richtung Port Quelle Ziel Verwendung

HTTPS

TCP

Eingehend

443

Fern-Knoten-CIDR(s)

N/A

Kubelet zum Kubernetes API-Server

HTTPS

TCP

Eingehend

443

Fern-Pod-CIDR(s)

N/A

Pods, die Zugriff auf den K8s-API-Server erfordern, wenn das CNI kein NAT für den Pod-Datenverkehr verwendet.

HTTPS

TCP

Ausgehend

10250

N/A

Fern-Knoten-CIDR(s)

Kubernetes-API-Server zu Kubelet

HTTPS

TCP

Ausgehend

Webhook-Ports

N/A

Fern-Pod-CIDR(s)

Kubernetes-API-Server zum Webhook (beim Ausführen von Webhooks in Hybridknoten)
Wichtig

Beschränkungen für Sicherheitsgruppenregeln: Amazon-EC2-Sicherheitsgruppen verfügen standardmäßig über maximal 60 eingehende Regeln. Die eingehenden Regeln der Sicherheitsgruppe werden möglicherweise nicht angewendet, wenn die Sicherheitsgruppe Ihres Clusters diese Beschränkung erreicht. In diesem Fall kann es erforderlich sein, die fehlenden eingehenden Regeln manuell hinzuzufügen.

Verantwortung für die Bereinigung von CIDR: Wenn Sie Fern-Knoten- oder Pod-Netzwerke aus EKS-Clustern entfernen, löscht EKS die entsprechenden Sicherheitsgruppenregeln nicht automatisch. Sie sind dafür verantwortlich, nicht verwendete Fern-Knoten- oder Pod-Netzwerke manuell aus Ihren Sicherheitsgruppenregeln zu entfernen.

Weitere Informationen zu der Cluster-Sicherheitsgruppe, die Amazon EKS erstellt, finden Sie unter Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen.

(Optional) Manuelle Konfiguration der Sicherheitsgruppe

Sollten Sie zusätzliche Sicherheitsgruppen erstellen oder die automatisch erstellten Regeln ändern müssen, können Sie die folgenden Befehle als Referenz verwenden. Standardmäßig erstellt der folgende Befehl eine Sicherheitsgruppe, die den gesamten ausgehenden Datenverkehr zulässt. Sie können den ausgehenden Zugriff einschränken, sodass nur die oben genannten Regeln gelten. Wenn Sie eine Einschränkung der ausgehenden Regeln in Erwägung ziehen, empfehlen wir Ihnen, alle Ihre Anwendungen und die Pod-Konnektivität gründlich zu testen, bevor Sie Ihre geänderten Regeln auf einen Produktions-Cluster 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 On-Premises-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"}]}]'