網路隔離的最小配置

kubesphere發表於2024-04-25

作者：任雲康，青雲科技研發工程師

前言

對於專案下的網路隔離，有使用者提出了以下疑問：

  • 網路隔離是針對 Pod 的嗎？
  • 網路隔離的最小配置是什麼？
    • 配置後，哪些是可以訪問的，哪些是不可以訪問的？
    • 透過 Ingress 暴露、LB 型別的 Service 暴露、NodePort 型別的 Service 暴露的流量的具體鏈路是什麼樣的？

KubeSphere 網路策略的實現思路

KubeSphere 對於 NetworkPolicy 的整合中主要包含：

  • 叢集網路策略管理：主要提供一個原生的 NetworkPolicy 資源的管理，當 KubeSphere 租戶網路隔離無法滿足使用者的全部需求時，可以在此透過 yaml 管理原生的 NetworkPolicy。

  • 租戶網路隔離管理：分為企業空間網路隔離和專案空間的網路隔離。

    • 當開啟企業空間網路隔離時，會自動為該企業空間的所有專案建立一條只允許本企業空間訪問的入站規則的網路策略，預設不限制出站流量；
    • 當開啟專案網路隔離時，會自動為該專案建立一條只允許專案訪問的入站規則的網路策略；
    • 專案網路隔離下可以配置白名單列表，內部白名單允許當前專案中的容器組與當前企業空間其他專案中的服務進行通訊，外部白名單允許當前專案中的容器組與企業空間外部的特定網段和埠進行通訊；
    • 預設不限制出站流量；如果配置出站白名單，那隻會放行白名單上的出站項。

出站：即對本專案下的 pod 是否可以訪問本專案外的 pod/ip/port 的限制。
入站：即對本專案外的 pod/ip 是否可以訪問本專案下的 pod 所提供的服務的限制。
注意：NetworkPolicy 是由具體的 CNI 來實現，KubeSphere 做了 UI 化的管理，同時封裝了一個專案級別的 NetworkPolicy，用作專案空間的網路隔離。

因此，對前文的問題，我們有了答案：

  1. 網路隔離是針對與 pod 的，而專案網路隔離會匹配本專案下的所有 pod；也可以認為此處的網路隔離是針對專案的；
  2. 服務透過 Ingress、NodePort、LoadBalancer 暴露，表明 service 要給叢集外提供服務，如果使用 KubeSphere 專案網路隔離進行管理的話，需要配置外部白名單。

配置

當我們透過 NodePort、LoadBalancer 暴露 Kubernetes 的 service 時，kube-proxy 會建立相應的 ipvs 或 iptables 規則來轉發流量。然而，當外部流量進入叢集並根據這些規則被轉發時，如果目標 pod 不在本地節點上，就會進行一次源網路地址轉換（SNAT），這將導致 TCP 包中的源 IP 地址被替換為節點 IP 或 overlay 封裝介面的 IP，從而丟失了客戶端的原始 IP。如果目標 pod 在本地節點上，可能會直接轉發到本機 pod，此時會保留客戶端 IP。

這裡以 Calico 舉例，如果使用的非 ipip/vxlan 模式，我們需要找到 node 上的 eth0 網口上的 IP；如果使用的是 ipip/vxlan 模式，需要找到 node 上的用於封裝網路卡的 IP，然後新增到外部白名單中放行。同時也要把客戶端 IP 也新增到外部白名單中放行。

為了總是保留客戶端的原始 IP，可以將 service 的外部訪問策略設定為 Local。但是當流量進入沒有目標 pod 的節點上時，流量不再進行轉發導致請求失敗。

配置 NodePort 暴露

當配置 service 為 NodePort 且配置外部訪問策略為 Cluster 時，流量訪問如下：

當配置 service 為 NodePort 且配置外部訪問策略為 Local 時，流量訪問如下：

開啟專案網路隔離後，

  • 當外部訪問策略為 Cluster ，需要在外部白名單中放行叢集的所有節點 IP 或 overlay 封裝介面的 IP、客戶端 IP，缺點是可能會丟失客戶端 IP，且由於 SNAT 的緣故無法攔截指定的 IP；
  • 當外部訪問策略為 Local ，需要在外部白名單中放行可以訪問該服務的客戶端 IP，缺點需要確保使用執行了 pod 的節點 IP:NodePort 來訪問 service，否則資料包會被丟棄，從而導致請求失敗。

配置 LoadBalancer 暴露

當 service 設定為 LoadBalancer 時，你需要支援配置外部負載均衡器的環境，不同的環境技術實現也會有所不同，下面以 OpenELB 為例說明。

當配置 service 為 LoadBalancer 且配置外部訪問策略為 Cluster 時，流量訪問如下：

當配置 service 為 LoadBalancer 且配置外部訪問策略為 Local 時，流量訪問如下：

開啟專案網路隔離後，

  • 當外部訪問策略為 Cluster ，需要在外部白名單中放行叢集的所有節點 IP 或 overlay 封裝介面的 IP、客戶端 IP，缺點是可能會丟失客戶端 IP，且由於 SNAT 的緣故無法攔截指定的 IP；
  • 當外部訪問策略為 Local ，需要在外部白名單中放行可以訪問該服務的客戶端 IP，OpenELB 只會將訪問 LoadBalancer serviceip 的流量轉發到已經執行了 pod 的節點上。

配置 Ingress 暴露

當配置 Ingress 訪問時，叢集內部不同的 service 需要註冊相應的應用路由，同時 Ingress svc 依舊需要透過 LoadBalancer 或者 NodePort 對外暴露，訪問流量如下圖：

對於 LoadBalancer 或者 NodePort 對外暴露可見我們上述探討。

更多技術原理可參考 kubernetes networkpolicy：

  • https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/
  • https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/

本文由部落格一文多發平臺 OpenWrite 釋出！

相關文章