爱豆吧!

idouba@beta.

Istio技术与实践02:源码解析之Istio on Kubernetes 统一服务发现

【摘要】 本文基于Pilot服务发现Kubernetes部分源码重点介绍在Istio on Kubernetes环境下,如何基于Pilot的Adapter机制实现Istio管理的服务直接使用Kubernetes service来做统一服务发现,避免了其他微服务框架运行在Kubernetes环境时上下两套服务目录的局面。并以此为入口从架构、场景等方面总结下Istio和Kubernetes的结合关系。

前言

文章Istio技术与实践01: 源码解析之Pilot多云平台服务发现机制结合Pilot的代码实现介绍了Istio的抽象服务模型和基于该模型的数据结构定义,了解到Istio上只是定义的服务发现的接口,并未实现服务发现的功能,而是通过Adapter机制以一种可扩展的方式来集成各种不同的服务发现。本文重点讲解Adapter机制在Kubernetes平台上的使用。即Istio on Kubernetes如何实现服务发现。

Kubernetes和Istio的结合Kubernetes和Istio的结合

从场景和架构上看Istio和Kubernetes都是非常契合的一种搭配。从场景和架构上看Istio和Kubernetes都是非常契合的一种搭配。

首先从场景上看Kuberntes为应用负载的部署、运维、扩缩容等提供了强大的支持。通过Service机制提供了负载间访问机制,通过域名结合Kubeproxy提供的转发机制可以方便的访问到对端的服务实例。因此如上图可以认为Kubernetes提供了一定的服务发现和负载均衡能力,但是较深入细致的流量治理能力,因为Kubnernetes所处的基础位置并未提供,而Istio正是补齐了这部分能力,两者的结合提供了一个端到端的容器服务运行和治理的解决方案。

从架构看Istio和Kubernetes更是深度的结合。 得益于Kuberntes Pod的设计,数据面的Sidecar作为一种高性能轻量的代理自动注入到Pod中和业务容器部署在一起,接管业务容器的inbound和outbound的流量,从而实现对业务容器中服务访问的治理。在控制面上Istio基于其Adapter机制集成Kubernetes的域名,从而避免了两套名字服务的尴尬场景。

在本文中将结合Pilot的代码实现来重点描述图中上半部分的实现,下半部分的内容Pilot提供的通用的API给Envoy使用可参照上一篇文章的DiscoverServer部分的描述。

理解了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特有的服务发现能力就介绍完了。即kube\controller也实现了ServiceDiscovery中规定的服务发现的接口中定义的全部发方法。除了初始化了一个kube controller来从Kubeapiserver中获取和维护服务发现数据外,在pilot server初始化的时候,还有一个重要的initDiscoveryService初始化DiscoveryServer,这个discoveryserver使用contrller,其实是ServiceDiscovery上的服务发现供。发布成通用协议的接口,V1是rest,V2是gRPC,进而提供服务发现的能力给Envoy调用,这部分是Pilot服务发现的通用机制,在上篇文章的adapter机制中有详细描述,这里不再赘述。

以上介绍了istio基于Kubernetes的名字服务实现服务发现的机制和流程。整个调用关系如下,可以看到和其他的Adapter实现其实类似。

  • Discoveryserver基于Controller上维护的服务发现数据,发布成gRPC协议的服务供Envoy使用。

前面只是提到了服务发现的数据维护,可以看到在Kubernetes场景下,Istio只是是使用了kubeAPIServer中service这种资源对象。在执行层面,说到Service就不得不说Kuberproxy,因为Service只是一个逻辑的描述,真正执行转发动作的是Kubeproxy,他运行在集群的每个节点上,把对Service的访问转发到后端pod上。在引入Istio后,将不再使用Kubeproxy做转发了,而是将这些映射关系转换成为pilot的转发模型,下发到envoy进行转发,执行更复杂的控制。这些在后面分析Discoveryserver和Sidecar的交互时再详细分析。

在和Kubnernetes结合的场景下强调下几个概念:

Istio的治理Service就是Kubernetes的Service。不管是服务描述的manifest还是存在于服务注册表中服务的定义都一样。 Istio治理的是服务间的通信。这里的服务并不一定是所谓的微服务,并不在乎是否做了微服务化。只要有服务间的访问,需要治理就可以用。一个大的单体服务打成一个镜像在Kuberntes里部署起来被其他负载访问和分拆成微服务后被访问,在治理看来没有任何差别。

本文只是描述了在服务发现上两者的结合,随着分析的深入,会发现Istio和Kubernetes的更多契合。K8s编排容器服务已经成为一种事实上的标准;微服务与容器在轻量、快速部署运维等特征的匹配,微服务运行在容器中也正成为一种标准实践;随着istio的成熟和ServiceMesh技术的流行,使用Istio进行微服务治理的实践也正越来越多;而istio和k8s的这种天然融合使得上面形成了一个完美的闭环。对于云原生应用,采用kubernetes构建微服务部署和集群管理能力,采用Istio构建服务治理能力,也将成为微服务真正落地的一个最可能的途径。有幸参与其中让我们一起去见证和经历这个趋势吧。

注:文中代码基于commit:505af9a54033c52137becca1149744b15aebd4ba