當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

解密OpenShift内部通信网络

發布時間：2025/3/16 编程问答 34 豆豆

生活随笔收集整理的這篇文章主要介紹了解密OpenShift内部通信网络小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

上一篇：PaaS中OpenShift持久化存儲的管理實踐

由于 OpenShift 網絡通信概念較多，相對理解起來困難，為了方便讀者能夠清晰深入內部，在開始網絡模型講解之前，我們先嘗試從 OpenShift 的用戶角度，提出 5 個問題，并對 5 個問題作出解答，先對 OpenShift 網絡通信有個大致的概念。然后讀者帶著對這 5 個問題的理解，閱讀本章節更為詳細的內容。

1. OpenShift 中 Pod 之間通訊是否一定需要 Service？

? ?

答案：Pod 之間的通信不需要 Service。

在同一個 Namespace 中， Pod A 開放了某個端口，在一個 Pod B 中 curl pod_A_IP:port，就能與之通信，如下圖 2-45 所示。

圖 2-45 查看兩個 pod 的 IP 地址

所以說：Pod 之間能不能通信，和兩個 Pod 經不經過 Service、有沒有 Service 無關。

2. 從一個 Pod 訪問另外一個 Pod 可以通信，其數據鏈路是什么？

? ?

答案：兩個 Pod 如果在一個 OpenShift 節點上，其通信流量沒有繞出本宿主機的 OVS：如果兩個 Pod 在不同節點上， Pod 之間的通信經過了 Vxlan。具體內容后文將展開說明。

3. 既然 Pod 之間通信不需要 Service，為何 Kubernetes 引入 Service？

? ?

我們首先要明確：Service 是對一組提供相同功能的 Pods 的抽象，并為它們提供一個統一的內部訪問入口。它主要解決：

負載均衡：Service 提供其所屬多個 Pod 的負載均衡

服務注冊與發現：解決不同服務之間的通信問題。在 OpenShift 中的創建應用后，需要提供訪問應用的地址供其他服務調用，這個地址就是由 Service 提供。

在 OpenShift 中，我們每創建一個 Service，會分配一個 IP 地址，稱為 ClusterIP，這個 IP 地址是一個虛擬的地址（OpenShift 外部不可達），這樣內部 DNS 就可以通過 Service 名稱（FQDN）解析成 ClusterIP 地址。這就完成了服務注冊，DNS 解析需要的信息全部保存在 Etcd 中。

那么，Service 注冊到 Etcd 的內容是什么呢?

實際上是 Service 資源對象的 Yaml 包含的相關內容。

也就是說，Etcd 中記錄的 Services 注冊信息里有 Namespace，Service Name，ClusterIP 等，通過這三個信息就可組成 DNS A 記錄，也就是，Service 的 FQDN 和 Service ip 之間的對應關系。需要說明的是，Etcd 不是 DNS，DNS A 記錄是通過查詢生成的。OpenShift 的 DNS 是由 SkyDNS/CoreDNS 實現的（后面內容詳細介紹）。

服務發現這個詞經常被妖魔化。它的作用是為了 OpenShift 某個服務發現另外一個服務。也就說，Service A 要和 ServiceB 通訊，我需要知道 ServiceB 是誰、在哪、Cluster IP、對應的 Pod IP 都是什么？這就叫服務發現。

4. 有了 Service 以后，Pod 之間的通訊和沒有 Service 有何區別？

? ?

在數據通訊層，沒區別，因為 Service 只是邏輯層面的東西。

但是，沒有 Service，多個 Pod 無法實現統一入口，也無法實現負載均衡。也就是說，沒有 Service，多個 Pod 之間的負載均衡就要依賴第三方實現。

那么，有了 Service 以后，Pod 之間怎么尋址？

回答這個問題，我們要站在開發者角度。如果一個程序員，要寫微服務，微服務之間要相互調用，怎么寫？寫 Pod IP 和 ClusterIP 是不現實的，因為這兩個 IP 可能發生變化。

如果程序員決定用 Kubernetes 做服務發現的前提下（如果使用微服務框架中的服務注冊中心做服務注冊發現，可以不使用 Kubernetes 的 Service），實現不同服務之間的調用，那么就需要使用 Kubernetes 的 Service 名稱。因為 Service 名稱我們是可以固定的。

OpenShift/Kubernetes 中 Service 有短名和長名。以下圖 2-46 為例，jws-app 就是 Service 的短名，Service 長名的格式是：..svc.cluser.local，也就是 jws-app.web.svc.cluser.local。Service 短名可以自動補充成長名，這是 OpenShift 中的 DNS 做的，這個后面介紹。

