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一层抽离出来，做更多的扩展。