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.
In diesem Abschnitt werden die wichtigsten Netzwerkkonzepte und die Einschränkungen beschrieben, die Sie beim Entwurf Ihrer Netzwerktopologie für EKS-Hybridknoten berücksichtigen müssen.
Netzwerkkonzepte für EKS-Hybridknoten
VPC als Netzwerk-Hub
Der gesamte Datenverkehr, der die Cloud-Grenze überschreitet, fließt durch Ihre VPC. Dazu gehört der Verkehr zwischen der EKS-Steuerebene oder den Pods, die in diesen ausgeführt werden AWS , und Hybridknoten oder Pods, die auf ihnen ausgeführt werden. Sie können sich die VPC Ihres Clusters als Netzwerkhub zwischen Ihren Hybridknoten und dem Rest des Clusters vorstellen. Diese Architektur gibt Ihnen die volle Kontrolle über den Datenverkehr und sein Routing, aber Sie sind auch dafür verantwortlich, Routen, Sicherheitsgruppen und Firewalls für die VPC korrekt zu konfigurieren.
EKS-Steuerebene zur VPC
Die EKS-Steuerebene verbindet Elastic Network Interfaces (ENIs) mit Ihrer VPC. Diese ENIs verarbeiten den Verkehr zum und vom EKS-API-Server. Sie steuern die Platzierung der EKS-Steuerungsebene ENIs bei der Konfiguration Ihres Clusters, da EKS eine Verbindung ENIs zu den Subnetzen herstellt, die Sie bei der Clustererstellung übergeben.
EKS ordnet Sicherheitsgruppen den Gruppen zu ENIs , die EKS Ihren Subnetzen anhängt. Diese Sicherheitsgruppen ermöglichen den Verkehr zur und von der EKS-Steuerebene über die. ENIs Dies ist wichtig für EKS-Hybridknoten, da Sie den Datenverkehr von den Hybridknoten und den darauf laufenden Pods zur EKS-Steuerebene zulassen müssen ENIs.
Netzwerke mit Remote-Knoten
Die Remote-Knoten-Netzwerke, insbesondere der Remote-Knoten CIDRs, sind die Bereiche, die den Maschinen IPs zugewiesen sind, die Sie als Hybridknoten verwenden. Wenn Sie Hybridknoten bereitstellen, befinden sie sich in Ihrem lokalen Rechenzentrum oder Edge-Standort, bei dem es sich um eine andere Netzwerkdomäne als die EKS-Steuerebene und die VPC handelt. Jeder Hybridknoten hat eine IP-Adresse oder Adressen von einem Remote-Knoten-CIDR, der sich von den Subnetzen in Ihrer VPC unterscheidet.
Sie konfigurieren den EKS-Cluster mit diesen Remote-Knoten, CIDRs sodass EKS den gesamten für die Hybridknoten bestimmten Datenverkehr IPs über Ihre Cluster-VPC weiterleiten kann, z. B. Anfragen an die Kubelet-API.
Remote-Pod-Netzwerke
Die Remote-Pod-Netzwerke sind die Bereiche, die den Pods IPs zugewiesen sind, die auf den Hybridknoten ausgeführt werden. Im Allgemeinen konfigurieren Sie Ihr CNI mit diesen Bereichen, und die IP-Adressverwaltungsfunktion (IPAM) des CNI sorgt dafür, dass jedem Hybridknoten ein Teil dieser Bereiche zugewiesen wird. Wenn Sie einen Pod erstellen, weist das CNI dem Pod eine IP aus dem Slice zu, der dem Knoten zugewiesen ist, für den der Pod geplant wurde.
Sie konfigurieren den EKS-Cluster mit diesen Remote-Pods, CIDRs sodass die EKS-Steuerebene weiß, dass sie den gesamten Datenverkehr, der für die Pods bestimmt ist, die auf den Hybridknoten ausgeführt werden, über die VPC Ihres Clusters weiterleitet, z. B. die Kommunikation mit Webhooks.
Lokal zur VPC
Das lokale Netzwerk, das Sie für Hybridknoten verwenden, muss zu der VPC weitergeleitet werden, die Sie für Ihren EKS-Cluster verwenden. Es stehen mehrere Network-to-Amazon VPC-Konnektivitätsoptionen zur Verfügung, um Ihr lokales Netzwerk mit einer 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 lokalen Netzwerk korrekt konfigurieren, sodass beide Netzwerke den richtigen Datenverkehr über die Verbindung für die beiden Netzwerke weiterleiten.
In der VPC muss der gesamte Datenverkehr, der zu den Remote-Knoten- und Remote-Pod-Netzwerken fließt, über die Verbindung zu Ihrem lokalen Netzwerk (als „Gateway“ bezeichnet) geleitet werden. Wenn einige Ihrer Subnetze unterschiedliche Routing-Tabellen haben, müssen Sie jede Routing-Tabelle mit den Routen für Ihre Hybridknoten und die darauf ausgeführten Pods konfigurieren. Dies gilt für die Subnetze, an die die EKS-Steuerebene ENIs angeschlossen ist, und für Subnetze, die EC2 Knoten oder Pods enthalten, die mit Hybridknoten kommunizieren müssen.
In Ihrem lokalen Netzwerk müssen Sie Ihr Netzwerk so konfigurieren, dass der Verkehr zur und von der VPC Ihres EKS-Clusters und den anderen für Hybridknoten erforderlichen AWS Diensten zugelassen wird. Der Datenverkehr für den EKS-Cluster durchquert das Gateway in beide Richtungen.
Netzwerkeinschränkungen
Vollständig geroutetes Netzwerk
Die Haupteinschränkung besteht darin, dass die EKS-Steuerebene und alle Knoten, Cloud- oder Hybridknoten, ein vollständig geroutetes Netzwerk bilden müssen. Das bedeutet, dass alle Knoten in der Lage sein müssen, einander auf Ebene drei über ihre IP-Adresse zu erreichen.
Die EKS-Kontrollebene und die Cloud-Knoten sind bereits voneinander erreichbar, da sie sich in einem flachen Netzwerk (der VPC) befinden. Die Hybridknoten befinden sich jedoch in einer anderen Netzwerkdomäne. Aus diesem Grund müssen Sie zusätzliches Routing in der VPC und in Ihrem lokalen Netzwerk konfigurieren, um den Verkehr zwischen den Hybridknoten und dem Rest des Clusters weiterzuleiten. Wenn die Hybridknoten voneinander und von der VPC aus erreichbar sind, können sich Ihre Hybridknoten in einem einzigen flachen Netzwerk oder in mehreren segmentierten Netzwerken befinden.
Routbarer Remote-Pod CIDRs
Damit die EKS-Steuerebene mit Pods kommunizieren kann, die auf Hybridknoten ausgeführt werden (z. B. Webhooks oder der Metrics Server), oder für Pods, die auf Cloud-Knoten laufen, mit Pods kommunizieren können, die auf Hybridknoten ausgeführt werden (Workload-Ost-West-Kommunikation), muss Ihr Remote-Pod-CIDR von der VPC aus routbar sein. Das bedeutet, dass die VPC in der Lage sein muss, den Datenverkehr zum Pod CIDRs über das Gateway zu Ihrem lokalen Netzwerk weiterzuleiten, und dass Ihr lokales Netzwerk in der Lage sein muss, den Datenverkehr für einen Pod an den richtigen Knoten weiterzuleiten.
Es ist wichtig, den Unterschied zwischen den Pod-Routing-Anforderungen in der VPC und den lokalen Anforderungen zu beachten. Die VPC muss nur wissen, dass der gesamte Datenverkehr, der zu einem Remote-Pod fließt, das Gateway passieren sollte. Wenn Sie nur einen Remote-Pod-CIDR haben, benötigen Sie nur eine Route.
Diese Anforderung gilt für alle Hops in Ihrem lokalen Netzwerk bis hin zum lokalen Router im selben Subnetz wie Ihre Hybridknoten. Dies ist der einzige Router, der den Pod-CIDR-Slice kennen muss, der jedem Knoten zugewiesen ist, um sicherzustellen, dass der Datenverkehr für einen bestimmten Pod an den Knoten weitergeleitet wird, für den der Pod geplant wurde.
Sie können diese Routen für den lokalen Pod CIDRs von Ihrem lokalen Router an die VPC-Routentabellen weitergeben, dies ist jedoch nicht erforderlich. Wenn sich Ihr lokaler Pod häufig CIDRs ändert und Ihre VPC-Routing-Tabellen aktualisiert werden müssen, um den sich ändernden Pod widerzuspiegeln CIDRs, empfehlen wir, den lokalen Pod an die VPC-Routing-Tabellen CIDRs weiterzugeben. Dies ist jedoch ungewöhnlich.
Beachten Sie, dass die Einschränkung, Ihren lokalen Pod routingfähig zu machen, optional ist. CIDRs Wenn Sie keine Webhooks auf Ihren Hybridknoten ausführen oder Pods auf Cloud-Knoten nicht mit Pods auf Hybridknoten kommunizieren lassen müssen, müssen Sie das Routing für den Pod in CIDRs Ihrem lokalen Netzwerk nicht konfigurieren.
Warum muss der lokale Pod mit CIDRs Hybridknoten routingfähig sein?
Wenn Sie EKS mit dem VPC-CNI für Ihre Cloud-Knoten verwenden, weist das VPC-CNI den Pods IPs direkt von der VPC zu. Das bedeutet, dass kein spezielles Routing erforderlich ist, da sowohl Cloud-Pods als auch die EKS-Steuerebene den Pod direkt erreichen können. IPs
Bei der Ausführung vor Ort (und mit anderen CNIs in der Cloud) werden die Pods normalerweise in einem isolierten overlay Netzwerk ausgeführt, und das CNI kümmert sich um die Übertragung des Datenverkehrs zwischen den Pods. Dies erfolgt üblicherweise durch Kapselung: Das CNI wandelt den Datenverkehr in pod-to-pod Datenverkehr um und kümmert sich dabei um die Kapselung und Entkapselung an beiden Enden. node-to-node Auf diese Weise ist keine zusätzliche Konfiguration der Knoten (anhand der IP-Adresse) und der Router erforderlich.
Die Vernetzung mit Hybridknoten ist einzigartig, da sie eine Kombination aus beiden Topologien darstellt — die EKS-Kontrollebene und die Cloud-Knoten (mit dem VPC-CNI) erwarten ein flaches Netzwerk mit Knoten und Pods, während sich die Pods, die auf Hybridknoten laufen, in einem Overlay-Netzwerk befinden, das VXLAN zur Kapselung verwendet (standardmäßig in Cilium). Pods, die auf Hybridknoten ausgeführt werden, können die EKS-Steuerebene erreichen und Pods, die auf Cloud-Knoten ausgeführt werden, vorausgesetzt, das lokale Netzwerk kann zur VPC weiterleiten. Ohne Routing für den Pod CIDRs im lokalen Netzwerk wird jedoch jeglicher Datenverkehr, der zu einer lokalen Pod-IP zurückkehrt, irgendwann unterbrochen, wenn das Netzwerk nicht weiß, wie es das Overlay-Netzwerk erreichen und zu den richtigen Knoten weiterleiten kann.
