伴随着非侵入式微服务技术 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)如下:
因此,在服务注册时,需要将标签信息存放在标签中,同时按照分割符“ |” 分割,如“ tag1 | value1”,如下为具体服务注册 注册 Service 接口的一个例子:
实践篇
本文实践部署的版本分别为:
领事 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 文件覆盖配置配置达到定制化安装的目的:
下面指定一个笔者实践的配置 config.yaml:
注:若您想要配置更多 Consul 的功能,请参考:Helm Chart Reference(https://www.consul.io/docs/k8s/helm)。
安装后查看服务信息,可以看到 consul-consul-ui 的访问方式为 NodePort,其对应的端口为 30267,即后续可以通过 http:// {node_ip}:30267 访问注册中心。
Istio 部署
下载安装包
在下载页下载安装包,注意选择对应的操作系统安装包,本文以的 MacOS 为例下载了 istio-1.6.8-osx.tar.gz,解压后进入 istio 目录。
将 istioctl 命令加入路径
安装 Istio 并集成领事
Istio 1.6 中组件已经完成了精简,即 Istio 之前版本的多种组件已经完全统一至 Istiod 中,因此我们通过引用 Istio 官方文档对 pilot-discovery (控制面主要实现)命令参数说明,发现了对接 Consul XML 中心的参数说明:
即通过 pilot -discovery --registries = Consul — consulserverURL = http:// { {node_ip}}:39267 / ,但是这些参数具体在哪里配置呢?
通过对官方文档查阅,发现可以自定义清单来完成安装,我们修改清单 yaml 来指定参数:
修改完成后完成最终部署:
最终我们在 default 命令空间下开启自动注入 Sidecar 功能:
为验证 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,领事等方向有深入的研究和实践。
评论 1 条评论