混合節點kubelet到 EKS 控制平面混合節點kube-proxy到 EKS 控制平面 EKS 控制平面到混合節點 (kubelet 伺服器）在混合節點上執行的 Pod 到 EKS 控制平面在混合節點上執行的 EKS 控制平面到 Pod (webhooks)在混合節點上執行Pod-to-Pod 雲端節點上的 Pod 到混合節點上的 Pod （東西流量）

混合節點的網路流量流程

此頁面詳細說明 EKS 混合節點的網路流量流程，圖表顯示不同流量類型的end-to-end網路路徑。

涵蓋下列流量流程：

混合節點kubelet到 EKS 控制平面
EKS 控制平面到混合節點 (kubelet 伺服器）
在混合節點上執行的 Pod 到 EKS 控制平面
在混合節點上執行的 EKS 控制平面到 Pod (webhooks)
在混合節點上執行Pod-to-Pod
雲端節點上的 Pod 到混合節點上的 Pod （東西流量）

混合節點`kubelet`到 EKS 控制平面

請求

1kubelet. 啟動請求

當混合節點kubelet上的需要與 EKS 控制平面通訊時（例如，報告節點狀態或取得 Pod 規格），它會使用節點註冊期間提供的 kubeconfig 檔案。這kubeconfig具有 API 伺服器端點 URL (Route53 DNS 名稱），而不是直接 IP 地址。

會執行端點的 kubelet DNS 查詢（例如， https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com )。在公有存取叢集中，這會解析為屬於執行中 EKS 服務的公有 IP 地址（例如 54.239.118.52) AWS。kubelet 然後，會為此端點建立安全的 HTTPS 請求。初始封包如下所示：


+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 10.80.0.2     | Src: 52390 (random) |                 |
| Dst: 54.239.118.52 | Dst: 443            |                 |
+--------------------+---------------------+-----------------+

2. 本機路由器路由

由於目的地 IP 是公有 IP 地址，不屬於本機網路，因此 kubelet會將此封包傳送至其預設閘道（本機內部部署路由器）。路由器會檢查目的地 IP，並判斷其為公有 IP 地址。

對於公有流量，路由器通常會將封包轉送至處理傳出流量的網際網路閘道或邊界路由器。這在圖表中被省略，並取決於現場部署網路的設定方式。封包會周遊您的內部部署網路基礎設施，最終到達網際網路服務供應商的網路。

3. 交付至 EKS 控制平面

封包會通過公有網際網路和傳輸網路，直到到達 AWS網路。 AWS的網路會將封包路由到適當區域中的 EKS 服務端點。當封包到達 EKS 服務時，它會轉送到叢集的實際 EKS 控制平面。

透過公有網際網路的路由與我們在其他流量流程中看到的私有 VPC 路由路徑不同。主要差別在於，使用公有存取模式時，從內部部署 kubelet（雖然不是從 Pod) 到 EKS 控制平面的流量不會通過您的 VPC，而是使用全球網際網路基礎設施。

回應

在 EKS 控制平面處理kubelet請求後，它會傳送回應：

3. EKS 控制平面傳送回應

EKS 控制平面會建立回應封包。此封包具有公有 IP 做為來源，而混合節點的 IP 做為目的地：


+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 54.239.118.52 | Src: 443            |                 |
| Dst: 10.80.0.2     | Dst: 52390          |                 |
+--------------------+---------------------+-----------------+

2. 網際網路路由

回應封包會透過網際網路傳回，並遵循網際網路服務供應商決定的路由路徑，直到到達您的內部部署網路邊緣路由器為止。

1。本機交付

您的內部部署路由器會收到封包，並將目的地 IP (10.80.0.2) 識別為屬於您的本機網路。它會透過您的本機網路基礎設施轉送封包，直到它到達目標混合節點，會在其中kubelet接收和處理回應。

混合節點`kube-proxy`到 EKS 控制平面

