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.
Netzwerkkonzepte für Hybridknoten
In diesem Abschnitt werden die wichtigsten Netzwerkkonzepte und die Einschränkungen erläutert, die Sie bei der Gestaltung Ihrer Netzwerk-Topologie für EKS-Hybridknoten berücksichtigen müssen.
Netzwerkkonzepte für EKS-Hybridknoten
VPC als Netzwerk-Bereich
Der gesamte Datenverkehr, der die Cloud-Grenze überschreitet, wird über Ihre VPC geleitet. Dies umfasst den Datenverkehr zwischen der EKS-Steuerebene oder den in AWS ausgeführten Pods und den darauf ausgeführten Hybridknoten oder Pods. Sie können sich die VPC Ihres Clusters als Netzwerk-Bereich zwischen Ihren Hybridknoten und dem Rest des Clusters vorstellen. Diese Architektur ermöglicht Ihnen die vollständige Kontrolle über den Datenverkehr und dessen Weiterleitung, überträgt Ihnen jedoch auch die Verantwortung für die korrekte Konfiguration von Routen, Sicherheitsgruppen und Firewalls für die VPC.
EKS-Steuerebene zur VPC
Die EKS-Steuerebene verbindet Elastic Network Interfaces (ENIs) mit Ihrem VPC. Diese ENIs verarbeiten den Datenverkehr zum und vom EKS-API-Server. Sie steuern die Platzierung der EKS-Steuerebenen-ENIs bei der Konfiguration Ihres Clusters, da EKS ENIs mit den Subnetzen verbindet, die Sie bei der Cluster-Erstellung übergeben.
EKS ordnet Sicherheitsgruppen den ENIs zu, die EKS mit Ihren Subnetzen verbindet. Diese Sicherheitsgruppen ermöglichen den Datenverkehr von und zur EKS-Steuerebene über die ENIs. Dies ist für EKS-Hybridknoten wichtig, da Sie Datenverkehr von den Hybridknoten und den darauf ausgeführten Pods zu den EKS-Steuerebenen-ENIs zulassen müssen.
Fern-Knoten-Netzwerke
Die Fern-Knoten-Netzwerke, insbesondere die Fern-Knoten-CIDRs, sind die IP-Bereiche, die den Rechnern zugewiesen sind, die Sie als Hybridknoten verwenden. Wenn Sie Hybridknoten bereitstellen, befinden sich diese in Ihrem On-Premises-Rechenzentrum oder Edge-Standort, der sich in einer anderen Netzwerk-Domain als die EKS-Steuerebene und die VPC befindet. Jeder Hybridknoten verfügt über eine oder mehrere IP-Adressen aus einem Fern-Knoten-CIDR, der sich von den Subnetzen in Ihrer VPC unterscheidet.
Sie konfigurieren den EKS-Cluster mit diesen Fern-Knoten-CIDRs, damit EKS den gesamten für die IPs der Hybridknoten bestimmten Datenverkehr über Ihr Cluster-VPC weiterleiten kann, z. B. Anfragen an die Kubelet-API.
Fern-Pod-Netzwerke
Die Fern-Pod-Netzwerke sind die IP-Adressbereiche, die den Pods zugewiesen sind, die in Hybridknoten ausgeführt werden. In der Regel konfigurieren Sie Ihr CNI mit diesen Bereichen, und die IP-Adressverwaltungsfunktion (IPAM) des CNI übernimmt die Zuweisung eines Teils dieser Segmente zu jedem Hybridknoten. Wenn Sie einen Pod erstellen, weist das CNI dem Pod eine IP-Adresse aus dem Segment zu, das dem Knoten zugewiesen wurde, auf dem der Pod geplant wurde.
Sie konfigurieren den EKS-Cluster mit diesen Fern-Pod-CIDRs, damit die EKS-Steuerebene den gesamten Datenverkehr, der für die auf den Hybridknoten ausgeführten Pods bestimmt ist, über die VPC Ihres Clusters leiten muss, z. B. die Kommunikation mit Webhooks.
On-premises zur VPC
Das On-Premises-Netzwerk, das Sie für Hybridknoten verwenden, muss an die VPC weiterleiten, die Sie für Ihren EKS-Cluster verwenden. Es stehen mehrere Netzwerk-zu-Amazon-VPC-Konnektivitätsoptionen zur Verfügung, um Ihr On-Premises-Netzwerk mit einem VPC zu verbinden. Sie können auch Ihre eigene VPN-Lösung verwenden.
Es ist wichtig, dass Sie das Routing auf der AWS-Cloud-Seite in der VPC und in Ihrem On-Premises-Netzwerk korrekt konfigurieren, damit beide Netzwerke den richtigen Datenverkehr über die Verbindung für die beiden Netzwerke weiterleiten.
In der VPC muss der gesamte Datenverkehr, der an die Fern-Knoten- und Fern-Pod-Netzwerke geht, über die Verbindung zu Ihrem On-Premises-Netzwerk (als „Gateway“ bezeichnet) weitergeleitet werden. Wenn einige Ihrer Subnetze unterschiedliche Routen-Tabellen aufweisen, müssen Sie jede Routen-Tabelle mit den Routen für Ihre Hybridknoten und die darauf ausgeführten Pods konfigurieren. Dies gilt für die Subnetze, an welche die EKS-Steuerebenen-ENIs angefügt sind, sowie für Subnetze, die EC2-Knoten oder Pods enthalten, die mit Hybridknoten kommunizieren müssen.
In Ihrem On-Premises-Netzwerk müssen Sie Ihr Netzwerk so konfigurieren, dass der Datenverkehr zu und von der VPC Ihres EKS-Clusters und den anderen für Hybridknoten erforderlichen AWS-Services möglich ist. Der Datenverkehr für den EKS-Cluster durchläuft das Gateway in beide Richtungen.
Netzwerkbeschränkungen
Vollständig weitergeleitetes Netzwerk
Die wichtigste Einschränkung besteht darin, dass die EKS-Steuerebene und alle Knoten, Cloud- oder Hybridknoten, ein vollständig weitergeleitetes Netzwerk bilden müssen. Dies bedeutet, dass alle Knoten in der Lage sein müssen, sich gegenseitig auf Layer 3 über die IP-Adresse zu erreichen.
Die EKS-Steuerebene und die Cloud-Knoten sind bereits voneinander erreichbar, da sie sich in einem flachen Netzwerk (dem VPC) befinden. Die Hybridknoten befinden sich jedoch in einer anderen Netzwerk-Domain. Aus diesem Grund müssen Sie zusätzliches Routing in der VPC und in Ihrem On-Premises-Netzwerk konfigurieren, um den Datenverkehr zwischen den Hybridknoten und dem Rest des Clusters weiterzuleiten. Wenn die Hybridknoten untereinander und von der VPC aus erreichbar sind, können sich Ihre Hybridknoten in einem einzigen flachen Netzwerk oder in mehreren segmentierten Netzwerken befinden.
Routingfähige Fern-Pod-CIDRs
Damit die EKS-Steuerebene mit Pods kommunizieren kann, die in Hybridknoten ausgeführt werden (z. B. Webhooks oder der Metriken-Server), oder damit Pods, die auf Cloud-Knoten ausgeführt werden, mit Pods kommunizieren können, die in Hybridknoten ausgeführt werden (Ost-West-Kommunikation der Workloads), muss Ihr Fern-Pod-CIDR vom VPC aus routingfähig sein. Dies bedeutet, dass die VPC in der Lage sein muss, den Datenverkehr über das Gateway an die Pod-CIDRs Ihres On-Premises-Netzwerks weiterzuleiten, und dass Ihr On-Premises-Netzwerk den Datenverkehr für einen Pod an den richtigen Knoten weiterleiten muss.
Es ist wichtig, den Unterschied zwischen den Pod-Routing-Anforderungen im VPC und On-Premises zu beachten. Die VPC muss lediglich wissen, dass der gesamte Datenverkehr, der an einen Fern-Pod gesendet wird, über das Gateway geleitet werden soll. Wenn Sie nur über eine Fern-Pod-CIDR verfügen, benötigen Sie nur eine Route.
Diese Anforderung gilt für alle Hops in Ihrem On-Premises-Netzwerk bis zum lokalen Router im selben Subnetz wie Ihre Hybridknoten. Dies ist der einzige Router, der den jedem Knoten zugewiesenen Pod-CIDR-Segment kennen muss, um sicherzustellen, dass der Datenverkehr für einen bestimmten Pod an den Knoten übermittelt wird, für den der Pod geplant wurde.
Sie können diese Routen für die On-Premises-Pod-CIDRs von Ihrem On-Premises-Router an die VPC-Routing-Tabellen weiterleiten, dies ist jedoch nicht zwingend erforderlich. Wenn sich Ihre On-Premises-Pod-CIDRs regelmäßig ändern und Ihre VPC-Routing-Tabellen aktualisiert werden müssen, um die geänderten Pod-CIDRs widerzuspiegeln, empfehlen wir, die On-Premises-Pod-CIDRs an die VPC-Routing-Tabellen weiterzugeben. Dies ist jedoch eher selten der Fall.
Beachten Sie, dass die Einschränkung, Ihre On-Premises-Pod-CIDRs routingfähig zu machen, optional ist. Wenn Sie keine Webhooks in Ihren Hybridknoten ausführen müssen oder Pods auf Cloud-Knoten mit Pods in Hybridknoten kommunizieren müssen, ist es nicht erforderlich, das Routing für die Pod-CIDRs in Ihrem On-Premises-Netzwerk zu konfigurieren.
Warum müssen die On-Premises-Pod-CIDRs mit Hybridknoten routingfähig sein?
Bei der Verwendung von EKS mit VPC CNI für Ihre Cloud-Knoten weist VPC CNI den Pods IP-Adressen direkt aus der VPC zu. Dies bedeutet, dass kein spezielles Routing erforderlich ist, da sowohl Cloud-Pods als auch die EKS-Steuerebene die Pod-IPs direkt erreichen können.
Bei der Ausführung On-Premises (und mit anderen CNIs in der Cloud) werden die Pods in der Regel in einem isolierten Überlagerungsnetzwerk ausgeführt, und das CNI übernimmt die Übertragung des Datenverkehrs zwischen den Pods. Dies geschieht in der Regel durch Kapselung: Das CNI wandelt den Datenverkehr zwischen Pods in Datenverkehr zwischen Knoten um und übernimmt die Kapselung und Entkapselung an beiden Enden. Auf diese Weise sind keine zusätzlichen Konfigurationen an den Knoten und Routern erforderlich.
Die Vernetzung mit Hybridknoten ist einzigartig, da sie eine Kombination beider Topologien darstellt – die EKS-Steuerebene und die Cloud-Knoten (mit dem VPC CNI) erwarten ein flaches Netzwerk einschließlich Knoten und Pods, während die in Hybridknoten ausgeführten Pods sich in einem Überlagerungsnetzwerk befinden, das VXLAN für die Kapselung verwendet (standardmäßig in Cilium). In Hybridknoten ausgeführte Pods können die EKS-Steuerebene erreichen, und auf Cloudknoten ausgeführte Pods können dies erreichen, vorausgesetzt, das On-Premises-Netzwerk kann zum VPC weiterleiten. Ohne Routing für die Pod-CIDRs im On-Premises-Netzwerk wird jedoch jeglicher Datenverkehr, der zu einer On-Premises-Pod-IP zurückkehrt, letztendlich verworfen, wenn das Netzwerk nicht weiß, wie es das Überlagerungsnetzwerk erreichen und zu den richtigen Knoten weiterleiten soll.
