Kubernetes 系列（四十六）東西向通信（Service to Service）

Kubernetes 系列（四十六）Kubernetes 中東西向通信（Service to Service）

詳細了解3個涉及 service to service 通信的原生k8s對象：ClusterIP Service 、DNS 和 Kube Proxy。

在我上一篇文章 “Kubernetes中的南北通信” 中，我寫到了客戶機如何在叢集中通路服務。一旦進入叢集，我們現在就可以看到後端服務如何在叢集内互相通信。

傳統 service-to-service 通信

在進入Kubernetes生态系統之前，先快速了解一下傳統的服務到服務通信——通信是通過IP位址進行的，是以為了讓服務 A 調用服務 B，一種方法是為服務B配置設定一個靜态IP位址。現在，要麼服務A已經知道這個IP位址（這在處理非常少的服務時可能有效），要麼服務B使用域名注冊自己，服務A通過 DNS 查找獲得服務 B 的聯系位址。

Kubernetes 網絡模型

現在在Kubernetes叢集中，我們有一個控制平面，它構成了叢集管理元件和一組稱為節點的工作機器。這些節點托管Pods，這些Pods将後端微服務作為容器化服務運作。叢集内的Pod到Pod通信就是 k8s 的網絡模型。

根據Kubernetes網絡模型-

1. 1. 叢集中的每個 pod 都有自己獨特的叢集範圍内的 IP 位址
2. 2. 叢集内所有 pod 可以互相通信,
3. 3. 通信在沒有 NAT 的情況下進行，這意味着目标 pod 可以看到源 pod 的真實 IP 位址。Kubernetes 認為容器網絡或其上運作的應用程式是可信的，不需要在網絡級别進行身份驗證，當然叢集也支援類似的 NetworkPolicy 進行通路控制。

ClusterIP service — 對 Pod 的持久抽象

由于叢集中的每個 pod 都有自己的IP位址，是以一個 pod 應該很容易與另一個pod通信？不，因為Pods 是不穩定的，每次建立一個Pod 都會得到一個新的 IP 位址。是以，用戶端服務必須以某種方式切換到下一個可用的 pod，這是不可取的。

Pod 直接互相通路需要面臨的問題是：pod IP 位址的短暫性以及如何發現其他關聯的一組 pod

是以，Kubernetes 可以在一組 Pod 之上建立一個層，該層可以為該組提供單一 IP 位址，并提供基本的負載均衡。

Pods 通過持久 IP 位址上的 Cluster IP 類型服務暴露用戶端與服務對話，而不是直接與Pods 對話

這個抽象由 Kubernetes 中名為ClusterIP Service 的服務對象提供。它在多個節點上産生，進而在叢集内建立單個服務。它可以在任何端口上接收請求，并将其轉發到pod上的任何端口。是以，當應用程式服務 A 需要與服務 B 通信時，它調用服務 B 對象的ClusterIP服務，而不是運作服務的單個pod。ClusterIP 使用 Kubernetes 中标簽和選擇器的标準模式來持續掃描符合選擇标準的pod。Pod 有标簽，服務用選擇器來查找标簽。使用這一點，就有可能實作一個基本的流量分割，即微服務的舊版本和新版本在同一個叢集IP服務後面共存。

CoreDNS — 叢集中的服務發現

雖然服務 B 已經獲得了一個持久的IP位址，服務 A 仍然需要知道這個 IP 位址是什麼，然後才能與服務B通信。Kubernetes 支援使用 CoreDNS 進行名稱解析。服務 A 應該知道它需要與之通信的 ClusterIP 的名稱（&port）。

1. 1. CoreDNS 會掃描叢集，每當建立 ClusterIP 服務時，它的條目就會添加到DNS伺服器（如果配置了，它還會為每個pod 添加一個條目，但與服務到服務的通信無關）。
2. 2. 接下來，CoreDNS 将自己暴露為一個ClusterIP 服務（預設情況下稱為kube dns），該服務被配置為 pods 中的名稱伺服器。
3. 3. 發起請求的 Pod從 DNS 擷取 ClusterIP服務的 IP 位址，然後可以使用IP位址和端口發起請求。

Services 通過<host name>.<name of namespace>.<type>.<root>來識别。

Kube-proxy — ClusterIP 服務和背景Pods之間的連結（目标網絡位址轉換）

到目前為止，從本文來看，似乎是ClusterIP服務将調用轉發到後端Pods。但實際上，這是由Kube-proxy 完成的。Kube-proxy 在每個節點上運作，并監視服務及其背景Pod（實際上是端點對象）。

1. 1. 當節點上運作的 pod 向ClusterIP服務送出請求時，kube-proxy 會攔截它。
2. 2. 通過檢視目标 IP 位址和端口，它可以識别目标ClusterIP服務。它将此請求的目的地替換為一個端點的位址，在該端點上存在用于服務請求的實際Pod。

它們是如何正在協同工作的?

ClusterIP 服務、CoreDNS、用戶端Pod、Kube-proxy、端點和目标服務Pod的互動

1. 1. 目标的 ClusterIP 服務已在 CoreDNS 中注冊
2. 2. DNS解析：每個pod 都有一個 resolve.conf 檔案，其中包含 CoreDNS 服務的 IP 位址，pod執行DNS查找。
3. 3. Pod使用從 DNS 接收的 IP 位址和它已經知道的端口來調用 ClusterIP 服務。
4. 4. 目标位址轉換：Kube-proxy 将目标 IP 位址更新為服務B的 Pod 可用的位址

總結

我們看到了本地 Kubernetes 對象，這些對象使服務到服務的通信成為可能。雖然這些細節對應用程式層是隐藏的，但最好知道在普通的Kubernetes中有什麼可用的，以及在什麼地方适合建構在Kubernetes之上的平台/産品。