前言
文章Istio技术与实践01： 源码解析之Pilot多云平台服务发现机制结合Pilot的代码实现介绍了Istio的抽象服务模型和基于该模型的数据结构定义，了解到Istio上只是定义的服务发现的接口，并未实现服务发现的功能，而是通过Adapter机制以一种可扩展的方式来集成各种不同的服务发现。本文重点讲解Adapter机制在Kubernetes平台上的使用。即Istio on 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的域名，从而避免了两套名字服务的尴尬场景。
在本文中将结合Pilot的代码实现来重点描述图中上半部分的实现，下半部分的内容Pilot提供的通用的API给Envoy使用可参照上一篇文章的DiscoverServer部分的描述。
基于Kubernetes的服务发现
理解了Pilot的ServiceDiscovery的Adapter的主流程后，了解这部分内容比较容易。Pilot-discovery在initServiceControllers时，根据服务注册配置的方式，如果是Kubernetes，则会走到这个分支来构造K8sServiceController。
case serviceregistry.KubernetesRegistry:
s.createK8sServiceControllers(serviceControllers, args); err != nil {
return err
}
创建controller其实就是创建了一个Kubenernetes的controller，可以看到List/Watch了Service、Endpoints、Node、Pod几个资源对象。
// NewController creates a new Kubernetes controller
func NewController(client kubernetes.Interface, options ControllerOptions) *Controller {
out := &Controller{
domainSuffix: options.DomainSuffix,
client: client,
queue: NewQueue(1 * time.Second),
}
out.services = out.createInformer(&v1.Service{}, "Service", options.ResyncPeriod,
func(opts meta_v1.ListOptions) (runtime.Object, error) {
return client.CoreV1().Services(options.WatchedNamespace).List(opts)
},
func(opts meta_v1.ListOptions) (watch.Interface, error) {
return client.CoreV1().Services(options.WatchedNamespace).Watch(opts)
})
out.endpoints = out.createInformer(&v1.Endpoints{}, "Endpoints", options.ResyncPeriod,
func(opts meta_v1.ListOptions) (runtime.Object, error) {
return client.CoreV1().Endpoints(options.WatchedNamespace).List(opts)
},
func(opts meta_v1.ListOptions) (watch.Interface, error) {
return client.CoreV1().Endpoints(options.WatchedNamespace).Watch(opts)
})
out.nodes = out.createInformer(&v1.Node{}, "Node", options.ResyncPeriod,
func(opts meta_v1.ListOptions) (runtime.Object, error) {
return client.CoreV1().Nodes().List(opts)
},
func(opts meta_v1.ListOptions) (watch.Interface, error) {
return client.CoreV1().Nodes().Watch(opts)
})
out.pods = newPodCache(out.createInformer(&v1.Pod{}, "Pod", options.ResyncPeriod,
func(opts meta_v1.ListOptions) (runtime.Object, error) {
return client.CoreV1().Pods(options.WatchedNamespace).List(opts)
},
func(opts meta_v1.ListOptions) (watch.Interface, error) {
return client.CoreV1().Pods(options.WatchedNamespace).Watch(opts)
}))
return out
}
在 createInformer 中其实就是创建了SharedIndexInformer。这种方式在Kubernetes的各种Controller中广泛使用。Informer调用 APIserver的 List 和 Watch 两种类型的 API。在初始化的时，先调用 List API 获得全部资源对象，缓存在内存中; 然后，调用 Watch API 去 Watch这种这种资源对象，维护缓存。
Service informer := cache.NewSharedIndexInformer(
&cache.ListWatch{ListFunc: lf, WatchFunc: wf}, o,
resyncPeriod, cache.Indexers{})
下面看下Kubernetes场景下对ServiceDiscovery接口的实现。我们看下Kubernetes下提供的服务发现的接口，包括获取服务列表和服务实例列表。
func (c *Controller) GetService(hostname model.Hostname) (*model.Service, error) {
name, namespace, err := parseHostname(hostname)
item, exists := c.serviceByKey(name, namespace)
svc := convertService(*item, c.domainSuffix)
return svc, nil
}
最终是从infromer的缓存中获取Service资源对象。
func (c *Controller) serviceByKey(name, namespace string) (*v1.Service, bool) {
item, exists, err := c.services.informer.GetStore().GetByKey(KeyFunc(name, namespace))
return item.(*v1.Service), true
}
获取服务实例列表也是类似，也是从Informer的缓存中获取对应资源，只是涉及的对象和处理过程比Service要复杂一些。
func (c *Controller) InstancesByPort(hostname model.Hostname, reqSvcPort int,
labelsList model.LabelsCollection) ([]*model.ServiceInstance, error) {
// Get actual service by name
name, namespace, err := parseHostname(hostname)
item, exists := c.serviceByKey(name, namespace)
svc := convertService(*item, c.domainSuffix)
svcPortEntry, exists := svc.Ports.GetByPort(reqSvcPort)
for _, item := range c.endpoints.informer.GetStore().List() {
ep := *item.(*v1.Endpoints)
…
}
...
}
}
return nil, nil
}
可以看到就是做了如下的转换,将Kubernetes的对一个服务发现的数据结构转换成Istio的抽象模型对应的数据结构。
其实在conversion.go中提供了多个convert的方法将Kubernetes的数据对象转换成Istio的标准格式。除了上面的对Service、Instance的convert外，还包含对port，label、protocol的convert。如下面protocol的convert就值得一看。
func ConvertProtocol(name string, proto v1.Protocol) model.Protocol {
out := model.ProtocolTCP
switch proto {
case v1.ProtocolUDP:
out = model.ProtocolUDP
case v1.ProtocolTCP:
prefix := name
i := strings.Index(name, "-")
if i >= 0 {
prefix = name[:i]
}
protocol := model.ParseProtocol(prefix)
if protocol != model.ProtocolUDP && protocol != model.ProtocolUnsupported {
out = protocol
}
}
return out
}
看过Istio文档的都知道在使用Istio和Kuberntes结合的场景下创建Pod时要求满足4个约束。其中重要的一个是Port必须要有名，且Port的名字名字的格式有严格要求：Service 的端口必须命名，且端口的名字必须满足格式 <protocol>[-<suffix>]，例如name: http2-foo 。在K8s场景下这部分我们一般可以不对Pod命名的，看这段解析的代码可以看服务的Protocol是从name中解析出来的。如果Service的protocol是UDP的，则协议UDP；如果是TCP的，则会从名字中继续解析协议。如果名称是不可识别的前缀或者端口上的流量就会作为普通的 TCP 流量来处理。
另外同时在Informer 中添加对add、delete、和update事件的回调，分别对应 informer 监听到创建、更新和删除这三种事件类型。可以看到这里是将待执行的回调操作包装成一个task，再压到Queue中，然后在Queue的run()方法中拿出去挨个执行，这部分不细看了。
到这里Kuberntes特有的服务发现能力就介绍完了。即kubecontroller也实现了ServiceDiscovery中规定的服务发现的接口中定义的全部发方法。除了初始化了一个kube controller来从Kubeapiserver中获取和维护服务发现数据外，在pilot server初始化的时候，还有一个重要的initDiscoveryService初始化DiscoveryServer，这个discoveryserver使用contrller，其实是ServiceDiscovery上的服务发现供。发布成通用协议的接口，V1是rest，V2是gRPC,进而提供服务发现的能力给Envoy调用，这部分是Pilot服务发现的通用机制，在上篇文章的adapter机制中有详细描述，这里不再赘述。
总结
以上介绍了istio基于Kubernetes的名字服务实现服务发现的机制和流程。整个调用关系如下，可以看到和其他的Adapter实现其实类似。
1. KubeController使用List/Watch获取和维护服务列表和其他需求的资源对象，提供转换后的标准的服务发现接口和数据结构；
2. Discoveryserver基于Controller上维护的服务发现数据，发布成gRPC协议的服务供Envoy使用。
前面只是提到了服务发现的数据维护，可以看到在Kubernetes场景下，Istio只是是使用了kubeAPIServer中service这种资源对象。在执行层面，说到Service就不得不说Kuberproxy，因为Service只是一个逻辑的描述，真正执行转发动作的是Kubeproxy，他运行在集群的每个节点上，把对Service的访问转发到后端pod上。在引入Istio后，将不再使用Kubeproxy做转发了，而是将这些映射关系转换成为pilot的转发模型，下发到envoy进行转发，执行更复杂的控制。这些在后面分析Discoveryserver和Sidecar的交互时再详细分析。
在和Kubnernetes结合的场景下强调下几个概念：
1. Istio的治理Service就是Kubernetes的Service。不管是服务描述的manifest还是存在于服务注册表中服务的定义都一样。
2. Istio治理的是服务间的通信。这里的服务并不一定是所谓的微服务，并不在乎是否做了微服务化。只要有服务间的访问，需要治理就可以用。一个大的单体服务打成一个镜像在Kuberntes里部署起来被其他负载访问和分拆成微服务后被访问，在治理看来没有任何差别。
本文只是描述了在服务发现上两者的结合，随着分析的深入，会发现Istio和Kubernetes的更多契合。K8s编排容器服务已经成为一种事实上的标准；微服务与容器在轻量、快速部署运维等特征的匹配，微服务运行在容器中也正成为一种标准实践；随着istio的成熟和ServiceMesh技术的流行，使用Istio进行微服务治理的实践也正越来越多；而istio和k8s的这种天然融合使得上面形成了一个完美的闭环。对于云原生应用，采用kubernetes构建微服务部署和集群管理能力，采用Istio构建服务治理能力，也将成为微服务真正落地的一个最可能的途径。有幸参与其中让我们一起去见证和经历这个趋势吧。
注：文中代码基于commit：505af9a54033c52137becca1149744b15aebd4ba