如果您啟用叢集的公有端點存取，傳回流量會使用公有網際網路。此流量源自混合節點kube-proxy上的到 EKS 控制平面，並遵循與從 kubelet到 EKS 控制平面的流量相同的路徑。

EKS 控制平面到混合節點 (`kubelet` 伺服器）

請求

1。EKS Kubernetes API 伺服器啟動請求

EKS Kubernetes API 伺服器會從節點物件的狀態擷取節點的 IP 地址 (10.80.0.2)。然後，它會在 VPC 中透過其 ENI 路由此請求，因為目的地 IP 屬於設定的遠端節點 CIDR (10.80.0.0/16)。初始封包如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 67493 (random) |                 |
| Dst: 10.80.0.2  | Dst: 10250          |                 |
+-----------------+---------------------+-----------------+

2. VPC 網路處理

封包離開 ENI 並進入 VPC 聯網層，並在其中導向子網路的閘道以進行進一步路由。

3. VPC 路由表查詢

包含 EKS 控制平面 ENI 之子網路的 VPC 路由表具有遠端節點 CIDR 的特定路由（圖表中的第二個路由）。根據此路由規則，封包會導向至 VPC-to-onprem閘道。

4. 跨邊界傳輸

閘道會透過您建立的連線（例如 Direct Connect 或 VPN)，將封包跨雲端邊界傳輸到您的內部部署網路。

5. 內部部署網路接收

封包會送達本機內部部署路由器，以處理混合節點所在子網路的流量。

6. 最終交付

本機路由器會識別目的地 IP (10.80.0.2) 地址屬於其直接連線的網路，並將封包直接轉送至 kubelet接收和處理請求的目標混合節點。

回應

在混合節點kubelet處理請求之後，它會以相反的相同路徑傳回回應：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 10250          |                 |
| Dst: 10.0.0.132 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

6. kubelet 傳送回應

混合節點 (10.80.0.2) kubelet上的會建立以原始來源 IP 做為目的地的回應封包。目的地不屬於本機網路，因此其會傳送到主機的預設閘道，也就是本機路由器。

5. 本機路由器路由

路由器會判斷目的地 IP (10.0.0.132) 屬於 10.0.0.0/16，其具有指向所連接閘道的路由 AWS。

4. 跨邊界傳回

封包會傳回相同的內部部署至 VPC 連線（例如 Direct Connect 或 VPN)，以反向跨越雲端邊界。

3. VPC 路由

當封包送達 VPC 時，路由表會識別目的地 IP 是否屬於 VPC CIDR。封包會在 VPC 中路由。

2. VPC 網路交付

VPC 網路層會使用 EKS 控制平面 ENI () 將封包轉送至子網路10.0.0.132。

1。ENI 接收

封包到達連接到 Kubernetes API 伺服器的 EKS 控制平面 ENI，完成往返。

在混合節點上執行的 Pod 到 EKS 控制平面

不使用 CNI NAT

請求

Pod 通常會透過 kubernetes服務與 Kubernetes API 伺服器通訊。服務 IP 是叢集服務 CIDR 的第一個 IP。此慣例允許在 CoreDNS 可用於連接 API 伺服器之前需要執行的 Pod，例如 CNI。請求以服務 IP 做為目的地離開 Pod。例如，如果服務 CIDR 為 172.16.0.0/16，則服務 IP 將為 172.16.0.1。

1。Pod 啟動請求

Pod 會從隨機來源連接埠傳送請求至 API 伺服器連接埠 (443172.16.0.1) 上的kubernetes服務 IP ()。封包如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

2. CNI 處理

CNI 偵測到目的地 IP 不屬於其管理的任何 Pod CIDR。由於傳出 NAT 已停用，CNI 會將封包傳遞至主機網路堆疊，而不進行修改。

3. 節點網路處理

封包會進入節點的網路堆疊，其中netfilter掛鉤會觸發 kube-proxy 設定的iptables規則。下列順序適用數個規則：

