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

混合節點的網路流量流程

此頁面詳細說明 EKS 混合節點的網路流量流程，其中各圖表會顯示不同流量類型的端到端網路路徑。

涵蓋下列流量流程：

混合節點 kubelet 到 EKS 控制平面
EKS 控制平面到混合節點 (kubelet 伺服器)
在混合節點上執行的 Pod 到 EKS 控制平面
EKS 控制平面到混合節點上執行的 Pod (Webhook)
在混合節點上執行的 Pod 到 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)。在公有存取叢集中，這會解析為屬於在 AWS 中執行的 EKS 服務的公有 IP 位址 (例如 54.239.118.52)。然後，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 可用之前執行的 Pod，以便連接 API 伺服器，例如 CNI。請求以服務 IP 作為目的地離開 Pod。例如，如果服務 CIDR 為 172.16.0.0/16，則服務 IP 將為 172.16.0.1。

1。Pod 啟動請求

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


+-----------------+---------------------+-----------------+
| 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 IP (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，conntrack 透過將來源 IP 從 EKS 控制平面 ENI 的 IP 重寫到 kubernetes 服務 IP，進而反轉 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 CIDR 必須能夠從 VPC 一直正確路由到託管每個 Pod 的特定節點，整個傳回路徑取決於跨雲端和內部部署網路的適當 Pod IP 路由。

使用 CNI NAT

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

請求

1。Pod 啟動請求

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


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

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

3. 節點網路處理

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


+-----------------+---------------------+-----------------+
| 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 CIDR 路由。

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

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

請求

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 的虛擬私有閘道或 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 CIDR 的路由。

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


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 CIDR 必須正確進行設定和路由：

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

在混合節點上執行的 Pod 到 Pod

本節說明在不同混合節點上執行的 Pod 會如何彼此進行通訊。此範例假設您的 CNI 使用 VXLAN 進行封裝，而這在 Cilium 或 Calico 等 CNI 中很常見。整體程序與其他封裝通訊協定，例如 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 CIDR，它只知道如何在節點 IP 之間路由流量。

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 是 Cilium 使用的 VXLAN 連接埠 - 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 CIDR 的路由。

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


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 CIDR 必須正確設定並可從雙向路由：

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

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

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

文件慣用形式

Kubernetes 概念

混合節點 nodeadm