圖 2-46 查看 Service 的名稱

那么，如果在兩個不同的 Namespace 中，有兩個相同的 Service 短名，微服務調用不是會出現混亂？程序員的代碼里是不是要寫 Service 全名？

首先，站在 OpenShift 集群管理員的角度，我們看所有的項目，有幾十個或者而更多，會覺得在不同 Namespaces 中存在相同的 Service 短名是可能（比如 Namespace A 中有個 acat 的 Service，Namespace B 中也有個 acat 的 Service）。但站在程序員角度，他只是 OpenShift 的使用者、擁有有自己的 Namespace 的管理權，其他 Namespace 不能訪問。而且絕大多數情況下，同一個業務項目的微服務一般會運行在同一個 Namespace 中，默認如果使用短名稱（只寫 Service Name），則會自動補全成當前 Namespace 的 FQDN，只有在跨 Namespace 調用的時候才必須寫全名 FQDN。

所以，程序員寫的程序用到了 Service Name。那么，真正運行應用的 Pod 之間的通訊，也必然會以 Service Name 去找。通過 Service 名稱解析為 Service ClusterIP，然后經過 Kube-proxy（默認 Iptables 模式）的負載均衡最終選擇一個實際的 Pod IP。找到 Pod IP 以后，接下來就會進行實際的數據交換，這就和 Service 沒有關系了。

5. ClusterIP 到 Pod IP 這部分的負載均衡怎么實現的？

? ?

目前版本 OpenShift 中是通過 kube-proxy（iptables 模式）實現的。具體內容后面內容詳細介紹。

? ?

通過以上 5 個問題的問答，相信很多讀者關于 OpenShift 通信網絡的疑問有了大致的了解。接下來，我們針對 OpenShift 的網絡通信展開講述。

? ?

OpenShift 的網絡模型

OpenShift 的網絡模型繼承于 Kubernetes，從內到外共包含如下四個方面：

Pod 內部容器通信的的網絡。

Pod 與 Pod 通信的網絡。

Pod 和 Service 之間通信的網絡。

集群外部與 Service 或 Pod 通信的網絡。

這四部分構成了整個 OpenShift 的網絡模型，下面我們分別進行說明。

7.1

? ?

Pod 內部容器通信的網絡

我們都知道 Pod 是一組容器的組合，意味著每個 Pod 中可以有多個容器存在，那么這多個容器之間如何通信呢？這就是這部分要解決的問題。

Kubernetes 通過為 Pod 分配統一的網絡空間，實現了多個容器之間網絡共享，也就是同一個 Pod 中的容器之間通過 Localhost 相互通信。

7.2

? ?

Pod 與 Pod 通信的網絡

關于這部分 Kubernetes 在設計之時的目標就是 Pod 之間可以不經過 NAT 直接通信，即使 Pod 跨主機。而這部分 Kubernetes 早期并未提供統一標準的方案，需要用戶提前將節點網絡配置完成，各個廠商提供了不同的解決方案，諸如 Flannel、OVS 等等。隨著 Kubernetes 的發展，在網絡方向上希望通過統一的方式來集成不同的網絡方案，也就有了現在的網絡開放接口 CNI（Container Network Interface）。

CNI 項目是由多個公司和項目創建組成的，包括 CoreOS、紅帽、Apache Mesos、Cloud Foundry、Kubernetes、Kurma 和 rkt。CoreOS 首先提出定義網絡插件和容器之間的通用接口，CNI 被設計為規范，它僅關注容器的網絡連接并在刪除容器時刪除分配的網絡資源。

CNI 有三個主要組成部分：

CNI 規范：定義容器運行時和網絡插件之間的 API。

插件：對各種 SDN 對接的組件。

庫：提供 CNI 規范的 Go 實現，容器運行時可以使用它來便捷地使用 CNI。

各廠商遵守規范開發網絡組件，在技術實現上共分為兩大陣營：

基于二層實現：通過將 Pod 放在一個大二層網絡中，跨節點通信通常使用 Vxlan 或 UDP 封包實現，常用的此類插件有 Flannel（UDP 或 Vxlan 封包模式）、OVS、Contiv、OVN 等。

基于三層實現：將 Pod 放在一個互聯互通的網絡中，通常使用路由實現，常用的此類插件有 Calico、Flannel-GW、Contiv、OVN 等。