封包會先命中KUBE-SERVICES鏈結，其中包含符合每個服務 ClusterIP 和連接埠的規則。
比對規則會跳至 kubernetes服務的KUBE-SVC-XXX鏈結（目的地為的封包172.16.0.1:443)，其中包含負載平衡規則。
負載平衡規則會隨機選取控制平面 ENI IPs (10.0.0.132 或 10.0.1.23) 的其中一個KUBE-SEP-XXX鏈。
選取的KUBE-SEP-XXX鏈結具有將目的地 IP 從服務 IP 變更為所選 IP 的實際規則。這稱為目的地網路地址轉譯 (DNAT)。

套用這些規則後，假設選取的 EKS 控制平面 ENI 的 IP 為 10.0.0.132，封包如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

節點會將封包轉送至其預設閘道，因為目的地 IP 不在本機網路中。

4. 本機路由器路由

本機路由器會判斷目的地 IP (10.0.0.132) 屬於 VPC CIDR (10.0.0.0/16)，並將其轉送至連線的閘道 AWS。

5. 跨邊界傳輸

封包會透過您已建立的連線（例如 Direct Connect 或 VPN)，跨雲端邊界傳輸到 VPC。

6. VPC 網路交付

VPC 聯網層會將封包路由至 EKS 控制平面 ENI (10.0.0.132) 所在的正確子網路。

7. ENI 接收

封包到達連接到 Kubernetes API 伺服器的 EKS 控制平面 ENI。

回應

EKS 控制平面處理請求後，會傳送回應回 Pod：

7. API 伺服器傳送回應

EKS Kubernetes API 伺服器會使用原始來源 IP 做為目的地來建立回應封包。封包如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

由於目的地 IP 屬於設定的遠端 Pod CIDR (10.85.0.0/16)，它會透過其在 VPC 中的 ENI 傳送它，並將子網路的路由器作為下一個躍點。

6. VPC 路由

VPC 路由表包含遠端 Pod CIDR (10.85.0.0/16) 的項目，會將此流量導向 VPC-to-onprem閘道。

5. 跨邊界傳輸

閘道會透過您建立的連線（例如 Direct Connect 或 VPN)，將封包跨雲端邊界傳輸到您的內部部署網路。

4. 現場部署網路接收

封包會送達本機內部部署路由器。

3. 交付至節點

路由器的資料表具有項目10.85.1.0/24，將 10.80.0.2做為下一個躍點，將封包交付至我們的節點。

2. 節點網路處理

當封包由節點的網路堆疊處理時， conntrack( 的一部分netfilter) 會比對封包與 Pod 最初建立的連線。由於最初套用了 DNAT，透過將來源 IP 從 EKS 控制平面 ENI 的 IP 重寫到kubernetes服務 IP 來conntrack反轉 DNAT：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

1。CNI 處理

CNI 會識別目的地 IP 屬於其網路中的 Pod，並將封包交付至正確的 Pod 網路命名空間。

此流程展示為什麼遠端 Pod CIDRs 必須能夠從 VPC 正確路由到託管每個 Pod 的特定節點 - 整個傳回路徑取決於 Pod IPs 在雲端和內部部署網路之間的適當路由。

使用 CNI NAT

此流程與沒有 CNI NAT 的流程非常相似，但有一個關鍵差異：CNI 會將來源 NAT (SNAT) 套用至封包，然後再將其傳送至節點的網路堆疊。這會將封包的來源 IP 變更為節點的 IP，允許封包路由回節點，而不需要額外的路由組態。

請求

1。Pod 啟動請求

Pod 會從隨機來源連接埠將請求傳送至 EKS Kubernetes API 伺服器連接埠 (443172.16.0.1) 上的kubernetes服務 IP ()。封包如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

2. CNI 處理

