从微服务的工具集观点来看， Kubernetes本身是支持微服务的架构， 在Pod中部署微服务很合适， 也已经解决了微服务的互访互通问题， 但对服务间访问的管理如服务的熔断、 限流、 动态路由、 调用链追踪等都不在Kubernetes的能力范围内
Kubernetes的Service基于每个节点的Kube-proxy从Kube-apiserver上获取Service和Endpoint 的信息， 并将对 Service 的请求经过负载均衡转发到对应的 Endpoint 上。 Kubernetes只提供了4层负载均衡能力， 无法基于应用层的信息进行负载均衡， 更不会提供应用层的流量管理， 在服务运行管理上也只提供了基本的探针机制， 并不提供服务访问指标和调用链追踪这种应用的服务运行诊断能力。
Istio的服务发现就是从Kube-apiserver中获取 Service和 Endpoint， 然后将其转换成 Istio服务模型的 Service 和 ServiceInstance， 但是其数据面组件不再是Kube-proxy， 而是在每个 Pod 里部署的 Sidecar， 也可以将其看作每个服务实例的13;Proxy。 这样， Proxy 的粒度就更细了， 和服务实例的联系也更紧密了， 可以做更多更细粒度的服务治理
Istio优势
1. 数据面
数据面Sidecar运行在Kubernetes的Pod里， 作为一个Proxy和业务容器部署在一起
2.统一服务发现
Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成， 省去了再搭一个类似Eureka 的注册中心的麻烦， 更避免了在 Kubernetes 上运行时服务发现数据不一致的问题。
3.基于Kubernetes CRD描述规则
Istio的所有路由规则和控制策略都是通过 Kubernetes CRD实现的， 因此各种规则策略对应的数据也被存储在 Kube-apiserver 中， 不需要另外一个单独的 APIServer 和后端的配置管理。
