**協助改進此頁面** 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 混合節點的網路流量流程 此頁面詳細說明 EKS 混合節點的網路流量流程，其中各圖表會顯示不同流量類型的端到端網路路徑。 涵蓋下列流量流程： + [混合節點 `kubelet` 到 EKS 控制平面](#hybrid-nodes-concepts-traffic-flows-kubelet-to-cp) + [EKS 控制平面到混合節點 (`kubelet` 伺服器)](#hybrid-nodes-concepts-traffic-flows-cp-to-kubelet) + [在混合節點上執行的 Pod 到 EKS 控制平面](#hybrid-nodes-concepts-traffic-flows-pods-to-cp) + [EKS 控制平面到混合節點上執行的 Pod (Webhook)](#hybrid-nodes-concepts-traffic-flows-cp-to-pod) + [在混合節點上執行的 Pod 到 Pod](#hybrid-nodes-concepts-traffic-flows-pod-to-pod) + [雲端節點上的 Pod 到混合節點上的 Pod (東西流量)](#hybrid-nodes-concepts-traffic-flows-east-west) ## 混合節點 `kubelet` 到 EKS 控制平面 ![\[混合節點 kubelet 到 EKS 控制平面\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/hybrid-nodes-kubelet-to-cp-public.png) ### 請求 **1`kubelet`. 啟動請求** 當混合節點上的 `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` 伺服器) ![\[EKS 控制平面到混合節點\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/hybrid-nodes-cp-to-kubelet.png) ### 請求 **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 控制平面 ![\[在混合節點上執行的 Pod 到 EKS 控制平面\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/hybrid-nodes-pod-to-cp.png) ### 不使用 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` 規則。按下列順序依次適用數條規則： 1. 該封包會先命中 `KUBE-SERVICES` 鏈結，其中包含與每個服務的 ClusterIP 和連接埠相符的規則。 1. 該相符規則會跳至 `kubernetes` 服務的 `KUBE-SVC-XXX` 鏈結 (以 `172.16.0.1:443` 為目的地的封包)，其中包含負載平衡規則。 1. 該負載平衡規則會隨機選取控制平面 ENI IP (`10.0.0.132` 或 `10.0.1.23`) 的其中一個 `KUBE-SEP-XXX` 鏈結。 1. 選取的 `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) ![\[EKS 控制平面到混合節點上執行的 Pod\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/hybrid-nodes-cp-to-pod.png) 此流量模式最常見於 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 到 Pod\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/hybrid-nodes-pod-to-pod.png) 本節說明在不同混合節點上執行的 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. **節點網路處理**：節點 1 的網路堆疊會根據其目的地 (`10.80.0.3`) 路由封包 1. **本機網路交付**： + 如果兩個節點位於相同的第 2 層網路上，則該封包會直接傳送至節點 2 + 如果封包位於不同的子網路上，則會先將該封包轉送至本機路由器 1. **路由器處理**：路由器會根據其路由表轉送封包，並將其交付至節點 2 **3. 接收節點處理** 當封裝的封包抵達節點 2 (`10.80.0.3`) 時： 1. 節點的網路堆疊會接收此封包並將其識別為 VXLAN 封包 (UDP 連接埠 `4789`) 1. 該封包會傳遞至 CNI 的 VXLAN 介面，以進行處理 **4. VXLAN 解封裝** 節點 2 上的 CNI 會處理 VXLAN 封包： 1. 它會移除外部標頭 (乙太網路、IP、UDP 和 VXLAN) 1. 它會擷取原始內部封包 1. 該封包現恢復為其原始格式： ``` +------------------+-----------------+-------------+-----------------+ | 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`) 和： 1. 識別此 IP 屬於本機 Pod 1. 透過適當的虛擬介面路由封包 1. 將封包交付至 Pod B 的網路命名空間 ### 回應 當 Pod B 回應 Pod A 時，整個程序會發生反轉，即以相反順序執行： 1. Pod B 會將封包傳送至 Pod A (`10.85.1.56`) 1. 節點 2 的 CNI 會使用 VXLAN 進行封裝，並將目的地設定為節點 1 (`10.80.0.2`) 1. 封裝的封包會交付至節點 1 1. 節點 1 的 CNI 會將其解封裝，並將原始回應交付給 Pod A ## 雲端節點上的 Pod 到混合節點上的 Pod (東西流量) ![\[雲端節點上的 Pod 到混合節點上的 Pod\]](http://docs.aws.amazon.com/zh_tw/eks/latest/userguide/images/hybrid-nodes-east-west.png) ### 請求 **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 的特定節點。