CNI 偵測到目的地 IP 不屬於其管理的任何 Pod CIDR。由於已啟用傳出 NAT，CNI 會將 SNAT 套用至封包，將來源 IP 變更為節點的 IP，然後再將其傳遞至節點的網路堆疊：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

注意：為了清楚起見，範例中iptables顯示為個別區塊的 CNI 和，但實際上，有些 CNIs 可能會使用 iptables 來套用 NAT。

3. 節點網路處理

在這裡，由設定的iptables規則kube-proxy的行為與上一個範例中的行為相同，將封包負載平衡到其中一個 EKS 控制平面 ENIs。封包現在如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

節點會將封包轉送至其預設閘道，因為目的地 IP 不在本機網路中。

4. 本機路由器路由

本機路由器會判斷目的地 IP (10.0.0.132) 屬於 VPC CIDR (10.0.0.0/16)，並將其轉送至連線的閘道 AWS。

5. 跨邊界傳輸

封包會透過您已建立的連線（例如 Direct Connect 或 VPN)，跨雲端邊界傳輸到 VPC。

6. VPC 網路交付

VPC 聯網層會將封包路由至 EKS 控制平面 ENI (10.0.0.132) 所在的正確子網路。

7. ENI 接收

封包到達連接到 Kubernetes API 伺服器的 EKS 控制平面 ENI。

回應

EKS 控制平面處理請求後，會傳送回應回 Pod：

7. API 伺服器傳送回應

EKS Kubernetes API 伺服器會使用原始來源 IP 做為目的地來建立回應封包。封包如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

由於目的地 IP 屬於設定的遠端節點 CIDR (10.80.0.0/16)，因此它會透過其在 VPC 中的 ENI 傳送它，並將子網路的路由器作為下一個躍點。

6. VPC 路由

VPC 路由表包含遠端節點 CIDR (10.80.0.0/16) 的項目，會將此流量導向 VPC-to-onprem閘道。

5. 跨邊界傳輸

閘道會透過您建立的連線（例如 Direct Connect 或 VPN)，將封包跨雲端邊界傳輸到您的內部部署網路。

4. 現場部署網路接收

封包會送達本機內部部署路由器。

3. 交付至節點

本機路由器會識別目的地 IP (10.80.0.2) 地址屬於其直接連線的網路，並將封包直接轉送至目標混合節點。

2. 節點網路處理

當封包由節點的網路堆疊處理時， conntrack( 的一部分netfilter) 會將封包與 Pod 最初建立的連線相符，而且自最初套用 DNAT 以來，它會透過將來源 IP 從 EKS 控制平面 ENI 的 IP 重寫至kubernetes服務 IP 來反轉此項目：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

1。CNI 處理

CNI 會識別此封包屬於先前已套用 SNAT 的連線。它會反轉 SNAT，將目的地 IP 變更回 Pod 的 IP：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

CNI 偵測到目的地 IP 屬於其網路中的 Pod，並將封包交付至正確的 Pod 網路命名空間。

此流程示範 CNI NAT-ing 如何透過允許封包路由回節點來簡化組態，而不需要額外的 Pod CIDRs 路由。

在混合節點上執行的 EKS 控制平面到 Pod (webhooks)

此流量模式最常見於 Webhook，其中 EKS 控制平面需要直接啟動與混合節點上 Pod 中執行之 Webhook 伺服器的連線。範例包括驗證和變更 API 伺服器在資源驗證或變動程序期間呼叫的許可 Webhook。

請求

1。EKS Kubernetes API 伺服器啟動請求

在叢集中設定 Webhook 並觸發相關的 API 操作時，EKS Kubernetes API 伺服器需要直接連線至 Webhook 伺服器 Pod。API 伺服器會先從與 Webhook 相關聯的服務或端點資源中查詢 Pod 的 IP 地址。

