[Day15] 如何將Cluster內的服務互相溝通

第 11 屆 iThome 鐵人賽

DAY 15

DevOps

Kubernetes and Istio 三十天系列第 15 篇

11th鐵人賽

sleepdragon

2019-10-01 22:57:56

4171 瀏覽

前言

終於寫了一半，前面感覺偷懶許多XD。把Istio大約的服務都有簡單介紹過了，接下來就會是很細節的去介紹不同的Istio服務以及有哪些變化或應用。今天就先以如何將Cluster內的服務互相溝通為主軸。

Pod To Pod(Service To Service)

Kubernetes Cluster內部各個Pod之間(Pod To Pod)(Service To Service)如何相互訪問

Cluster IP

Kubernetes以Pod作為Deployment的最小單位。Kubernetes會根據Pod的Deployment對其進行調度，包括創建、銷毀、遷移、水平伸縮等，因此Pod的IP地址不是固定的，不方便直接采用Pod IP對服務進行訪問。

為解決該問題，Kubernetes提供了Service資源，Service對提供同一個服務的多個Pod進行聚合。一個Service提供一個虛擬的Cluster IP，後端對應一個或者多個提供服務的Pod。在集群中訪問該Service時，采用Cluster IP即可，Kube-proxy負責將發送到Cluster IP的請求轉發到後端的Pod上。

Kube-proxy目前共有三種模式可以選擇，預設為space proxy

space proxy

space

Kube-proxy會為每一個Service創建一個Listen端口。發向Cluster IP的請求被Iptables規則重定向到Kube-proxy監聽的端口上，Kube-proxy根據Load balancer算法選擇一個提供服務的Pod並和其建立鏈接，將請求轉發到Pod上。
Kube-proxy充當了一個L4 Load balancer的角色。由於Kube-proxy運行在space proxy中，在進行轉發處理時會增加兩次內核和用戶空間之間的數據拷貝，效率較另外兩種模式低一些；好處是當後端的Pod不可用時，kube-proxy可以重試其他Pod。

iptables proxy

iptables

為了避免增加內核和用戶空間的數據拷貝操作，提高轉發效率，Kube-proxy提供了iptables模式，Kube-proxy為service後端的每個Pod創建對應的iptables規則，直接將發向Cluster IP的請求重定向到一個Pod IP。
Kube-proxy不承擔L4代理的角色，只負責創建iptables規則。優點是比space proxy效率更高，但不能提供靈活的Load balancer策略，當後端Pod不可用時也無法進行重試。

ipvs proxy

ipvs

跟iptables proxy類似，Kube-proxy監控Pod的變化並創建相應的ipvs rules。ipvs也是在kernel模式下通過netfilter實現的，但采用了hash table來儲存ipvs rules，因此在規則較多的情況下，Ipvs相對iptables轉發效率更高。除此以外，ipvs支持更多的Load balancer算法。如果要設置kube-proxy為ipvs模式，必須在OS中也有安裝IPVS kernel modules。

上面幾種都是應用在Kube-Proxy的Service，之前已經有分享過Kube-Proxy並不能滿足我們目前服務的需求，至於為什麼可以參考這篇[Day03]為什麼我們要用Istio，Native Kubernetes有什麼做不到

Istio Sidecar Envoy Proxy

Istio Sidecar Proxy

Cluster IP可以Kubernetes Service之間相互訪問的問題，但從上面Kube-proxy的三種模式可以看到，Cluster IP的方式只提供了Servcie Discovery和基本的Load balancer功能。如果要為Service間的Route Rule以及Metrics collection，distributed tracing等功能,就必須得依靠Istio提供的Service Mesh。

在Kubernetes中部署Istio後，Istio通過iptables和Sidecar Proxy接管Service之間的通信，Service間的相互通信不再通過Kube-proxy，而是通過Istio的Sidecar Proxy(Envoy Proxy)進行。流程是這樣的：Client發起的請求被iptables重定向到Sidecar Proxy，Sidecar Proxy根據從Istio Control Plane獲取的VirtualService和DestinationRule，選擇一個Service Pod進行連接。

Istio Sidecar Proxy和Kube-proxy的space proxy運作機制類似，都是通過在不同Namespace的Service來轉發Client的請求和後端多個Pod之間的負載均衡。兩者的不同點是：Kube-Proxy工作在四層，而Sidecar Proxy則是一個L7 Proxy，可以針對HTTP，gRPC等L7進行處理和轉發，因此功能更為強大，可以有更加靈活的Route rules等功能。