Unterstützung für die Verbesserung dieser Seite beitragen
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.
Um zu diesem Benutzerhandbuch beizutragen, 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.
Voraussetzungen für die Einrichtung von Hybridknoten
Um Amazon EKS-Hybridknoten verwenden zu können, müssen Sie private Konnektivität von Ihrer lokalen Umgebung zu/von AWS Bare-Metal-Servern oder virtuellen Maschinen mit einem unterstützten Betriebssystem haben und AWS IAM Roles Anywhere- oder AWS Systems Manager (SSM) -Hybridaktivierungen konfiguriert haben. Sie sind für die Verwaltung dieser Voraussetzungen während des gesamten Lebenszyklus der Hybridknoten verantwortlich.
-
Hybride Netzwerkkonnektivität von Ihrer lokalen Umgebung zu/von AWS
-
Infrastruktur in Form von physischen oder virtuellen Rechnern
-
Mit Hybridknoten kompatibles Betriebssystem
-
On-Premises IAM-Anmeldeinformationsanbieter konfiguriert
Hybride Netzwerkkonnektivität
Die Kommunikation zwischen der Amazon-EKS-Steuerebene und den Hybridknoten wird über die VPC und Subnetze geleitet, die Sie während der Cluster-Erstellung übergeben. Dies baut auf dem vorhandenen Mechanismus
Für ein optimales Erlebnis empfehlen wir eine zuverlässige Netzwerkkonnektivität von mindestens 100 Mbit/s und eine maximale Round-Trip-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 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. 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-Netzwerkkonfiguration
Sie müssen den eingehenden Netzwerkzugriff von der Amazon-EKS-Steuerebene auf Ihre On-Premises-Umgebung aktivieren, damit die Amazon-EKS-Steuerebene mit dem in Hybridknoten ausgeführten kubelet und optional mit in Ihren Hybridknoten ausgeführten Webhooks kommunizieren kann. Darüber hinaus müssen Sie den ausgehenden Netzwerkzugriff für Ihre Hybridknoten und die darauf ausgeführten Komponenten aktivieren, damit diese mit der Amazon-EKS-Steuerebene kommunizieren können. Sie können diese Kommunikation so konfigurieren, dass Ihre AWS Direct Connect-, AWS Site-to-Site VPN- oder Ihre eigene VPN-Verbindung vollständig privat bleibt.
Die CIDR-Bereiche (Classless Inter-Domain Routing), die Sie für Ihre lokalen Knoten- und Pod-Netzwerke verwenden, müssen IPv4 RFC-1918- oder CGNAT-Adressbereiche verwenden. Ihr On-Premises Router muss mit Routen zu Ihren On-Premises Knoten und optional zu Pods konfiguriert sein. Weitere Informationen zu den Anforderungen an das On-Premises-Netzwerk, einschließlich einer vollständigen Liste der erforderlichen Ports und Protokolle, die in Ihrer Firewall und Ihrer On-Premises-Umgebung aktiviert werden müssen, finden Sie unter Konfiguration des On-Premises-Netzwerks.
EKS-Cluster-Konfiguration
Um die Latenz zu minimieren, empfehlen wir Ihnen, Ihren Amazon EKS-Cluster in der AWS Region zu erstellen, die Ihrer lokalen Umgebung oder Edge-Umgebung am nächsten liegt. Sie übergeben Ihren lokalen Knoten und Pod CIDRs während der Amazon EKS-Clustererstellung über zwei API-Felder: RemoteNodeNetwork undRemotePodNetwork. Möglicherweise müssen Sie mit Ihrem lokalen Netzwerkteam darüber sprechen, wie Sie Ihren lokalen Knoten und Pod identifizieren können. CIDRs Der Knoten-CIDR wird von Ihrem On-Premises-Netzwerk zugewiesen und der Pod-CIDR wird von der Container Network Interface (CNI) zugewiesen, die Sie verwenden, wenn Sie ein Überlagerungsnetzwerk für Ihr CNI verwenden. Cilium und Calico verwenden standardmäßig Überlagerungsnetzwerke.
Der lokale Knoten und der Pod, die CIDRs Sie über die RemotePodNetwork Felder RemoteNodeNetwork und konfigurieren, werden verwendet, um die Amazon EKS-Steuerebene so zu konfigurieren, dass der Datenverkehr über Ihre VPC zu den kubelet und den Pods geleitet wird, die auf Ihren Hybridknoten ausgeführt werden. Ihr lokaler Knoten und Ihr Pod CIDRs dürfen sich nicht miteinander, mit der VPC-CIDR, die Sie bei der Clustererstellung übergeben, oder mit der IPv4 Servicekonfiguration für Ihren Amazon EKS-Cluster überschneiden. Außerdem CIDRs muss der Pod für jeden EKS-Cluster einzigartig sein, damit Ihr lokaler Router den Verkehr weiterleiten kann.
Wir empfehlen, entweder den öffentlichen oder den privaten Endpunktzugriff für den API-Server-Endpunkt von Amazon EKS Kubernetes zu verwenden. Wenn Sie „Öffentlich und privat“ wählen, wird der Amazon EKS Kubernetes API-Serverendpunkt IPs für Hybridknoten, die außerhalb Ihrer VPC laufen, immer öffentlich aufgelöst, wodurch verhindert werden kann, dass Ihre Hybridknoten dem Cluster beitreten. Wenn Sie den öffentlichen Endpunktzugriff verwenden, wird der Kubernetes-API-Serverendpunkt öffentlich aufgelöst IPs und die Kommunikation von Hybridknoten zur Amazon EKS-Kontrollebene wird über das Internet geleitet. Wenn Sie privaten Endpunktzugriff wählen, wird der Kubernetes-API-Serverendpunkt in privat aufgelöst IPs und die Kommunikation von Hybridknoten zur Amazon EKS-Kontrollebene wird über Ihre private Konnektivitätsverbindung, in den meisten Fällen AWS Direct Connect oder VPN, geleitet. AWS Site-to-Site
VPC-Konfiguration
Sie müssen die VPC, die Sie bei der Erstellung des Amazon-EKS-Clusters übergeben, mit Routen in der Routing-Tabelle für Ihren On-Premises-Knoten und optional für Pod-Netzwerke mit Ihrem Virtual Private Gateway (VGW) oder Transit Gateway (TGW) als Ziel konfigurieren. Es folgt ein Beispiel. Ersetzen Sie REMOTE_NODE_CIDR und REMOTE_POD_CIDR durch die Werte für Ihr On-Premises-Netzwerk.
| Bestimmungsort | Target | Description |
|---|---|---|
|
10.226.0.0/16 |
local |
Lokaler Datenverkehr zu den VPC-Routen innerhalb der VPC |
|
REMOTE_NODE_CIDR |
tgw-abcdef123456 |
CIDR des On-Premises-Knotens, Weiterleitung des Datenverkehrs an den TGW |
|
REMODE_POD_CIDR |
tgw-abcdef123456 |
CIDR des On-Premises-Pods, Weiterleitung des Datenverkehrs an den TGW |
Sicherheitsgruppenkonfiguration
Wenn Sie einen Cluster erstellen, erstellt Amazon EKS eine Sicherheitsgruppe mit dem Namen eks-cluster-sg-<cluster-name>-<uniqueID>. Sie können die eingehenden Regeln dieser Cluster-Sicherheitsgruppe nicht ändern. Sie können jedoch die ausgehenden Regeln einschränken. Sie müssen Ihrem Cluster eine zusätzliche Sicherheitsgruppe hinzufügen, um das Kubelet und optional die auf Ihren Hybridknoten ausgeführten Webhooks zu aktivieren, damit sie Kontakt mit der Amazon-EKS-Steuerebene aufnehmen können. Die erforderlichen Eingangsregeln für diese zusätzliche Sicherheitsgruppe sind unten aufgeführt. Ersetzen Sie REMOTE_NODE_CIDR und REMOTE_POD_CIDR durch die Werte für Ihr On-Premises-Netzwerk.
| Name | ID der Sicherheitsgruppenregel | IP-Version | Typ | Protocol (Protokoll) | Port-Bereich | Quelle |
|---|---|---|---|---|---|---|
|
On-Premise-Knoten eingehend |
sgr-abcdef123456 |
IPv4 |
HTTPS |
TCP |
443 |
REMOTE_NODE_CIDR |
|
On-Premise-Pod eingehend |
sgr-abcdef654321 |
IPv4 |
HTTPS |
TCP |
443 |
REMOTE_POD_CIDR |
Infrastruktur
Sie müssen über Bare-Metal-Server oder virtuelle Rechnern verfügen, die Sie als Hybridknoten verwenden können. Hybridknoten sind unabhängig von der zugrunde liegenden Infrastruktur und unterstützen x86- und ARM-Architekturen. Amazon EKS Hybrid Nodes verfolgt einen „Bring Your Own Infrastructure“-Ansatz, bei dem Sie für die Bereitstellung und Verwaltung der Bare-Metal-Server oder virtuellen Rechnern verantwortlich sind, die Sie für Hybridknoten verwenden. Es gibt zwar keine strengen Mindestanforderungen an die Ressource, jedoch empfehlen wir, für Hybridknoten Hosts mit mindestens 1 vCPU und 1 GiB RAM zu verwenden.
Betriebssystem
Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu und RHEL werden fortlaufend für die Verwendung als Knotenbetriebssystem für Hybridknoten validiert. Bottlerocket wird nur AWS in VMware vSphere-Umgebungen unterstützt. AL2023 ist nicht durch AWS Supportpläne abgedeckt, wenn es außerhalb von Amazon EC2 ausgeführt wird. AL2023 kann nur in lokalen virtualisierten Umgebungen verwendet werden. Weitere Informationen finden Sie im Amazon Linux 2023 User Guide. AWS unterstützt die Integration von Hybridknoten mit den Betriebssystemen Ubuntu und RHEL, bietet jedoch keine Unterstützung für das Betriebssystem selbst.
Sie sind für die Bereitstellung und Verwaltung des Betriebssystems verantwortlich. Wenn Sie Hybridknoten zum ersten Mal testen, ist es am einfachsten, die CLI für Amazon EKS Hybrid Nodes (nodeadm) auf einem bereits bereitgestellten Host auszuführen. Für Produktionsbereitstellungen empfehlen wir, nodeadm in Ihre Golden-Betriebssystem-Images aufzunehmen und es so zu konfigurieren, dass es als systemd-Service ausgeführt wird, um Hosts beim Host-Startup automatisch mit Amazon-EKS-Clustern zu verbinden.
On-Premises IAM-Anmeldeinformationsanbieter
Amazon EKS-Hybridknoten verwenden temporäre IAM-Anmeldeinformationen, die durch AWS SSM-Hybrid-Aktivierungen oder AWS IAM Roles Anywhere bereitgestellt werden, um sich beim Amazon EKS-Cluster zu authentifizieren. Sie müssen entweder AWS SSM-Hybrid-Aktivierungen oder AWS IAM Roles Anywhere mit der Amazon EKS Hybrid Nodes CLI () verwenden. nodeadm Wir empfehlen, AWS SSM-Hybrid-Aktivierungen zu verwenden, wenn Sie nicht über eine bestehende Public Key-Infrastruktur (PKI) mit einer Zertifizierungsstelle (CA) und Zertifikaten für Ihre lokalen Umgebungen verfügen. Wenn Sie bereits über PKI und Zertifikate vor Ort verfügen, verwenden Sie IAM Roles Anywhere. AWS
Ähnlich wie bei Amazon-EKS-Knoten-IAM-Rolle für Knoten, die auf Amazon EC2 ausgeführt werden, erstellen Sie eine IAM-Rolle für Hybridknoten mit den erforderlichen Berechtigungen, um Hybridknoten mit Amazon-EKS-Clustern zu verbinden. Wenn Sie AWS IAM Roles Anywhere verwenden, konfigurieren Sie eine Vertrauensrichtlinie, die es IAM Roles Anywhere ermöglicht, die AWS IAM-Rolle Hybrid Nodes zu übernehmen, und konfigurieren Sie Ihr IAM Roles Anywhere-Profil mit der Hybrid Nodes AWS IAM-Rolle als angenommener Rolle. Wenn Sie AWS SSM verwenden, konfigurieren Sie eine Vertrauensrichtlinie, die es AWS SSM ermöglicht, die IAM-Rolle Hybrid Nodes zu übernehmen und die Hybrid-Aktivierung mit der Hybrid Nodes IAM-Rolle zu erstellen. Informationen zum Erstellen der IAM-Rolle für Hybridknoten mit den erforderlichen Berechtigungen finden Sie unter Vorbereitung der Anmeldeinformationen für Hybridknoten.