默认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单独更新)。
标签:服务,service,Consul,Istio,istio,instance,注册,entry,consul From: https://www.cnblogs.com/muzinan110/p/17061228.html