1.2.2　Kubernetes與Service Mesh

圖1-1所示為Kubernetes原生與Service Mesh的服務訪問關系（每個Pod中部署一個Sidecar的模式）。

1.流量轉發

Kubernetes集群的每個節點都部署了一個kube-proxy組件，該組件會先與Kubernetes API Server通信，獲取集群中的service信息，再設置iptables規則，直接將對某個service的請求發送到對應的Endpoint（屬于同一組service的Pod）上。

圖1-1

2.服務發現

Istio服務網格不僅可以沿用Kubernetes中的service做服務注冊，還可以通過控制平面的平臺適配器對接其他服務發現系統，生成數據平面的配置（使用CRD聲明，保存在etcd中）。數據平面的透明代理（Transparent Proxy）以Sidecar容器的形式部署在每個應用服務的Pod中，這些Proxy都需要請求控制平面同步代理配置。之所以說是透明代理，是因為應用程序容器完全沒有感知代理的存在，在該過程中kube-proxy組件一樣需要攔截流量，只不過kube-proxy組件攔截的是進出Kubernetes節點的流量，而Sidecar Proxy攔截的是進出該Pod的流量。圖1-2所示為Istio中的服務發現機制。

圖1-2

3.服務網格的劣勢

由于Kubernetes的每個節點都會運行眾多的Pod，因此將原先kube-proxy方式的路由轉發功能置于每個Pod中，會導致大量的配置分發、同步和最終一致性問題。為了細粒度地進行流量管理，必須添加一系列新的抽象，從而導致用戶的學習成本進一步增加，但隨著技術的普及，該情況會慢慢得到緩解。

4.服務網格的優勢

kube-proxy的設置都是全局生效的，無法對每個服務做細粒度的控制，而服務網格通過Sidecar Proxy的方式將Kubernetes中對流量的控制從service一層抽離出來，做更多的擴展。