伴随着非侵入式微服务技术Service Mesh服务网格的兴起，其解决了侵入式微服务框架的相关问题，实现了语言无关，对应用透明等能力。因此越来越多的开发者逐渐由传统的侵入式微服务解决方案（典型的技术方案为Spring Cloud）转变为Service Mesh微服务解决方案。

作为Service Mesh领域的热门开放项目，Istio为微服务提供无侵入的流量管理，安全通信，服务可见性等服务治理能力，目前Istio也基本成为了Service Mesh领域的事实标准。微服务项目开始考虑将自己的微服务应用向Istio进行迁移。

基于上述背景，Istio中的替代服务发现主要基于Kubernetes Service来实现，同时结合百度云原生技术团队内部外部实践落地的场景，即发现部分开发者仍然希望使用第三方注册中心的现状，那么对于非Kubernetes Service上的服务数据应该如何分割到Istio中呢？

为解决这类问题，根本需要解决的问题为【服务发现】，即Service Mesh中微服务能够发现非Kubernetes Service中的服务，Istio则需要对接支持第三方注册中心。

本文以Istio控制面对接第三方注册中心Consul，为读者介绍Istio如何对接Consul注册中心以及具体的实践过程，同时为Istio如何对接第三方注册中心提供技术思路。

本文假设读者对Kubernetes，Service Mesh，Helm等有一定的了解，若您还尚未了解，请查阅相关资料。同时本文主要讲解Istio对接Consul注册中心，因此希望读者对Consul作为注册中心等基础知识有一定的了解。

如果您尚未了解Consul相关内容，请参考我们之前的公众号文章：Consul作为注册中心在云环境的实践与应用。

Istio中服务发现机制

默认服务发现机制

我们先看看Istio的主要架构：

控制面板（控制平面）：负责数据下发，如服务/服务实例数据，服务治理配置数据。
数据面板（数据平面）：高级代理负责具体的流量治理。

如下图，Istio部署在Kubernetes平台后，替换的服务/服务实例数据布局Kubernetes Service，Istio控制面板（控制平面）列表监视Kubernetes中服务/服务实例数据，当数据发生变化后，Istio控制平面将数据通过XDS方式推送至数据面板（数据平面）中的Proxy。的服务无法调用Consul中部署的服务。

对接第三方注册中心的方式

通过查阅Istio官方文档及相应代码，发现Istio目前有如下三种方式对接第三方注册中心：

对接Consul注册中心方式

整体架构

如本文前言所述，现存的应用程序对接的注册中心可能仍为第三方注册中心Consul，因此如何将Conss上的服务/服务实例数据替换到Istio中呢？

这要求Istio控制平面能够对接Consul注册中心，考虑到成本最小化，此处使用官方提供的Consul RegistryAdapter。Istio启动后控制平面从Consul获取服务/服务实例数据，考虑到Consul中服务/服务实例的变更时效性，Istio控制面通过Long Polling的方式监听Consul XML中心的数据变化。

如下图所示将 Consul 上的服务数据纳入到了Istio 中。

Consul XML适应Istio

在K8S中资源都可以绑定label信息，那么在Consul中服务/服务实例的label信息具体怎样添加呢？
通过查看Consul API 注册服务接口，我们发现服务注册模型中有两个位置可以携带上述标签信息，分别为：

Tags (array: nil) -指定要分配给服务的标签列表。这些标签可用于以后的过滤，并通过API公开。我们建议使用有效的DNS标签以与外部DNS兼容
Meta(map<string|string>: nil) -指定链接到服务实例的任意KV元数据。

通过官方文档说明，我们还不能完全知道label应该具体如何搬运，但通过查阅Istio Pilot代码后，我们发现label可携带在标签中和每个label的键和值按照分割符“ |” 分割，具体的实现代码逻辑（代码位置：consul.conversion.go）如下：

