使用Consul作为Istio的注册中心

默认istio使用k8s作为注册中心，k8s的service、endpoint对应于服务、实例。

针对一些还未接入到服务网格的Spring Cloud服务，其使用的注册中心可能是consul，如何让服务网格上的consumer服务能访问到非服务网格的Provider，是应用在服务网格迁移过程中所面临的问题。istio本身提供了一些机制，来引入外部注册中心的服务。

除了将consul作为与kubernetes同级别的注册中心接入，社区还有一种思路，借助service entry，将consul上的服务映射为istio的 service entry，将consul服务的instance作为workload entry，从而帮助服务网格上的服务，去访问不在服务网格的服务。

1.注册中心接入(intree)

consul 部署

consul服务以Deployment的形式，部署到k8s的default namespace下。

istio配置

注意istio采用1.7.8版本。通过demo profile部署后，修改 registries 为Kubernetes+Consul，以及增加consul server的地址。

问题： 更新pod instance后，sidecar不更新数据。

缺点： 即使是consul部分service/instance更新，istiod也是全量更新

2.service entry方案

针对consul开发controller，watch consul的service变化，并为service 生成 service entry ，为 service 的 instances 生成 workload entry。

社区有 consul2istio 项目，实现了从consul同步到istio的service entry的功能。

不过，该项目将instance直接作为service entry的endpoints，而不是为instance创建对应的wle，所以无法根据wle的label，选择不同的wle，这样会在做流量治理时遇到一些问题：例如无法为不同版本的instance设置流量治理规则，进行灰度发布。

consul2istio 可以实现增量更新（watch consul变化、每个service entry单独更新）。