假設 Webhook Pod 在具有 IP 的混合節點上執行10.85.1.23，EKS Kubernetes API 伺服器會建立對 Webhook 端點的 HTTPS 請求。初始封包會透過 VPC 中的 EKS 控制平面 ENI 傳送，因為目的地 IP 10.85.1.23屬於設定的遠端 Pod CIDR (10.85.0.0/16)。封包如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 41892 (random) |                 |
| Dst: 10.85.1.23 | Dst: 8443           |                 |
+-----------------+---------------------+-----------------+

2. VPC 網路處理

封包離開 EKS 控制平面 ENI 並進入 VPC 聯網層，並將子網路的路由器作為下一個躍點。

3. VPC 路由表查詢

包含 EKS 控制平面 ENI 之子網路的 VPC 路由表包含遠端 Pod CIDR () 的特定路由10.85.0.0/16。此路由規則會將封包導向 VPC-to-onprem（例如，適用於 Direct Connect 的 Virtual Private Gateway 或 VPN 連線）：


Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)

4. 跨邊界傳輸

閘道會透過您建立的連線（例如 Direct Connect 或 VPN)，將封包跨雲端邊界傳輸到您的內部部署網路。封包會在周遊此連線時維護其原始來源和目的地 IP 地址。

5. 現場部署網路接收

封包會送達本機內部部署路由器。路由器會參考其路由表，以判斷如何到達 10.85.1.23 地址。若要這麼做，您的內部部署網路必須具有將流量導向適當混合節點的 Pod CIDRs 路由。

在此情況下，路由器的路由表包含一個項目，指出可透過具有 IP 的混合節點來連接10.85.1.0/24子網路10.80.0.2：


Destination     Next Hop
10.85.1.0/24    10.80.0.2

6. 交付至節點

根據路由表項目，路由器會將封包轉送到混合節點 (10.80.0.2)。當封包到達節點時，它看起來與 EKS Kubernetes API 伺服器傳送它時相同，目的地 IP 仍然是 Pod 的 IP。

7. CNI 處理

節點的網路堆疊會收到封包，並看到目的地 IP 不是節點自己的 IP，將其傳遞給 CNI 進行處理。CNI 會識別目的地 IP 屬於在此節點本機上執行的 Pod，並透過適當的虛擬介面將封包轉送至正確的 Pod：


Original packet -> node routing -> CNI -> Pod's network namespace

Pod 中的 Webhook 伺服器會收到請求並加以處理。

回應

在 Webhook Pod 處理請求後，它會以相反的相同路徑傳回回應：

7. Pod 傳送回應

Webhook Pod 會使用自己的 IP 做為來源建立回應封包，並將原始請求者 (EKS 控制平面 ENI) 做為目的地：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.23 | Src: 8443           |                 |
| Dst: 10.0.0.132 | Dst: 41892          |                 |
+-----------------+---------------------+-----------------+

CNI 會識別此封包會移至外部網路（而非本機 Pod)，並將封包傳遞至保留原始來源 IP 的節點網路堆疊。

6. 節點網路處理

節點會判斷目的地 IP (10.0.0.132) 不在本機網路中，並將封包轉送至其預設閘道（本機路由器）。

5. 本機路由器路由

本機路由器會參考其路由表，並判斷目的地 IP (10.0.0.132) 屬於 VPC CIDR (10.0.0.0/16)。它會將封包轉送到連接到的閘道 AWS。

4. 跨邊界傳輸

封包會傳回相同的內部部署至 VPC 連線，以相反方向跨越雲端邊界。

3. VPC 路由

當封包抵達 VPC 時，路由表會識別目的地 IP 是否屬於 VPC 內的子網路。封包會在 VPC 中相應地路由。

2. 和 1. EKS 控制平面 ENI 接收

封包到達連接到 EKS Kubernetes API 伺服器的 ENI，完成往返。API 伺服器會收到 Webhook 回應，並繼續根據此回應處理原始 API 請求。

此流量流程示範為什麼必須正確設定和路由遠端 Pod CIDRs：