func convertLabels(labelsStr []string) labels.Instance {   out := make(labels.Instance, len(labelsStr))   for _, tag := range labelsStr {      // 按照 | 分割符号进行分割KV信息      vals := strings.Split(tag, "|")      // Labels not of form "key|value" are ignored to avoid possible collisions      if len(vals) > 1 {         out[vals[0]] = vals[1]      } else {         log.Debugf("Tag %v ignored since it is not of form key|value", tag)      }   }   return out}func convertLabels(labelsStr []string) labels.Instance {
   out := make(labels.Instance, len(labelsStr))
   for _, tag := range labelsStr {
      // 按照 | 分割符号进行分割KV信息
      vals := strings.Split(tag, "|")
      // Labels not of form "key|value" are ignored to avoid possible collisions
      if len(vals) > 1 {
         out[vals[0]] = vals[1]
      } else {
         log.Debugf("Tag %v ignored since it is not of form key|value", tag)
      }
   }
   return out
}

因此，在服务注册时，需要将标签信息存放在标签中，同时按照分割符“ |” 分割，如“ tag1 | value1”，如下为具体服务注册注册Service接口的一个例子：

{
  "ID": "instance-c7ac82ae14ef42d1a4ffa3b2ececa17f-local-provider-demo-172-22-204-83-provider-demo-10001",  #Instance ID确保一个region唯一
  "Name": "provider-demo",  # 服务名
  "Tags": [
    "tag1|value1",               # 标签
    "protocol|http"              # 标明其为http服务
  ],
  "Address": "127.0.0.1",   # 服务ip地址
  "Port": 9999,             # 服务提供服务端口号
  "Meta": {                 # metadata信息，kv形式
    "protocol": "http"      # 标明其为http服务                
  },
  "Check": {            
    "TTL": "30s",                          # TTL健康检查
    "deregisterCriticalServiceAfter": "30s"  # 异常服务下线
  }
}

实践篇

本文实践部署的版本分别为：

领事1.6.1
Istio 1.6.8

领事部署

领事部署安装的途径有多种，本文中采用头盔在K8S环境中安装领事方式其他请参考官方安装文档。

下载头盔包

K8S环境中安装Consul时，官方推荐的方式为通过Helm来进行安装，为保证安装的顺利进行，建议您安装Helm 3，Helm安装完成后，下载consul-helm （https://github.com/hashicorp / consul-helm）Helm包来安装Consul。

安装领事

通常来说，配置无法满足实际的需求，因此可以通过自定义配置config.yaml文件覆盖配置配置达到定制化安装的目的：

# 通过覆盖默认配置达到定制化安装目的
$ helm install consul ./consul-helm -f config.yaml -n test

下面指定一个笔者实践的配置config.yaml：

ui:
  service:
    type: 'NodePort'  # Consul UI界面通过NodePort的形式访问
connectInject:
  enabled: false      # 关闭consul connectInject功能
client:
  enabled: false       # 关闭consul client节点模式，即所有的节点为consul server
# Use only one Consul server for local development
server:
  enabled: true
  storage: 1Gi                    # 自定义的strage信息
  storageClass: rook-ceph-block
  replicas: 1                     # 定义的副本信息，生产环境中建议为3个
  bootstrapExpect: 1              # Consul集群正常启动时预期的节点数量，即集群中节点数目达到该数目时才正常选举启动
  disruptionBudget:
    enabled: true
    maxUnavailable: 0

注：若您想要配置更多Consul的功能，请参考：Helm Chart Reference（https://www.consul.io/docs/k8s/helm）。

安装后查看服务信息，可以看到consul-consul-ui的访问方式为NodePort，其对应的端口为30267，即后续可以通过http：// {node_ip}：30267访问注册中心。

$kubectl get service -n test
consul-consul-dns      ClusterIP   10.20.62.108    <none>   53/TCP,53/UDP                                                           8m38s
consul-consul-server   ClusterIP   None            <none>   8500/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8300/TCP,8600/TCP,8600/UDP   8m38s
consul-consul-ui       NodePort    10.20.154.128   <none>   80:30267/TCP

Istio部署

下载安装包

在下载页下载安装包，注意选择对应的操作系统安装包，本文以的MacOS为例下载了istio-1.6.8-osx.tar.gz，解压后进入istio目录。

# 进入istio目录，其中目录samples目录用于存放示例Bookinfo Application，bin目录存放istioctl命令，manifests用于存放的安装清单文件
$ cd istio-1.6.8

将istioctl命令加入路径

$ export PATH=$PWD/bin:$PATH

安装Istio并集成领事

Istio 1.6中组件已经完成了精简，即Istio之前版本的多种组件已经完全统一至Istiod中，因此我们通过引用Istio官方文档对pilot-discovery （控制面主要实现）命令参数说明，发现了对接Consul XML中心的参数说明：

即通过pilot -discovery --registries = Consul — consulserverURL = http：// { {node_ip}}：39267 / ，但是这些参数具体在哪里配置呢？

通过对官方文档查阅，发现可以自定义清单来完成安装，我们修改清单yaml来指定参数：

# 文件位置：istio-1.6.8/manifests/charts/istio-control/istio-discovery/templates
...
  containers:
        - name: discovery
          image: pilot:dev  # 本文中修复了Consul数据变更后Istio推送失效的问题，因此重新构建了镜像
{{- if .Values.global.imagePullPolicy }}
          imagePullPolicy: {{ .Values.global.imagePullPolicy }}
{{- end }}
          args:
          - "discovery"
          - --monitoringAddr=:15014
          - --registries=Kubernetes,Consul  # 考虑后面要部署BookInfo Application，因此可以对接多个注册中心，即Kubernetes和Consul,读者可根据实际情况选择集成那种注册中心
          - --consulserverURL=http://{node_ip}:30267  # 注意{node_ip}需要替换为具体的地址
...

修改完成后完成最终部署：

# 注意此处profile=demo本质上对应了一系列的安装清单文件，manifests 目录中的清单文件夹manifests中文件会对默认的profile demo的内容进行覆盖配置安装
$ istioctl install --charts=./manifests --set profile=demo

最终我们在default命令空间下开启自动注入Sidecar功能：

$ kubectl label namespace default istio-injection=enabled

为验证XDS规则等下发情况，我们参考官方Bookinfo应用程序文档部署了示例。同时部署了服务provider-demo，其注册在Consul注册中心上。

踩坑篇

对接过程发现了两个问题：

XDS变更变更失效，即Consul XML中心的中心。
Istio无法对接开启开启ACL鉴权认证的Consul注册中心。

XDS变更引导为何失效

当部署完BookInfo应用程序示例后，通过重新修改Consul上的服务provider-demo实例信息，笔者满心欢喜进入istio-proxy容器访问 http://127.0.0.1:15000/config_dump 查询envoy configdump中的数据，有望能够将Consul XML中心上更改的服务provider-demo在envoy configdump中查询到，但查询数据发现更改的服务数据provider-demo无需通过XDS完成更改替换，这是什么原因呢？带着这样的疑问，笔者决定调试一下代码。

通过代码调试发现（代码位置：bootstrap.server.go），领事服务数据发生变化后，已经引起数据变更事件，但对应的PushRequest.ConfigUpdated中ConfigKey.Name始终不正确，该些主要表明具体的那个那个服务发生了变化，以服务provier-demo变更为例，预期该插入的变量为“ provider-demo.service.consul”，而实际却是“ .service.consul”，最终导致该数据被推前【被误判为不应该下发该数据]，最终导致变更数据没有通过XDS进行下发。

