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.
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. Dazu gehört der Verkehr zwischen der EKS-Steuerungsebene oder den Pods, die in AWS Hybridknoten oder Pods laufen, die auf ihnen ausgeführt werden. 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-Kontrollebene 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.
Fern-Knoten-Netzwerke
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 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 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. Die Verbindungen zur kubelet API werden in den Befehlenkubectl attach,, kubectl cpkubectl exec, kubectl logs und verwendet. kubectl port-forward
Fern-Pod-Netzwerke
Die Remote-Pod-Netzwerke sind die Bereiche, die den Pods IPs zugewiesen wurden, die auf den 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 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.
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 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 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 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 Datenverkehr 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 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.
Routbarer Remote-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. 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 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 sich dafür entscheiden, diese Routen für den lokalen Pod CIDRs von Ihrem lokalen Router an die VPC-Routentabellen weiterzugeben, dies ist jedoch nicht erforderlich. Wenn sich Ihr On-Premises-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 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 den Pod CIDRs im lokalen Netzwerk wird jedoch jeglicher Datenverkehr, der zu einer lokalen Pod-IP zurückkehrt, irgendwann verworfen, wenn das Netzwerk nicht weiß, wie es das Overlay-Netzwerk erreichen und zu den richtigen Knoten weiterleiten kann.
