【摘要】 本文基于Pilot服务发现Kubernetes部分源码重点介绍在Istio on Kubernetes环境下，如何基于Pilot的Adapter机制实现Istio管理的服务直接使用Kubernetes service来做统一服务发现，避免了其他微服务框架运行在Kubernetes环境时上下两套服务目录的局面。并以此为入口从架构、场景等方面总结下Istio和Kubernetes的结合关系。
前言
前面文章《Istio源码解析 Pilot服务发现的Adapter机制》结合Pilot的代码实现介绍了Istio的抽象服务模型和基于该模型的数据结构定义，了解到Istio上只是定义的服务发现的接口，并未实现服务发现的功能，而是通过Adapter机制以一种可扩展的方式来集成各种不同的服务发现。本文重点讲解Adapter机制在Kubernetes平台上的使用。即Istio+Kubernetes如何实现服务发现。 Istio的官方设计上特别强调其架构上的可扩展性，即通过框架定义与实现解耦的方式来集成各种不同的实现。如Pilot上的adapter机制集成不同的服务注册表，Mixer通过提供一个统一的面板给数据面Sidecar，后端可以通过模板定义的方式对接不同的Backend来进行各种访问管理。但就现阶段实现，从代码或者文档的细节去细看其功能，还是和Kubernetes结合最紧密。
Kubernetes和Istio的结合
从场景和架构上看Istio和Kubernetes都是非常契合的一种搭配。
首先从场景上看Kuberntes为应用负载的部署、运维、扩缩容等提供了强大的支持。通过Service机制提供了负载间访问机制，通过域名结合Kubeproxy提供的转发机制可以方便的访问到对端的服务实例。因此如上图可以认为Kubernetes提供了一定的服务发现和负载均衡能力，但是较深入细致的流量治理能力，因为Kubnernetes所处的基础位置并未提供，而Istio正是补齐了这部分能力，两者的结合提供了一个端到端的容器服务运行和治理的解决方案。 从架构看Istio和Kubernetes更是深度的结合。 得益于Kuberntes Pod的设计，数据面的Sidecar作为一种高性能轻量的代理自动注入到Pod中和业务容器部署在一起，接管业务容器的inbound和outbound的流量，从而实现对业务容器中服务访问的治理。在控制面上Istio基于其Adapter机制集成Kubernetes的域名，从而避免了两套名字服务的尴尬场景。
基于Kubernetes的服务发现
理解了Pilot的ServiceDiscovery的Adapter的主流程后，了解这部分内容比较容易。Pilot-discovery在initServiceControllers时，根据服务注册配置的方式，如果是Kubernetes，则会走到这个分支来构造K8sServiceController。