该问题笔者在Istio代码的基础上完成了修改并完成重新重组验证，现有该问题已经修改，后续笔者也将会将提炼反馈给Istio社区。

如何对接开启了ACL认证鉴权的Consul注册中心

生产环境中的Consul注册中心经常都开启了ACL认证鉴权，但笔者在对接过程发现中Istio控制面代码标记并没设置设置Consul ACL令牌的配置项，笔者修改了Istio代码设置Consul令牌，用于处理从Consul注册中心获取数据，目前已经能够支持对接开启了ACL鉴权认证的Consul注册中心，后续笔者也会将PR反馈给Istio社区。

笔者通过亲身实践，发现Istio对接第三方注册中心尤其是对接Consul注册中心目前还存在一些功能问题待解决，后续笔者也将问题和解决方案及时反馈给社区，推动该问题的解决，同时希望更多的人能参与其中共建繁荣的Istio社区。
笔者有幸经历了百度由传统的微服务框架Spring Cloud（Java生态中微服务一体化解决方案）向Service Mesh（服务网格，转变微服务一体化解决方案）架构的转变，实践了将第三方注册中心Consul集成至Istio的生态中，望此能够让读者对Istio集成第三方注册中心Consul有一定的了解。

附录：
《什么是Istio？》：https：//istio.io/v1.6/docs/concepts/what-is-istio/
《在Kubernetes上安装Consul》：https：//www.consul.io/docs/k8s/installation/install
《快速入门》：https：//istio.io/v1.6/docs/setup/getting-started/

作者简介：
刘超，百度研发工程师，现就职于百度基础架构部云原生团队，并和参与百度内部外部多个大规模微服务化改造，专注于微服务及云原生领域相关技术，对Spring Cloud ，服务网格，Istio，领事等方向有深入的研究和实践。

创作场景

Istio 控制面对接 Consul 注册中心