VPC 必須具有指向內部部署閘道之遠端 Pod CIDRs的路由
您的內部部署網路必須具有 Pod CIDRs 的路由，將流量導向託管這些 Pod 的特定節點
如果沒有此路由組態，將無法從 EKS 控制平面存取在混合節點上 Pod 中執行的 Webhook 和其他類似服務。

在混合節點上執行Pod-to-Pod

本節說明在不同混合節點上執行的 Pod 如何互相通訊。此範例假設您的 CNI 使用 VXLAN 進行封裝，這在 Cilium 或 Calico 等 CNIs 中很常見。其他封裝通訊協定的整體程序類似，例如 Geneve 或 IP-in-IP。

請求

1。Pod A 啟動通訊

節點 1 上的 Pod A (10.85.1.56) 想要將流量傳送至節點 2 上的 Pod B (10.85.2.67)。初始封包如下所示：


+------------------+-----------------+-------------+-----------------+
| 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 攔截和處理封包

當 Pod A 的封包離開其網路命名空間時，CNI 會攔截它。CNI 會參考其路由表，並判斷： - 目的地 IP (10.85.2.67) 屬於 Pod CIDR - 此 IP 不在本機節點上，但屬於節點 2 (10.80.0.3) - 封包需要使用 VXLAN 封裝。

封裝的決策至關重要，因為基礎實體網路不知道如何直接路由 Pod CIDRs，它只知道如何在節點 IPs之間路由流量。

CNI 會將整個原始封包封裝在 VXLAN 框架內。這有效地建立具有新標頭的「封包內」：


+-----------------+----------------+--------------+------------+---------------------------+
| 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)               |
+-----------------+----------------+--------------+------------+---------------------------+

有關此封裝的要點：- 外部封包從節點 1 (10.80.0.2) 定址到節點 2 (10.80.0.3) - UDP 連接埠8472是預設使用的 VXLAN 連接埠 Cilium - VXLAN 網路識別符 (VNI) 識別此封包所屬的覆蓋網路 - 整個原始封包（將 Pod A 的 IP 作為來源，將 Pod B 的 IP 作為目的地）在內部保持不變

封裝的封包現在會進入節點 1 的一般網路堆疊，並以與任何其他封包相同的方式處理：

節點網路處理：節點 1 的網路堆疊會根據其目的地路由封包 (10.80.0.3)
本機網路交付：
- 如果兩個節點位於相同的第 2 層網路上，封包會直接傳送到節點 2
- 如果封包位於不同的子網路上，則會先將封包轉送至本機路由器
路由器處理：路由器會根據其路由表轉送封包，並將其交付至節點 2

3. 接收節點處理

當封裝的封包送達節點 2 () 時10.80.0.3：

節點的網路堆疊會接收並識別為 VXLAN 封包 (UDP 連接埠 4789)
封包會傳遞至 CNI 的 VXLAN 介面進行處理

4. VXLAN 解壓縮

節點 2 上的 CNI 會處理 VXLAN 封包：

它會去除外部標頭（乙太網路、IP、UDP 和 VXLAN)
它會擷取原始內部封包
封包現在恢復為原始格式：


+------------------+-----------------+-------------+-----------------+
| 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 會檢查目的地 IP (10.85.2.67) 和：

識別此 IP 屬於本機 Pod
透過適當的虛擬介面路由封包
將封包交付至 Pod B 的網路命名空間

回應

當 Pod B 回應 Pod A 時，整個程序會反向發生：

Pod B 將封包傳送至 Pod A (10.85.1.56)
節點 2 的 CNI 使用 VXLAN 封裝，將目的地設定為節點 1 (10.80.0.2)
封裝的封包會傳送到節點 1
節點 1 的 CNI 將其解封裝，並交付原始回應給 Pod A

雲端節點上的 Pod 到混合節點上的 Pod （東西流量）

請求

1。Pod A 啟動通訊

