k8s内 使用nacos注册中心dubbo provider重启 有几率会导致consumer始终去连旧的ip 导致服务一直不可用

[RainElohim]

k8s、sca 2.2.1、nacos1.2.1

类似issues #1259 #1253

说是2.2.1解决了，实际并没有，这个问题还存在

[lcg72]

试试dubbo2.7.4.1，当初是基于这个版本解决的，也可以尝试nacos服务端采用1.3.0，怀疑是不是k8s关闭pod的时候某些duboo版本没有正常取消注册，而且nacos心跳检测存在问题。

[RainElohim]

试试dubbo2.7.4.1，当初是基于这个版本解决的，也可以尝试nacos服务端采用1.3.0，怀疑是不是k8s关闭pod的时候某些duboo版本没有正常取消注册，而且nacos心跳检测存在问题。

pod关闭有触发关闭钩子，是发的15信号给java，我观察过nacos里ip列表，ip的变化是正常的

[RainElohim]

试试dubbo2.7.4.1，当初是基于这个版本解决的，也可以尝试nacos服务端采用1.3.0，怀疑是不是k8s关闭pod的时候某些duboo版本没有正常取消注册，而且nacos心跳检测存在问题。

切回2.7.4.1也不行。。。provider是滚动更新的，nacos里也不会存在没节点的情况

[RainElohim]

更换成了Zk 也一样的问题

[zjwon]

我也遇到了一样的问题，而且手动触发关闭钩子也不行，在日志里已经看到老的IP已执行Unregister，但consumer还是去连旧的ip，具体描述见： https://github.com/apache/dubbo/issues/6489

[yuezhenyu0208]

我也遇到这个问题 2.2.1 并未修复

[RainElohim]

@mercyblitz 小马哥，这么严重的问题排不到2.2.2版本吗 = =

[wghdir]

我的sca2.2.1,nacos1.3.2，docker发布后也发现有一台出现这种情况

[daiqingliang]

遇到同样的问题!

[daiqingliang]

这个bug已经解决了，根据这个描述应该是没问题了
https://github.com/alibaba/spring-cloud-alibaba/pull/1286
本地测试环境升级了springboot到2.2.1 springcloud到Hoxton.SR2 sca版本2.2.1版本后，测试bug已经修复了。

[RainElohim]

这个bug已经解决了，根据这个描述应该是没问题了

1286

本地测试环境升级了springboot到2.2.1 springcloud到Hoxton.SR2 sca版本2.2.1版本后，测试bug已经修复了。

1286 早就看过了，你最好在看看类似的问题，这都几个月了，一样有人遇到，你好好测吧，这不是必现bug

[junwangit]

这个问题肯定是存在的，我是放弃spring-cloud-starter-dubbo，直接引入dubbo-spring-boot-starter 2.7.6 。注册方式变成service而不是实例了

[zjwon]

看刚发布的2.2.3 release note，依然没有解决这个问题

[daiqingliang]

这个bug已经解决了，根据这个描述应该是没问题了

1286

本地测试环境升级了springboot到2.2.1 springcloud到Hoxton.SR2 sca版本2.2.1版本后，测试bug已经修复了。

1286 早就看过了，你最好在看看类似的问题，这都几个月了，一样有人遇到，你好好测吧，这不是必现bug

嗯，问题果然还有....升级到2.2.1不行

[RainElohim]

这问题还没人来看下吗。。。。。。。

[zjwon]

我每天都来看一下，每天都失望而归

[metaphysical-road]

这个bug已经解决了，根据这个描述应该是没问题了

1286

本地测试环境升级了springboot到2.2.1 springcloud到Hoxton.SR2 sca版本2.2.1版本后，测试bug已经修复了。

1286 早就看过了，你最好在看看类似的问题，这都几个月了，一样有人遇到，你好好测吧，这不是必现bug

嗯，问题果然还有....升级到2.2.1不行

看刚发布的2.2.3 release note，依然没有解决这个问题

2.2.3 release还没解决这个问题嘛？

[Reminisd]

+1 遇到此问题

[daiqingliang]

这个问题重现的方式：本地启动nacos，先启动一个provider，然后启动一个consumer，然后启动第二个provider，第二个provider刚开始打印日志时，关闭第一个provider（kill -15）。整个过程是模拟kubectl delete pod的过程，其实要避免这个问题，重启pod时可以用kubectl scale先扩展到两个，然后删除旧的pod，再缩容到1个

kubectl scale --replicas=2 deployment/gateway
#kubectl delete pod old-pod
kubectl scale --replicas=1 deployment/gateway

[LayJustDoIt]

2.2.3依然没修复，掉坑里了

[lcg72]

@daiqingliang 如果是你描述的场景出现问题，我就没有机会碰到了，我设置了K8S里面ReadinessProbe探针。保证新的容器里面Dubbo正常提供服务后再关闭旧的容器。可以利用actuator来判断dubbo的运行状态。 我觉得要保证dubbo服务的可用性，运维是需要根据不同环境做优化的。

[daiqingliang]

@lcg72 我们服务中只用到了Liveness探针，只是用来保证服务可用性；现在的问题是，当镜像更新后，需要重启pod，一般都是执行kubectl delete pod pod-name，这条命令会导致old pod的停止和new pod的启动同时执行，就有可能导致invoker指向old pod的ip，可否介绍一下这种情形下Readiness探针的使用？

[lcg72]

@daiqingliang ReadinessProbe探针：用于判断容器是否启动完成，即容器的Ready是否为True。 由于项目已经交付，我现在看不到完整的配置，只是提供一下思路。 首先需要配置dubbo和actuator，目的是能够通过url判断dubbo的健康状态。 然后是配置探针，配置上这个url。 当重新部署服务的时候，K8S会根据这个url去检测是否ready。只有ready状态，才会去清理旧的容器。 如果不去对dubbo状态做检测的话，dubbo还没有对外提供服务，而旧的容器被关闭，就会造成一段时间服务不可用。

[lcg72]

@daiqingliang 重新部署，可以在K8S生成一个重新部署的钩子，然后在部署脚本中或镜像更新时调用，剩下的事情交给K8S自己去弄。

[daiqingliang]

@lcg72 谢谢，大体知道啥意思了，用什么方式并不重要，重要的是 新实例注册到dubbo并可用后再停用旧实例 这个逻辑，我们逻辑是一样的

[zjwon]

你们可以按这个配置试一下，我目前就是这个配置，只会尝试连一次老的IP，已经不影响正常使用 https://github.com/alibaba/spring-cloud-alibaba/issues/1805#issuecomment-726670593

[cqyisbug]

2.2.3依然没修复，掉坑里了

+1

[wangyilonghuan]

Hoxton.SR3,2.2.1.RELEASE 生产者重启，消费要等一会才能获取到新的信息，但这个时间有点长，我看源代码是60000才轮询一次

[ghost]

nacos触发一下下线和上线，似乎可以缓解这个问题。而且似乎对后续重启也有作用。还未分析原因。

[RainElohim]

这个问题不打算修了吗

[RainElohim]

没有进展吗？？？？？

[rock007]

我也遇到了，只能抛弃spring-cloud-alibaba,直接用dobbo了吗？

[wangzihaogithub]

可以解决，我在项目里是这样解决的 https://github.com/wangzihaogithub/spring-cloud-alibaba-dubbo-issues-1595

[ljwhx2002]

dubbo3.0.9 ，我也碰到相类似的情况。 provider 在k8s里重部署后更换了ip，其它的系统使用了provider历史的某一个ip，结果consumer没有重启情况 可能有本地缓存 一直去调用这个不可用的ip。https://github.com/apache/dubbo/issues/12338