内部通訊-Sidecar Proxy

Istio Sidecar Proxy

Cluster IP解決了服務之間互相通路的問題，但從上面Kube-proxy的三種模式可以看到，Cluster IP的方式隻提供了服務發現和基本的LB功能。如果要為服務間的通信應用靈活的路由規則以及提供Metrics collection，distributed tracing等服務管控功能,就必須得依靠Istio提供的服務網格能力了。

在Kubernetes中部署Istio後，Istio通過iptables和Sidecar Proxy接管服務之間的通信，服務間的互相通信不再通過Kube-proxy，而是通過Istio的Sidecar Proxy進行。請求流程是這樣的：Client發起的請求被iptables重定向到Sidecar Proxy，Sidecar Proxy根據從控制面擷取的服務發現資訊和路由規則，選擇一個後端的Server Pod建立連結，代理并轉發Client的請求。

Istio Sidecar Proxy和Kube-proxy的userspace模式的工作機制類似，都是通過在使用者空間的一個代理來實作用戶端請求的轉發和後端多個Pod之間的負載均衡。兩者的不同點是：Kube-Proxy工作在四層，而Sidecar Proxy則是一個七層代理，可以針對HTTP，GRPS等應用層的語義進行處理和轉發，是以功能更為強大，可以配合控制面實作更為靈活的路由規則和服務管控功能。

Istio Sidecar Proxy