EC2 節點上的 Pod A (10.0.0.56) 想要將流量傳送至混合節點上的 Pod B (10.85.1.56)。初始封包如下所示：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.56  | Src: 52390 (random) |                 |
| Dst: 10.85.1.56 | Dst: 8080           |                 |
+-----------------+---------------------+-----------------+

使用 VPC CNI 時，Pod A 具有來自 VPC CIDR 的 IP，並直接連接到 EC2 執行個體上的 ENI。Pod 的網路命名空間已連線至 VPC 網路，因此封包會直接進入 VPC 路由基礎設施。

2. VPC 路由

VPC 路由表包含遠端 Pod CIDR (10.85.0.0/16) 的特定路由，會將此流量導向 VPC-to-onprem閘道：


Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)

根據此路由規則，封包會導向至連線至內部部署網路的閘道。

3. 跨邊界傳輸

閘道會透過您建立的連線（例如 Direct Connect 或 VPN)，將封包跨雲端邊界傳輸到您的內部部署網路。在此傳輸過程中，封包會維護其原始來源和目的地 IP 地址。

4. 現場部署網路接收

封包會送達本機內部部署路由器。路由器會參考其路由表，以判斷到達 10.85.1.56 地址的下一個跳轉。您的內部部署路由器必須具有將流量導向適當混合節點的 Pod CIDRs 路由。

路由器的資料表有一個項目，指出子網路可透過具有 IP 的混合節點10.85.1.0/24來連接10.80.0.2：


Destination     Next Hop
10.85.1.0/24    10.80.0.2

5. 節點網路處理

路由器會將封包轉送至混合節點 (10.80.0.2)。當封包到達節點時，它仍然具有 Pod A 的 IP 作為來源，Pod B 的 IP 作為目的地。

6. CNI 處理

節點的網路堆疊會收到封包，並看到目的地 IP 不是自己的 IP 會將其傳遞給 CNI 進行處理。CNI 會識別目的地 IP 屬於在此節點本機上執行的 Pod，並透過適當的虛擬介面將封包轉送至正確的 Pod：


Original packet -> node routing -> CNI -> Pod B's network namespace

Pod B 會接收封包並視需要處理。

回應

6. Pod B 傳送回應

Pod B 會以自己的 IP 做為來源建立回應封包，而 Pod A 的 IP 做為目的地：


+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 8080           |                 |
| Dst: 10.0.0.56  | Dst: 52390          |                 |
+-----------------+---------------------+-----------------+

CNI 會識別此封包目的地為外部網路，並將其傳遞至節點的網路堆疊。

5. 節點網路處理

節點會判斷目的地 IP (10.0.0.56) 不屬於本機網路，並將封包轉送至其預設閘道（本機路由器）。

4. 本機路由器路由

本機路由器會參考其路由表，並判斷目的地 IP (10.0.0.56) 屬於 VPC CIDR (10.0.0.0/16)。它會將封包轉送到連接到的閘道 AWS。

3. 跨邊界傳輸

封包會傳回相同的內部部署至 VPC 連線，並反向跨越雲端邊界。

2. VPC 路由

當封包送達 VPC 時，路由系統會識別目的地 IP 是否屬於 VPC 內的子網路。封包會透過 VPC 網路路由至託管 Pod A 的 EC2 執行個體。

1。Pod A 接收回應

封包抵達 EC2 執行個體，並透過其連接的 ENI 直接交付至 Pod A。由於 VPC CNI 不會針對 VPC 中的 Pod 使用浮水印聯網，因此不需要額外的解封裝 - 封包會以其原始標頭完整送達。

此東西流量流程示範了為什麼遠端 Pod CIDRs 必須正確設定並從兩個方向路由：

VPC 必須具有指向內部部署閘道之遠端 Pod CIDRs 的路由
您的內部部署網路必須具有 Pod CIDRs 的路由，將流量導向託管這些 Pod 的特定節點。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

Kubernetes 概念

混合節點 nodeadm