可以看到網絡插件的種類較為繁多，OpenShift 默認使用的是基于 OVS 的二層網絡實現 Pod 與 Pod 之間的通信，后面我們將詳細介紹。

7.3

? ?

Pod 和 Service 之間通信的網絡

Pod 與 Service 之間的通信主要指在 Pod 中訪問 Service 的地址。在 OpenShift 中， Service 是對一組提供相同功能的 Pods 的抽象，并為它們提供一個統一的內部訪問入口。主要解決以下兩個問題：

服務注冊與發現：服務注冊發現在微服務架構中，解決不同服務之間的通信問題。在 OpenShift 中的創建應用后，需要提供訪問應用的地址供其他服務調用，這個地址就是由 Service 提供。

每創建一個 Service 會分配一個 Service IP 地址，稱為 ClusterIP，這個 IP 地址是一個虛擬的地址，無法執行 ping 操作。同時自動在內部 DNS 注冊一條對應的 A 記錄，這就完成了服務注冊，注冊信息全部保存在 Etcd 中。服務發現支持環境變量和 DNS 兩種方式，其中 DNS 的方式最為常用，關于 DNS 的部分我們將在后面章節詳細說明。

負載均衡：每個 Service 后端可能對應多個 Pod 示例，在訪問 Service 的時候需要選擇一個合適的后端處理請求。

Service 的負載均衡可以由很多的實現方式，目前 Kubernetes 官方提供了三種代理模式：userspace、iptables、ipvs。目前版本 OpenShift 默認的代理模式是 iptables，本文主要介紹這種模式。有興趣的讀者參考 Kubernetes 官網中對 Service 的介紹自行了解其他模式。

Iptables 模式官方示意圖如下圖 2-47 所示：

圖 2-47 Iptables 模式

從圖中可以看出，當客戶端訪問 Servcie 的 ClusterIP 時，由 Iptables 實現負載均衡，選擇一個后端處理請求，默認的負載均衡策略是輪詢。在這種模式下，每創建一個 Service，會自動匹配后端實例 Pod 記錄在 Endpoints 對象中，并在所有 Node 節點上添加相應的 iptables 規則，將訪問該 Service 的 ClusterIP 與 Port 的連接重定向到 Endpoints 中的某一個后端 Pod，由于篇幅有限，關于負載均衡實現的細節不再贅述。

這種模式有兩個缺點需要關注：

第一，不支持復雜的負載均衡算法；

第二，當選擇的某個后端 Pod 沒有響應時，無法自動重新連接到另一個 Pod，用戶必須利用 Pod 的健康監測來保證 Endpoints 列表中 Pod 都是存活的。

集群外部與 Service 或 Pod 通信的網絡上節中我們說過，創建 Service 分配的 ClusterIP 是一個虛擬 IP 地址，外部是無法訪問的，那么該如何實現集群外部訪問部署在集群中的應用呢？

目前 OpenShift 共有以下五種對外暴露服務的方式：

Hostport
Nodeport
Hostnetwork
Ingress/router
LoadBalancer

不同方式的使用場景各不相同，關于每種方式的具體細節我們將在后面小節中進行說明。

? ?

多租戶的隔離

對于 OpenShift 來說，認為一個 Namespace 就是一個租戶，實現多組戶隔離主要表現在網絡上，即每個租戶都擁有與其他租戶完全隔離的自有網絡環境。而 OpenShift 的網絡可以由多種第三方插件實現，是否支持多租戶隔離要看選擇的 Pod 網絡插件。目前廣泛使用的是通過網絡策略控制網絡隔離，網絡策略采用了比較嚴格的單向流控制，最小粒度可控制到 Pod 與 Pod，而不僅僅是 Namespace 級別的隔離。

在了解了 OpenShift 網絡模型之后，可以看到 OpenShift 網絡涉及的范圍大而復雜，除了 Pod 內部容器通信比較簡單、無需管理之外，其余的四部分都是可以配置管理的，如替換不同的插件或者通過不同的方式實現。

本文選自《OpenShift 在企業中的實踐》（第 2 版），經出版社授權發布。

推薦語：經典暢銷書再次升級！紅帽首席解決方案架構師聯合撰寫，20位全球知名企業IT負責人推薦，基于OpenShift v4，詳述PaaS、DevOps、云原生、微服務治理。完整描繪企業數字化轉型路線，為企業通過OpenShift實現IT轉型給出具體建議和參考架構。

總結

以上是生活随笔為你收集整理的解密OpenShift内部通信网络的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： hdu 4524 郑厂长系列故事——
下一篇： hdu 2570 迷障（贪心）