![]()
随着下一代非侵入式微服务技术 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 Control Panel（控制平面） List Watch Kubernetes 中 服务/服务实例数据，当数据发生变化后，Istio 控制平面将数据通过 XDS 方式推送至 Data Panel（数据平面）中的 Proxy 。注册在 Kubernetes Service 的服务可以正常互通访问，但对于传统的 Consul 注册中心上的服务暂无法纳入到 Istio 当中，也就造成了 Kubernetes 中部署的服务无法调用 Consul 中部署的服务 。
![]()
对接第三方注册中心的方式
通过查阅 Istio 官方文档及相应代码，发现 Istio 目前有如下三种方式对接第三方注册中心：
| 方式 |
说明 |
| Service Registry Adapter |
自定义适配器集成第三方注册中心，配器从第三方服务注册表中获取服务和服务实例，转换为Istio 内部的标准模型，官方已支持Consul。 |
| MCP Server |
自定义的 MCP Server 从第三方注册表中获取服务和服务实例，然后转换为 ServiceEntry 和 WorkloadEntry 资源，通过 MCP 协议提供给 Istio。 |
| ServiceEntry / WorkloadEntry |
从第三方法服务注册中心获取服务和服务实例数据，然后转换为 Istio 的 ServiceEntry 和 WorkloadEntry 资源，通过 Kubernetes API Server 的接口写入到 API Server 中。 |
对接 Consul 注册中心方式
如本文前言所述，现存的应用程序对接的注册中心可能仍为第三方注册中心 Consul ，因此如何将Consul 上的服务/服务实例数据纳入到 Istio 中呢？
这要求 Istio 控制平面能够对接 Consul 注册中心，考虑到成本最小化，本文使用 官方提供的Consul Registry Adapter。Istio 启动后控制平面从 Consul 获取服务/服务实例数据，考虑到 Consul 中服务/服务实例的变更时效性，Istio 控制面通过 Long Polling 的方式监听 Consul 注册中心上的数据变化。如下图所示将 Consul 上的服务数据纳入到了Istio 中。
![]()
在K8S中资源都可以绑定 label 信息，那么在 Consul 中服务/服务实例的 label 信息具体怎样添加呢？
通过查看 Consul API Register Service 接口，我们发现服务注册模型中有两个位置可以携带上述 label 信息，分别为：
-
Tags (array<string>: nil) - Specifies a list of tags to assign to the service. These tags can be used for later filtering and are exposed via the APIs. We recommend using valid DNS labels for compatibility with external DNS
-
Meta(map<string|string>: nil) - Specifies arbitrary KV metadata linked to the service instance.
通过官方文档说明，我们还不能完全知道 label 应该具体如何携带，但通过查阅 Istio Pilot 代码后，我们发现 label 可携带在 Tags 中并且每个 label 的 Key 和 Value 按照分割符 "|" 分割，具体的实现代码逻辑（代码位置：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
}
因此，在服务注册时，需要将 label 信息存放在 Tags 中，同时按照分割符 "|" 分割，如 " tag1|value1 "，如下为具体服务注册 Register 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" # 异常服务下线
}
}
实践篇
本文实践部署的版本分别为：
Ⅰ. Consul 部署
Consul 部署安装的途径有多种，本文中采用 Helm 在K8S环境中安装 Consul ，其他方式请参考官方安装文档。
K8S 环境中安装 Consul 时，官方推荐的方式为通过Helm来进行安装，为保证安装的顺利进行，建议您安装 Helm 3，Helm 安装完成后，下载 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。
安装后查看服务信息，可以看到 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 命令加入 path
$ export PATH=$PWD/bin:$PATH
Istio 1.6中组件已经完成了精简，即 Istio 之前版本的多种组件已经完全统一至 Istiod 中，因此我们通过查阅 Istio 官方文档对 pilot-discovery（控制面主要实现）命令参数说明，发现了对接 Consul 注册中心的参数说明：
| 参数 |
描述 |
| --registries <stringSlice> |
Comma separated list of platform service registries to read from (choose one or more from {Kubernetes, Consul, Mock}) (default `[Kubernetes]`) |
| --consulserverURL <string> |
URL for the Consul server (default ``) |
即通过 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 Application 文档部署了示例。同时部署了服务 provider-demo ，其注册在 Consul 注册中心上。
踩坑篇
对接过程发现了两个问题：
-
XDS 变更推送失效，即 Consul 注册中心上的服务服务/服务实例发生变化后，Istio 控制面没有通过 XDS 推送。
-
Istio 无法对接开启了 ACL 鉴权认证的 Consul 注册中心。
XDS 变更推送为何失效
当部署完 BookInfo Application 示例后，通过频繁修改 Consul 上的服务 provider-demo 实例信息，笔者满心欢喜进入 istio-proxy 容器访问 http://127.0.0.1:15000/config_dump 查询 envoy configdump 中的数据，预期能够将 Consul 注册中心上变更的服务 provider-demo 在 envoy configdump 中查询到，但查询数据发现变更的服务数据 provider-demo 并未通过XDS完成变更推送，这是什么原因呢？带着这样的疑问，笔者决定调试一下代码。
通过代码调试发现（代码位置: bootstrap.server.go ），Consul 服务数据发生变化后，已经引起数据变更事件，但对应的 PushRequest.ConfigUpdated中ConfigKey.Name 字段不正确，该字段主要表明具体的那个服务发生了变化，以服务 provier-demo 变更为例，预期该字段的值为 "provider-demo.service.consul" ，而实际却是 ".service.consul" ，最终导致该数据被 push 前【被误判为不应该下发该数据】，最终导致变更数据没有通过 XDS 进行下发。
![]()
该问题笔者在 Istio 代码的基础上完成了修改并完成重新构建镜像验证，目前该问题已经修改， 后续笔者也将会将提PR反馈给 Istio 社区。
如何对接开启了 ACL 认证鉴权的 Consul 注册中心
生产环境中的 Consul 注册中心往往都开启了 ACL 认证鉴权，但笔者在对接过程发现中 Istio 控制面代码层面并没预留设置 Consul ACL Token 的配置项，笔者修改了 Istio 代码设置 Consul Token，用于处理从 Consul 注册中心获取数据，目前已经能够支持对接开启了 ACL 鉴权认证的 Consul 注册中心， 后续笔者也会将 PR 反馈给 Istio 社区。
笔者通过亲身实践，发现 Istio 对接第三方注册中心尤其是对接 Consul 注册中心目前还存在一些功能问题待解决，后续笔者也将问题及解决方案及时反馈给社区，推动该问题的解决，同时希望更多的人能参与其中共建繁荣的 Istio 社区。
笔者有幸经历了百度由传统的微服务框架 Spring Cloud（Java生态中微服务一体化解决方案）向 Service Mesh（服务网格，下一代微服务一体化解决方案）架构的转变，实践了将第三方注册中心 Consul 集成至 Istio 的生态中，望本文能够让读者对 Istio 集成第三方注册中心 Consul 有一定的了解。
附录
-
《What is Istio?》：https://istio.io/v1.6/docs/concepts/what-is-istio/
-
《Installing Consul On Kubernetes》：https://www.consul.io/docs/k8s/installation/install
-
《Getting Started》：https://istio.io/v1.6/docs/setup/getting-started/
作者简介：刘超，百度研发工程师，现就职于百度基础架构部云原生团队，主导和参与百度内外部多项大规模微服务化改造，专注于微服务及云原生领域相关技术，对 Spring Cloud、Service Mesh、Istio、Consul 等方向有深入的研究和实践。
了解更多微服务、云原生技术的相关信息，请关注我们的微信公众号【云原生计算】！
![]()
