第三方注取不了 Istio 控制面对接 Consul 注册中心
专业出黑
随着下一代非侵入式微服务技术 Mesh 服务网格的兴起，其解决了侵入式微服务框架的相关问题，实现了语言无关、对应用透明等能力。因此越来越多的开发者逐渐由传统的侵入式微服务解决方案（典型的技术方案为 Cloud ）转变为 Mesh 微服务解决方案。
作为 Mesh 领域的热门开源项目，Istio 为微服务提供无侵入的流量管理、安全通信、服务可见性等服务治理能力，目前 Istio 也基本成为了 Mesh 领域的事实标准。目前越来越多的微服务项目开始考虑将自己的微服务应用向 Istio 进行迁移。
基于上述背景，Istio 中的默认服务发现主要基于 来实现，同时结合百度云原生技术团队在内外部实践落地的场景，即发现部分开发者仍然希望使用第三方注册中心的现状， 那么对于非 上的服务数据应该如何纳入到 Istio 中呢？
为解决此类问题，首要需要解决的问题为【服务发现】，即 Mesh 中微服务能够发现非 中的服务，Istio 则需要对接支持第三方注册中心。
本文以 Istio 控制面对接第三方注册中心 为例，为读者介绍 Istio 如何对接 注册中心以及具体的实践过程，同时为 Istio 如何对接第三方注册中心提供技术思路。
本文假设读者对 、 Mesh 、Helm 等有一定的了解，若您还还未了解，请查阅相关资料。同时本文主要讲解 Istio 对接 注册中心，因此希望读者对 作为注册中心等基础知识有一定的了解。
若您还未了解 相关内容，请参考我们之前的公众号文章：。
Istio 中服务发现机制默认服务发现机制
我们先看看Istio的主要架构：
如下图，Istio 部署在 平台后，默认的服务/服务实例数据来源于 ，Istio Panel（控制平面） List Watch 中 服务/服务实例数据，当数据发生变化后，Istio 控制平面将数据通过 XDS 方式推送至 Data Panel（数据平面）中的 Proxy 。注册在 的服务可以正常互通访问，但对于传统的 注册中心上的服务暂无法纳入到 Istio 当中，也就造成了 中部署的服务无法调用 中部署的服务 。
对接第三方注册中心的方式
通过查阅 Istio 官方文档及相应代码，发现 Istio 目前有如下三种方式对接第三方注册中心：
方式
说明
自定义适配器集成第三方注册中心，配器从第三方服务注册表中获取服务和服务实例，转换为Istio 内部的标准模型，官方已支持。
MCP
自定义的 MCP 从第三方注册表中获取服务和服务实例，然后转换为 和 资源，通过 MCP 协议提供给 Istio。
/
从第三方法服务注册中心获取服务和服务实例数据，然后转换为 Istio 的 和 资源，通过 API 的接口写入到 API 中。
对接 注册中心方式
如本文前言所述，现存的应用程序对接的注册中心可能仍为第三方注册中心 ，因此如何将 上的服务/服务实例数据纳入到 Istio 中呢？
这要求 Istio 控制平面能够对接 注册中心，考虑到成本最小化，本文使用官方提供的 。Istio 启动后控制平面从 获取服务/服务实例数据，考虑到 中服务/服务实例的变更时效性，Istio 控制面通过 Long 的方式监听 注册中心上的数据变化。如下图所示将 上的服务数据纳入到了Istio 中。
在K8S中资源都可以绑定 label 信息，那么在 中服务/服务实例的 label 信息具体怎样添加呢？
通过查看 接口，我们发现服务注册模型中有两个位置可以携带上述 label 信息，分别为：
通过官方文档说明，我们还不能完全知道 label 应该具体如何携带，但通过查阅 Istio Pilot 代码后，我们发现 label 可携带在 Tags 中并且每个 label 的 Key 和 Value 按照分割符 "|" 分割，具体的实现代码逻辑（代码位置：..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| "，如下为具体服务注册 接口 的一个例子：
{
"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" # 异常服务下线
}
}
实践篇
本文实践部署的版本分别为：
Ⅰ. 部署
部署安装的途径有多种，本文中采用 Helm 在K8S环境中安装 ，其他方式请参考官方安装文档。
K8S 环境中安装 时，官方推荐的方式为通过Helm来进行安装，为保证安装的顺利进行，建议您安装 Helm 3，Helm 安装完成后，下载 -helm Helm 包来安装 。
通常默认的配置无法满足实际的需求，因此可以通过自定义配置 .yaml 文件覆盖默认配置以此达到定制化安装的目的：
# 通过覆盖默认配置达到定制化安装目的
$ helm install consul ./consul-helm -f config.yaml -n test
下面给出一个笔者实践的配置 .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
注：若您想要配置更多 的功能，请参考：Helm Chart 。
安装后查看服务信息，可以看到 --ui 的访问方式为 ，其对应的端口为 30267 ，即后续可以通过 {}:30267 访问注册中心。
$kubectl get service -n test
consul-consul-dns ClusterIP 10.20.62.108 53/TCP,53/UDP 8m38s
consul-consul-server ClusterIP 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 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
将 命令加入 path
$ export PATH=$PWD/bin:$PATH
Istio 1.6中组件已经完成了精简，即 Istio 之前版本的多种组件已经完全统一至 中，因此我们通过查阅 Istio 官方文档对 pilot-（控制面主要实现）命令参数说明，发现了对接 注册中心的参数说明：
参数
描述
--
Comma list of to read from ( one or more from {, , Mock}) ( `[]`)
--
URL for the ( ``)
即通过 pilot --- = --- = {{}}: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
最终我们在 命令空间下开启自动注入 功能：
$ kubectl label namespace default istio-injection=enabled
为验证 XDS 规则等下发情况，我们参考官方 文档部署了示例。同时部署了服务 -demo ，其注册在 注册中心上。
踩坑篇
对接过程发现了两个问题：
XDS 变更推送失效，即 注册中心上的服务服务/服务实例发生变化后，Istio 控制面没有通过 XDS 推送。
Istio 无法对接开启了 ACL 鉴权认证的 注册中心。
XDS 变更推送为何失效
当部署完 示例后，通过频繁修改 上的服务 -demo 实例信息，笔者满心欢喜进入 istio-proxy 容器访问 :15000/_dump 查询 envoy 中的数据，预期能够将 注册中心上变更的服务 -demo 在 envoy 中查询到，但查询数据发现变更的服务数据 -demo 并未通过XDS完成变更推送，这是什么原因呢？带着这样的疑问，笔者决定调试一下代码。
通过代码调试发现（代码位置: ..go）， 服务数据发生变化后，已经引起数据变更事件，但对应的 .中.Name 字段不正确，该字段主要表明具体的那个服务发生了变化，以服务 -demo 变更为例，预期该字段的值为 "-demo.." ，而实际却是 ".." ，最终导致该数据被 push 前【被误判为不应该下发该数据】，最终导致变更数据没有通过 XDS 进行下发。
该问题笔者在 Istio 代码的基础上完成了修改并完成重新构建镜像验证，目前该问题已经修改， 后续笔者也将会将提PR反馈给 Istio 社区。
如何对接开启了 ACL 认证鉴权的 注册中心
生产环境中的 注册中心往往都开启了 ACL 认证鉴权，但笔者在对接过程发现中 Istio 控制面代码层面并没预留设置 ACL Token 的配置项，笔者修改了 Istio 代码设置 Token，用于处理从 注册中心获取数据，目前已经能够支持对接开启了 ACL 鉴权认证的 注册中心， 后续笔者也会将 PR 反馈给 Istio 社区。
笔者通过亲身实践，发现 Istio 对接第三方注册中心尤其是对接 注册中心目前还存在一些功能问题待解决，后续笔者也将问题及解决方案及时反馈给社区，推动该问题的解决，同时希望更多的人能参与其中共建繁荣的 Istio 社区。
笔者有幸经历了百度由传统的微服务框架 Cloud（Java生态中微服务一体化解决方案）向 Mesh（服务网格，下一代微服务一体化解决方案）架构的转变，实践了将第三方注册中心 集成至 Istio 的生态中，望本文能够让读者对 Istio 集成第三方注册中心 有一定的了解。
附录
作者简介：刘超，百度研发工程师，现就职于百度基础架构部云原生团队，主导和参与百度内外部多项大规模微服务化改造，专注于微服务及云原生领域相关技术，对 Cloud、 Mesh、Istio、 等方向有深入的研究和实践。
