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.
Abläufe des Netzwerk-Datenverkehrs für Hybridknoten
Diese Seite enthält detaillierte Informationen zu den Abläufen für Netzwerk-Datenverkehr für EKS-Hybridknoten mit Diagrammen, welche die durchgehenden Netzwerkpfade für die verschiedenen Datenverkehrstypen darstellen.
Die folgenden Datenverkehr-Abläufe werden abgedeckt:
Hybridknoten kubelet zur EKS-Steuerebene
Anforderung
1kubelet. Initiiert Anforderung
Wenn kubelet auf einem Hybridknoten mit der EKS-Steuerebene kommunizieren muss (z. B. um den Knotenstatus zu melden oder Pod-Spezifikationen abzurufen), verwendet es die während der Knotenregistrierung bereitgestellte kubeconfig-Datei. Dieses kubeconfig hat die URL des API-Server-Endpunkts (den Route53-DNS-Namen) und keine direkten IP-Adressen.
Das kubelet führt eine DNS-Suche für den Endpunkt durch (z. B.
https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com). In einem Cluster mit öffentlichem Zugriff wird daraus eine öffentliche IP-Adresse (z. B. 54.239.118.52) abgeleitet, die zum in AWS ausgeführten EKS-Service gehört. kubelet erstellt dann eine sichere HTTPS-Anfrage an diesen Endpunkt. Das ursprüngliche Paket sieht folgendermaßen aus:
+--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 52390 (random) | | | Dst: 54.239.118.52 | Dst: 443 | | +--------------------+---------------------+-----------------+
2. Lokales Router-Routing
Da es sich bei der Ziel-IP um eine öffentliche IP-Adresse handelt und sie nicht Teil des lokalen Netzwerks ist, sendet kubelet dieses Paket an sein Standard-Gateway (den On-Premises-Router vor Ort). Der Router prüft die Ziel-IP und stellt fest, dass es sich um eine öffentliche IP-Adresse handelt.
Bei öffentlichem Datenverkehr leitet der Router das Paket normalerweise an ein Internet-Gateway oder einen Border-Router weiter, der den ausgehenden Datenverkehr ins Internet abwickelt. Dies ist im Diagramm nicht dargestellt und hängt von der Konfiguration Ihres On-Premises-Netzwerks ab. Das Paket durchläuft Ihre On-Premises-Netzwerkinfrastruktur und erreicht schließlich das Netzwerk Ihres Internet-Serviceanbieters.
3. Übermittlung an die EKS-Steuerebene
Das Paket wird über das öffentliche Internet und Transitnetzwerke übertragen, bis es das Netzwerk von AWS erreicht. Das Netzwerk von AWS leitet das Paket an den EKS-Service-Endpunkt in der entsprechenden Region weiter. Wenn das Paket den EKS-Service erreicht, wird es an die eigentliche EKS-Steuerebene für Ihren Cluster weitergeleitet.
Dieses Routing über das öffentliche Internet unterscheidet sich vom privaten VPC-weitergeleiteten Pfad, den wir in anderen Datenverkehrsabläufen sehen werden. Der Hauptunterschied besteht darin, dass im öffentlichen Zugriffsmodus der Datenverkehr von On-Premises-kubelet (jedoch nicht von Pods) zur EKS-Steuerebene nicht über Ihre VPC läuft, sondern stattdessen die globale Internetinfrastruktur verwendet.
Antwort
Nachdem die EKS-Steuerebene die kubelet-Anfrage verarbeitet hat, sendet sie eine Antwort zurück:
3. EKS-Steuerebene sendet Antwort
Die EKS-Steuerebene erstellt ein Antwortpaket. Dieses Paket hat die öffentliche IP als Quelle und die IP des Hybridknotens als Ziel:
+--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 54.239.118.52 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 52390 | | +--------------------+---------------------+-----------------+
2. Internet-Routing
Das Antwortpaket wird über das Internet zurückgesendet und folgt dabei dem von den Internet-Serviceanbietern festgelegten Routing-Pfad, bis es Ihren On-Premises-Netzwerk-Edge-Router erreicht.
1. Lokale Übermittlung
Ihr On-Premises-Router empfängt das Paket und erkennt die Ziel-IP (10.80.0.2) als zu Ihrem lokalen Netzwerk gehörig. Er leitet das Paket über Ihre lokale Netzwerkinfrastruktur weiter, bis es den Ziel-Hybridknoten erreicht, wo es von kubelet empfangen und verarbeitet wird.
Hybridknoten kube-proxy zur EKS-Steuerebene
Wenn Sie den öffentlichen Endpunktzugriff für den Cluster aktivieren, wird für den Rück-Datenverkehr das öffentliche Internet verwendet. Dieser Datenverkehr stammt vom kube-proxy auf dem Hybridknoten zur EKS-Steuerebene und folgt dem gleichen Pfad wie der Datenverkehr vom kubelet zur EKS-Steuerebene.
EKS-Steuerebene zum Hybridknoten (kubelet-Server)
Anforderung
1. EKS-Kubernetes-API-Server initiiert Anfrage
Der EKS-Kubernetes-API-Server ruft die IP-Adresse (10.80.0.2) des Knotens aus dem Status des Knotenobjekts ab. Anschließend leitet er diese Anfrage über seine ENI in der VPC weiter, da die Ziel-IP zum konfigurierten CIDR (10.80.0.0/16) des Knotens aus der Ferne gehört. Das ursprüngliche Paket sieht folgendermaßen aus:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 67493 (random) | | | Dst: 10.80.0.2 | Dst: 10250 | | +-----------------+---------------------+-----------------+
2. VPC-Netzwerkverarbeitung
Das Paket verlässt die ENI und gelangt in die VPC- Netzwerkebene, wo es zur weiteren Weiterleitung an das Gateway des Subnetzes weitergeleitet wird.
3. Abfrage der VPC-Routing-Tabelle
Die VPC-Routing-Tabelle für das Subnetz, das die EKS-Steuerebene ENI enthält, verfügt über eine bestimmte Route (die zweite im Diagramm) für den CIDR des Knotens aus der Ferne. Basierend auf dieser Routing-Regel wird das Paket an das VPC-zu-On-Prem-Gateway weitergeleitet.
4. Grenzüberschreitender Transit
Das Gateway überträgt das Paket über die Cloud-Grenze hinweg über Ihre vorhandene Verbindung (z. B. Direct Connect oder VPN) an Ihr On-Premises-Netzwerk.
5. On-Premises-Netzwerkempfang
Das Paket wird an Ihren On-Premises-Router vor Ort weitergeleitet, der den Datenverkehr für das Subnetz verwaltet, in dem sich Ihre Hybridknoten befinden.
6. Endgültige Übermittlung
Der lokale Router erkennt, dass die Ziel IP (10.80.0.2)-Adresse zu seinem direkt verbundenen Netzwerk gehört, und leitet das Paket direkt an den Ziel-Hybridknoten weiter, wo kubelet die Anfrage empfängt und verarbeitet.
Antwort
Nachdem das kubelet des Hybridknotens die Anfrage verarbeitet hat, sendet er eine Antwort auf dem gleichen Weg in umgekehrter Richtung zurück:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 10250 | | | Dst: 10.0.0.132 | Dst: 67493 | | +-----------------+---------------------+-----------------+
6. kubelet Sendet Antwort
Das kubelet auf dem Hybridknoten (10.80.0.2) erstellt ein Antwortpaket mit der ursprünglichen Quell-IP als Ziel. Das Ziel gehört nicht zum lokalen Netzwerk, daher wird es an das Standard-Gateway des Hosts gesendet, das der lokale Router ist.
5. Lokales Router-Routing
Der Router stellt fest, dass die Ziel-IP (10.0.0.132) zu 10.0.0.0/16 gehört, das über eine Route verfügt, die auf das Gateway zeigt, das mit AWS verbunden ist.
4. Grenzüberschreitende Rückgabe
Das Paket wird über dieselbe On-Premises-VPC-Verbindung (z. B. Direct Connect oder VPN) zurückgesendet und durchquert die Cloud-Grenze in umgekehrter Richtung.
3. VPC-Routing
Wenn das Paket in der VPC ankommt, erkennen die Routing-Tabellen, dass die Ziel-IP zu einer VPC-CIDR gehört. Das Paket wird innerhalb der VPC weitergeleitet.
2. VPC-Netzwerkzustellung
Die VPC-Netzwerkschicht leitet das Paket an das Subnetz mit der EKS-Steuerebene ENI (10.0.0.132) weiter.
1. ENI-Empfang
Das Paket erreicht die EKS-Steuerebene ENI, die an den Kubernetes-API-Server angefügt ist, und schließt damit den Rundlauf ab.
Pods, die in Hybridknoten zur EKS-Steuerebene ausgeführt werden
Ohne CNI NAT
Anforderung
Pods kommunizieren in der Regel über den kubernetes-Service mit dem Kubernetes-API-Server. Die Service-IP ist die erste IP-Adresse des CIDR-Adressbereichs des Clusters. Diese Konvention ermöglicht es Pods, die vor der Verfügbarkeit von CoreDNS ausgeführt werden müssen, den API-Server zu erreichen, beispielsweise das CNI. Anfragen verlassen den Pod mit der Service-IP als Ziel. Wenn beispielsweise die CIDR des Services 172.16.0.0/16 ist, lautet die IP-Adresse des Services 172.16.0.1.
1. Pod initiiert Anfrage
Der Pod sendet von einem zufälligen Quell-Port eine Anfrage an die kubernetes-Service-IP (172.16.0.1) auf dem API-Server-Port (443). Das Paket sieht wie folgt aus:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+
2. CNI-Verarbeitung
Das CNI erkennt, dass die Ziel-IP zu keinem von ihm verwalteten Pod-CIDR gehört. Da ausgehendes NAT deaktiviert ist, leitet das CNI das Paket unverändert an den Host-Netzwerk-Stack weiter.
3. Knoten-Netzwerkverarbeitung
Das Paket gelangt in den Netzwerk-Stack des Knotens, wo netfilter-Hooks die vom Kube-Proxy festgelegten iptables-Regeln auslösen. Es gelten mehrere Regeln in der folgenden Reihenfolge:
-
Das Paket erreicht zunächst die
KUBE-SERVICES-Kette, die Regeln enthält, die mit der ClusterIP und dem Port jedes Services übereinstimmen. -
Die übereinstimmende Regel springt zur
KUBE-SVC-XXX-Kette für denkubernetes-Service (Pakete mit dem Ziel für172.16.0.1:443), die Regeln zum Load Balancing enthält. -
Die Load-Balancing-Regel wählt zufällig eine der
KUBE-SEP-XXX-Ketten für die ENI-IPs der Steuerebene (10.0.0.132or10.0.1.23). -
Die ausgewählte
KUBE-SEP-XXX-Kette verfügt über die eigentliche Regel, welche die Ziel-IP von der Service-IP in die ausgewählte IP ändert. Dies wird als Destination Network Address Translation (DNAT) bezeichnet.
Nachdem diese Regeln angewendet wurden, sieht das Paket wie folgt aus, vorausgesetzt, dass die IP der ausgewählten EKS-Steuerebene ENI 10.0.0.132 ist:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+
Der Knoten leitet das Paket an sein Standard-Gateway weiter, da sich die Ziel-IP nicht im lokalen Netzwerk befindet.
4. Lokales Router-Routing
Der lokale Router stellt fest, dass die Ziel-IP (10.0.0.132) zur VPC-CIDR (10.0.0.0/16) gehört, und leitet sie an das Gateway weiter, das mit AWS verbunden ist.
5. Grenzüberschreitender Transit
Das Paket wird über Ihre eingerichtete Verbindung (z. B. Direct Connect oder VPN) über die Cloud-Grenze hinweg an die VPC weitergeleitet.
6. VPC-Netzwerkzustellung
Die VPC-Netzwerkebene leitet das Paket an das richtige Subnetz weiter, in dem sich die EKS-Steuerebene ENI (10.0.0.132) befindet.
7. ENI-Empfang
Das Paket erreicht die EKS-Steuerebene ENI, die an den Kubernetes-API-Server angefügt ist.
Antwort
Nachdem die EKS-Steuerebene die Anfrage verarbeitet hat, sendet sie eine Antwort zurück an den Pod:
7. API-Server übermittelt Antwort
Der EKS-Kubernetes-API-Server erstellt ein Antwortpaket mit der ursprünglichen Quell-IP als Ziel. Das Paket sieht wie folgt aus:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+
Da die Ziel-IP zum konfigurierten Fern-Pod-CIDR (10.85.0.0/16) gehört, sendet sie diese über ihre ENI in der VPC mit dem Router des Subnetzes als nächstem Hop.
6. VPC-Routing
Die VPC-Routing-Tabelle enthält einen Eintrag für die Fern-Pod-CIDR (10.85.0.0/16), der diesen Datenverkehr an das VPC-zu-On-Premises-Gateway weiterleitet.
5. Grenzüberschreitender Transit
Das Gateway überträgt das Paket über die Cloud-Grenze hinweg über Ihre vorhandene Verbindung (z. B. Direct Connect oder VPN) an Ihr On-Premises-Netzwerk.
4. On-Premises-Netzwerkempfang
Das Paket erreicht Ihren lokalen On-Premises-Router.
3. Zustellung an den Knoten
Die Tabelle des Routers enthält einen Eintrag für 10.85.1.0/24 mit 10.80.0.2 als nächstem Hop, wodurch das Paket an unseren Knoten übermittelt wird.
2. Knoten-Netzwerkverarbeitung
Während das Paket vom Netzwerk-Stack des Knotens verarbeitet wird, ordnet conntrack (ein Teil von netfilter) das Paket der Verbindung zu, die der Pod ursprünglich hergestellt hat. Da ursprünglich DNAT angewendet wurde, kehrt conntrack das DNAT um, indem die Quell-IP von der IP der ENI der EKS-Steuerebene in die kubernetes-Service-IP umgeschrieben wird:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+
1. CNI-Verarbeitung
Das CNI erkennt, dass die Ziel-IP zu einem Pod in seinem Netzwerk gehört, und liefert das Paket an den richtigen Pod-Netzwerk-Namespace.
Dieser Ablauf zeigt, warum Fern-Pod-CIDRs vom VPC bis zum jeweiligen Knoten, auf dem sich der jeweilige Pod befindet, ordnungsgemäß routingfähig sein müssen. Der gesamte Rückweg hängt vom ordnungsgemäßen Routing der Pod-IPs über Cloud- und On-Premises-Netzwerke ab.
Mit CNI NAT
Dieser Ablauf ist dem ohne CNI NAT sehr ähnlich, jedoch mit einem wesentlichen Unterschied: Das CNI wendet Source NAT (SNAT) auf das Paket an, bevor es an den Netzwerk-Stack des Knotens gesendet wird. Dadurch wird die Quell-IP des Pakets in die IP des Knotens geändert, sodass das Paket ohne zusätzliche Routing-Konfiguration zurück zum Knoten geleitet werden kann.
Anforderung
1. Pod initiiert Anfrage
Der Pod sendet von einem zufälligen Quell-Port eine Anfrage an die kubernetes-Service-IP (172.16.0.1) auf dem EKS-Kubernetes-API-Server-Port (443). Das Paket sieht wie folgt aus:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+
2. CNI-Verarbeitung
Das CNI erkennt, dass die Ziel-IP zu keinem von ihm verwalteten Pod-CIDR gehört. Da ausgehendes NAT aktiviert ist, wendet das CNI SNAT auf das Paket an und ändert die Quell-IP in die IP des Knotens, bevor es an den Netzwerk-Stack des Knotens weitergeleitet wird:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+
Hinweis: CNI und iptables werden im Beispiel der Übersichtlichkeit halber als separate Blöcke angezeigt, in der Praxis ist es jedoch möglich, dass einige CNIs iptables verwenden, um NAT anzuwenden.
3. Knoten-Netzwerkverarbeitung
Hier verhalten sich die von kube-proxy festgelegten iptables-Regeln genauso wie im vorherigen Beispiel und verteilen die Last des Pakets auf eines der ENIs der EKS-Steuerebene. Das Paket sieht nun so aus:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+
Der Knoten leitet das Paket an sein Standard-Gateway weiter, da sich die Ziel-IP nicht im lokalen Netzwerk befindet.
4. Lokales Router-Routing
Der lokale Router stellt fest, dass die Ziel-IP (10.0.0.132) zur VPC-CIDR (10.0.0.0/16) gehört, und leitet sie an das Gateway weiter, das mit AWS verbunden ist.
5. Grenzüberschreitender Transit
Das Paket wird über Ihre eingerichtete Verbindung (z. B. Direct Connect oder VPN) über die Cloud-Grenze hinweg an die VPC weitergeleitet.
6. VPC-Netzwerkzustellung
Die VPC-Netzwerkebene leitet das Paket an das richtige Subnetz weiter, in dem sich die EKS-Steuerebene ENI (10.0.0.132) befindet.
7. ENI-Empfang
Das Paket erreicht die EKS-Steuerebene ENI, die an den Kubernetes-API-Server angefügt ist.
Antwort
Nachdem die EKS-Steuerebene die Anfrage verarbeitet hat, sendet sie eine Antwort zurück an den Pod:
7. API-Server übermittelt Antwort
Der EKS-Kubernetes-API-Server erstellt ein Antwortpaket mit der ursprünglichen Quell-IP als Ziel. Das Paket sieht wie folgt aus:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+
Da die Ziel-IP zum konfigurierten Fern-Knoten-CIDR (10.80.0.0/16) gehört, sendet sie diese über ihre ENI in der VPC mit dem Router des Subnetzes als nächstem Hop.
6. VPC-Routing
Die VPC-Routentabelle enthält einen Eintrag für den Fern-Knoten-CIDR (10.80.0.0/16), der diesen Datenverkehr an das VPC-zu-On-Premises-Gateway weiterleitet.
5. Grenzüberschreitender Transit
Das Gateway überträgt das Paket über die Cloud-Grenze hinweg über Ihre vorhandene Verbindung (z. B. Direct Connect oder VPN) an Ihr On-Premises-Netzwerk.
4. On-Premises-Netzwerkempfang
Das Paket erreicht Ihren lokalen On-Premises-Router.
3. Zustellung an den Knoten
Der lokale Router erkennt, dass die Ziel-IP-Adresse (10.80.0.2) zu seinem direkt verbundenen Netzwerk gehört, und leitet das Paket direkt an den Ziel-Hybridknoten weiter.
2. Knoten-Netzwerkverarbeitung
Während das Paket vom Netzwerkstack des Knotens verarbeitet wird, gleicht conntrack (ein Teil von netfilter) das Paket mit der ursprünglich vom Pod hergestellten Verbindung ab. Da ursprünglich DNAT angewendet wurde, wird dies rückgängig gemacht, indem die Quell-IP von der IP der EKS-Steuerebene ENI in die kubernetes-Service-IP umgeschrieben wird:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+
1. CNI-Verarbeitung
Das CNI identifiziert dieses Paket als Teil einer Verbindung, für die zuvor SNAT angewendet wurde. Es kehrt das SNAT um und ändert die Ziel-IP wieder in die IP des Pods:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+
Das CNI erkennt, dass die Ziel-IP zu einem Pod in seinem Netzwerk gehört, und liefert das Paket an den korrekten Pod-Netzwerk-Namespace.
Dieser Ablauf veranschaulicht, wie CNI NAT die Konfiguration vereinfachen kann, indem Pakete zurück zum Knoten geleitet werden können, ohne dass zusätzliches Routing für die Pod-CIDRs erforderlich ist.
EKS-Steuerebene für Pods, die in einem Hybridknoten ausgeführt werden (Webhooks)
Dieses Datenverkehrsmuster tritt am häufigsten bei Webhooks auf, bei denen die EKS-Steuerebene direkt Verbindungen zu Webhook-Servern herstellen muss, die in Pods auf Hybridknoten ausgeführt werden. Beispiele hierfür sind die Validierung und Mutation von Zulassungs-Webhooks, die vom API-Server während der Ressourcenvalidierung oder Mutationsprozesse aufgerufen werden.
Anforderung
1. EKS-Kubernetes-API-Server initiiert Anfrage
Wenn ein Webhook im Cluster konfiguriert ist und durch einen entsprechenden API-Vorgang ausgelöst wird, muss der EKS-Kubernetes-API-Server eine direkte Verbindung zum Webhook-Server-Pod herstellen. Der API-Server sucht zunächst die IP-Adresse des Pods aus der dem Webhook zugeordneten Service- oder Endpunkt-Ressource.
Vorausgesetzt, der Webhook-Pod wird in einem Hybridknoten mit IP 10.85.1.23 ausgeführt, erstellt der EKS-Kubernetes-API-Server eine HTTPS-Anfrage an den Webhook-Endpunkt. Das erste Paket wird über die EKS-Steuerebene ENI in Ihrem VPC gesendet, da die Ziel-IP 10.85.1.23 zum konfigurierten Fern-Pod-CIDR (10.85.0.0/16) gehört. Das Paket sieht wie folgt aus:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 41892 (random) | | | Dst: 10.85.1.23 | Dst: 8443 | | +-----------------+---------------------+-----------------+
2. VPC-Netzwerkverarbeitung
Das Paket verlässt die EKS-Steuerebene (ENI) und gelangt mit dem Router des Subnetzes als nächstem Hop in die VPC-Netzwerkebene.
3. Abfrage der VPC-Routing-Tabelle
Die VPC-Routing-Tabelle für das Subnetz, das die EKS-Steuerebene ENI enthält, enthält eine bestimmte Route für den Fern-Pod-CIDR (10.85.0.0/16). Diese Routing-Regel leitet das Paket an das VPC-zu-On-Premises-Gateway weiter (z. B. ein Virtual Private Gateway für Direct Connect- oder VPN-Verbindungen):
Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway)
4. Grenzüberschreitender Transit
Das Gateway überträgt das Paket über die Cloud-Grenze hinweg über Ihre vorhandene Verbindung (z. B. Direct Connect oder VPN) an Ihr On-Premises-Netzwerk. Das Paket behält seine ursprünglichen Quell- und Ziel-IP-Adressen bei, während es diese Verbindung durchläuft.
5. On-Premises-Netzwerkempfang
Das Paket erreicht Ihren lokalen On-Premises-Router. Der Router fragt seine Routing-Tabelle ab, um zu ermitteln, wie die Adresse 10.85.1.23 erreicht werden kann. Damit dies funktioniert, muss Ihr On-Premises-Netzwerk über Routen für die Pod-CIDRs verfügen, die den Datenverkehr an den entsprechenden Hybridknoten weiterleiten.
In diesem Fall enthält die Routing-Tabelle des Routers einen Eintrag, der angibt, dass das 10.85.1.0/24-Subnetz über den Hybridknoten mit der IP 10.80.0.2 erreichbar ist:
Destination Next Hop 10.85.1.0/24 10.80.0.2
6. Zustellung an den Knoten
Basierend auf dem Eintrag in der Routing-Tabelle leitet der Router das Paket an den Hybridknoten (10.80.0.2) weiter. Wenn das Paket am Knoten ankommt, sieht es genauso aus wie beim Versand durch den EKS-Kubernetes-API-Server, wobei die Ziel-IP weiterhin die IP des Pods ist.
7. CNI-Verarbeitung
Der Netzwerk-Stack des Knotens empfängt das Paket und leitet es zur Verarbeitung an das CNI weiter, da er erkennt, dass die Ziel-IP nicht die eigene IP des Knotens ist. Das CNI erkennt, dass die Ziel-IP zu einem Pod gehört, der lokal auf diesem Knoten ausgeführt wird, und leitet das Paket über die entsprechenden virtuellen Schnittstellen an den richtigen Pod weiter:
Original packet -> node routing -> CNI -> Pod's network namespace
Der Webhook-Server im Pod empfängt die Anfrage und verarbeitet sie.
Antwort
Nachdem der Webhook-Pod die Anfrage verarbeitet hat, sendet er eine Antwort zurück, die demselben Pfad in umgekehrter Reihenfolge folgt:
7. Pod sendet Antwort
Der Webhook-Pod erstellt ein Antwortpaket mit seiner eigenen IP-Adresse als Quelle und dem ursprünglichen Anforderer (der EKS-Steuerebenen-ENI) als Ziel:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.23 | Src: 8443 | | | Dst: 10.0.0.132 | Dst: 41892 | | +-----------------+---------------------+-----------------+
Das CNI erkennt, dass dieses Paket an ein externes Netzwerk (nicht an einen lokalen Pod) gesendet wird, und leitet das Paket unter Beibehaltung der ursprünglichen Quell-IP-Adresse an den Netzwerk-Stack des Knotens weiter.
6. Knoten-Netzwerkverarbeitung
Der Knoten stellt fest, dass sich die Ziel-IP (10.0.0.132) nicht im lokalen Netzwerk befindet, und leitet das Paket an sein Standard-Gateway (den lokalen Router) weiter.
5. Lokales Router-Routing
Der lokale Router fragt seine Routing-Tabelle ab und stellt fest, dass die Ziel-IP (10.0.0.132) zum VPC CIDR (10.0.0.0/16) gehört. Er leitet das Paket an das Gateway weiter, das eine Verbindung zu AWS herstellt.
4. Grenzüberschreitender Transit
Das Paket wird über dieselbe On-Premises-VPC-Verbindung zurückgesendet und durchquert die Cloud-Grenze in umgekehrter Richtung.
3. VPC-Routing
Wenn das Paket in der VPC ankommt, erkennen die Routing-Tabellen, dass die Ziel-IP zu einem Subnetz innerhalb der VPC gehört. Das Paket wird innerhalb der VPC entsprechend weitergeleitet.
2. und 1. ENI-Empfang der EKS-Steuerebene
Das Paket erreicht das ENI, das mit dem EKS-Kubernetes-API-Server verbunden ist, und schließt damit den Rundlauf ab. Der API-Server empfängt die Webhook-Antwort und setzt die Verarbeitung der ursprünglichen API-Anforderung basierend auf dieser Antwort fort.
Dieser Datenverkehrsablauf verdeutlicht, warum Fern-Pod-CIDRs ordnungsgemäß konfiguriert und weitergeleitet werden müssen:
-
Die VPC muss über Routen für die CIDRs der Fern-Pods verfügen, die auf das On-Premises-Gateway verweisen.
-
Ihr On-Premises-Netzwerk muss über Routen für Pod-CIDRs verfügen, die den Datenverkehr an die spezifischen Knoten weiterleiten, auf denen diese Pods gehostet werden
-
Ohne diese Routing-Konfiguration wären Webhooks und andere ähnliche Services, die in Pods auf Hybridknoten ausgeführt werden, von der EKS-Steuerebene aus nicht erreichbar.
Pod-zu-Pod-Ausführung auf Hybridknoten
In diesem Abschnitt wird erläutert, wie Pods, die in verschiedenen Hybridknoten ausgeführt werden, miteinander kommunizieren. In diesem Beispiel wird davon ausgegangen, dass Ihre CNI VXLAN für die Kapselung verwendet, was bei CNIs wie Cilium oder Calico üblich ist. Der Gesamtprozess ist bei anderen Kapselungsprotokollen wie Geneve oder IP-in-IP ähnlich.
Anforderung
1. Pod A initiiert die Kommunikation
Pod A (10.85.1.56) on Knoten 1 möchte Datenverkehr an Pod B (10.85.2.67) an Knoten 2 senden. Das ursprüngliche Paket sieht folgendermaßen aus:
+------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+
2. CNI fängt das Paket ab und verarbeitet es
Wenn das Paket von Pod A seinen Netzwerk-Namespace verlässt, wird es vom CNI abgefange Das CNI konsultiert seine Routing-Tabelle und stellt fest: – Die Ziel-IP (10.85.2.67) gehört zum Pod-CIDR. – Diese IP befindet sich nicht auf dem lokalen Knoten, sondern gehört zu Knoten 2 (10.80.0.3). – Das Paket muss mit VXLAN gekapselt werden.
Die Entscheidung zur Kapselung ist von entscheidender Bedeutung, da das zugrunde liegende physische Netzwerk nicht in der Lage ist, Pod-CIDRs direkt weiterzuleiten – es kann lediglich den Datenverkehr zwischen Knoten-IPs weiterleiten.
Das CNI kapselt das gesamte ursprüngliche Paket in einem VXLAN-Frame. Dadurch wird effektiv ein „Paket innerhalb eines Pakets“ mit neuen Headern erstellt:
+-----------------+----------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node1 MAC | Src: 10.80.0.2 | Src: Random | VNI: 42 | Packet (unchanged | | Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472 | | from above) | +-----------------+----------------+--------------+------------+---------------------------+
Wichtige Punkte zu dieser Kapselung: – Das äußere Paket ist von Knoten 1 (10.80.0.2) an Knoten 2 (10.80.0.3) adressiert. – Der UDP-Port 8472 ist der VXLAN-Port, den Cilium standardmäßig verwendet. – Die VXLAN-Netzwerk-ID (VNI) identifiziert, zu welchem Überlagerungsnetzwerk dieses Paket gehört. – Das gesamte Originalpaket (mit der IP-Adresse von Pod A als Quelle und der IP-Adresse von Pod B als Ziel) bleibt im Inneren unverändert
Das gekapselte Paket gelangt nun in den regulären Netzwerk-Stack von Knoten 1 und wird wie jedes andere Paket verarbeitet:
-
Knoten-Netzwerkverarbeitung: Der Netzwerk-Stack von Knoten 1 leitet das Paket basierend auf seinem Ziel weiter (
10.80.0.3) -
Bereitstellung im lokalen Netzwerk:
-
Wenn sich beide Knoten im selben Layer-2-Netzwerk befinden, wird das Paket direkt an Knoten 2 gesendet
-
Wenn sie sich in unterschiedlichen Subnetzen befinden, wird das Paket zuerst an den lokalen Router weitergeleitet
-
-
Router-Verarbeitung: Der Router leitet das Paket anhand seiner Routing-Tabelle weiter und übergibt es an Knoten 2
3. Verarbeitung des empfangenden Knotens
Wenn das gekapselte Paket bei Knoten 2 (10.80.0.3) ankommt:
-
Der Netzwerk-Stack des Knotens empfängt es und identifiziert es als VXLAN-Paket (UDP-Port
4789). -
Das Paket wird zur Verarbeitung an die VXLAN-Schnittstelle des CNI weitergeleitet
4. VXLAN-Entkapselung
Das CNI auf Knoten 2 verarbeitet das VXLAN-Paket:
-
Es entfernt die äußeren Header (Ethernet, IP, UDP und VXLAN).
-
Es extrahiert das ursprüngliche innere Paket
-
Das Paket hat nun wieder seine ursprüngliche Form:
+------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+
Das CNI auf Knoten 2 untersucht die Ziel-IP (10.85.2.67) und:
-
Identifiziert, dass diese IP zu einem lokalen Pod gehört
-
Leitet das Paket durch die entsprechenden virtuellen Schnittstellen
-
Liefert das Paket an den Netzwerk-Namespace von Pod B
Antwort
Wenn Pod B auf Pod A reagiert, verläuft der gesamte Prozess in umgekehrter Reihenfolge:
-
Pod B sendet ein Paket an Pod A (
10.85.1.56) -
Das CNI von Knoten 2 kapselt ihn mit VXLAN und legt das Ziel auf Knoten 1 (
10.80.0.2) fest -
Das gekapselte Paket wird an Knoten 1 übermittelt
-
Knoten 1 entkapselt die CNI und übermittelt die ursprüngliche Antwort an Pod A
Pods auf Cloud-Knoten zu Pods auf Hybridknoten (Ost-West–Datenverkehr)
Anforderung
1. Pod A initiiert die Kommunikation
Pod A (10.0.0.56) auf dem EC2-Knoten möchte Datenverkehr an Pod B (10.85.1.56) auf dem Hybridknoten senden. Das ursprüngliche Paket sieht folgendermaßen aus:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.56 | Src: 52390 (random) | | | Dst: 10.85.1.56 | Dst: 8080 | | +-----------------+---------------------+-----------------+
Mit dem VPC CNI verfügt Pod A über eine IP vom VPC CIDR und ist direkt mit einem ENI auf der EC2-Instance verbunden. Der Netzwerk-Namespace des Pods ist mit dem VPC-Netzwerk verbunden, sodass das Paket direkt in die VPC-Routing-Infrastruktur gelangt.
2. VPC-Routing
Die VPC-Routing-Tabelle enthält eine spezifische Route für die Fern-Pod-CIDR (10.85.0.0/16), die diesen Datenverkehr zum VPC-zu-On-Premises-Gateway weiterleitet:
Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway)
Basierend auf dieser Routing-Regel wird das Paket an das Gateway weitergeleitet, das mit Ihrem On-Premises-Netzwerk verbunden ist.
3. Grenzüberschreitender Transit
Das Gateway überträgt das Paket über die Cloud-Grenze hinweg über Ihre vorhandene Verbindung (z. B. Direct Connect oder VPN) an Ihr On-Premises-Netzwerk. Das Paket behält während der gesamten Übertragung seine ursprünglichen Quell- und Ziel-IP-Adressen bei.
4. On-Premises-Netzwerkempfang
Das Paket erreicht Ihren lokalen On-Premises-Router. Der Router fragt seine Routing-Tabelle ab, um den nächsten Hop zum Erreichen der Adresse 10.85.1.56 zu ermitteln. Ihr On-Premises-Router muss über Routen für die Pod-CIDRs verfügen, die den Datenverkehr an den entsprechenden Hybridknoten weiterleiten.
Die Tabelle des Routers enthält einen Eintrag, der angibt, dass das 10.85.1.0/24-Subnetz über den Hybridknoten mit der IP 10.80.0.2 erreichbar ist:
Destination Next Hop 10.85.1.0/24 10.80.0.2
5. Knoten-Netzwerkverarbeitung
Der Router leitet das Paket an den Hybridknoten weiter (10.80.0.2). Wenn das Paket am Knoten ankommt, enthält es weiterhin die IP-Adresse von Pod A als Quelle und die IP-Adresse von Pod B als Ziel.
6. CNI-Verarbeitung
Der Netzwerk-Stack des Knotens empfängt das Paket und leitet es, da die Ziel-IP-Adresse nicht seine eigene ist, zur Verarbeitung an das CNI weiter. Das CNI erkennt, dass die Ziel-IP zu einem Pod gehört, der lokal auf diesem Knoten ausgeführt wird, und leitet das Paket über die entsprechenden virtuellen Schnittstellen an den richtigen Pod weiter:
Original packet -> node routing -> CNI -> Pod B's network namespace
Pod B empfängt das Paket und verarbeitet es entsprechend den Anforderungen.
Antwort
6. Pod B sendet Antwort
Pod B erstellt ein Antwortpaket mit seiner eigenen IP als Quelle und der IP von Pod A als Ziel:
+-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 8080 | | | Dst: 10.0.0.56 | Dst: 52390 | | +-----------------+---------------------+-----------------+
Das CNI erkennt, dass dieses Paket für ein externes Netzwerk bestimmt ist, und leitet es an den Netz-Stack des Knotens weiter.
5. Knoten-Netzwerkverarbeitung
Der Knoten stellt fest, dass die Ziel-IP (10.0.0.56) nicht zum lokalen Netzwerk gehört und leitet das Paket an sein Standard-Gateway (den lokalen Router) weiter.
4. Lokales Router-Routing
Der lokale Router fragt seine Routing-Tabelle ab und stellt fest, dass die Ziel-IP (10.0.0.56) zum VPC CIDR (10.0.0.0/16) gehört. Er leitet das Paket an das Gateway weiter, das eine Verbindung zu AWS herstellt.
3. Grenzüberschreitender Transit
Das Paket wird über dieselbe On-Premises-VPC-Verbindung zurückgesendet und durchquert die Cloud-Grenze in umgekehrter Richtung.
2. VPC-Routing
Wenn das Paket in der VPC ankommt, erkennt das Routing-System, dass die Ziel-IP zu einem Subnetz innerhalb der VPC gehört. Das Paket wird über das VPC-Netzwerk an die EC2-Instance weitergeleitet, die Pod A hostet.
1. Pod A empfängt Antwort
Das Paket kommt bei der EC2-Instance an und wird über die zugehörige ENI direkt an Pod A weitergeleite Da die VPC CNI für Pods in der VPC kein Überlagerungsnetzwerk verwendet, ist keine zusätzliche Entkapselung erforderlich – das Paket kommt mit intakten Original-Headern an.
Dieser Ost-West-Datenverkehr verdeutlicht, warum Fern-Pod-CIDRs ordnungsgemäß konfiguriert und aus beiden Richtungen routingfähig sein müssen:
-
Die VPC muss über Routen für die CIDRs der Fern-Pods verfügen, die auf das On-Premises-Gateway verweisen.
-
Ihr On-Premises-Netzwerk muss über Routen für Pod-CIDRs verfügen, die den Datenverkehr an die spezifischen Knoten weiterleiten, auf denen diese Pods gehostet werden.
