SpringCloud 项目部署在 k8s 上，关于服务发现配置中心这里有没有什么组件推荐

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 639 天前的主题，其中的信息可能已经有所发展或是发生改变。

目前我们部署在 k8s 中的 springcloud 项目针对服务发现配置中心这里使用的是 nacos
技术 Leader 想要替换调 nacos 调研了下目前比较切合需求的是 spring-cloud-starter-kubernetes
但是考虑到配置管理这块对于开发同学使用 ConfigMaps 进行编写配置有一定的困难所以想参考参考大家部署在 k8s 上的 springcloud 技术栈都是怎样的呢有没有什么轻量的配置中心推荐
jdk1.8 springboot 2.1.3.RELEASE
多谢！多谢！

k8s

nacos

配置

部署

38 条回复 • 2023-03-20 21:59:00 +08:00

Kyle18Tang

2023-03-20 11:11:23 +08:00

配置中心 Apollo 吧

kd9yYw2RyhQwAwzn

2023-03-20 11:17:47 +08:00

@Kyle18Tang 谢谢我去看一下

MonkeyJon

2023-03-20 11:23:20 +08:00

nacos 不好用么，

zhenjiachen

2023-03-20 11:26:38 +08:00 via iPhone

我们的服务发现用的就是 spring cloud kubernetes ，不用多再新增一个服务了，配置中心没有用，服务多起来了，改起来还挺麻烦，准备引入配置中心了

perfectlife

2023-03-20 11:31:57 +08:00

说句实话感觉没必要换，nacos 作为配置中心和注册中心挺稳定的了，简单省事，开发人员如果 configmap 写配置都费劲，这就没有绝对的理由相信能用好 spring-cloud-starter-kubernetes ，还要去理解 k8s 中的各种对象的概念,切本地开发复杂度也会增加很多。然后你用 configmap 还要考虑权限控制，历史记录等问题

leeUp

2023-03-20 11:34:09 +08:00

我们是 nacos ，很好用啊，阿里云也支持的很好

LeegoYih

2023-03-20 11:59:28 +08:00

k8s consul nacos eureka(停止维护)

leozzf

2023-03-20 12:37:29 +08:00 via Android

国产的都不敢用

kd9yYw2RyhQwAwzn

2023-03-20 13:11:38 +08:00

@MonkeyJon 我们发现部署在 k8s 上的 nacos 稳定性不是很高特别是其中一个节点 down 再恢复的情况下会存在部分服务链接 nacos 上时断时续的问题

SoulSleep

2023-03-20 13:13:48 +08:00

敏感配置 nacos...或者所有配置都 nacos 了...很少用 configMap...
服务发现...nacos....很少会用 k8s service...因为有虚拟机和 k8s 互相访问的问题....

总只就是 nacos 一把梭....换的时候好换....别整太复杂，特别还依赖 k8s...相对风险更高

kd9yYw2RyhQwAwzn

2023-03-20 13:14:28 +08:00

@perfectlife 好的谢谢您的建议目前我们在本地联调时也很不方便目前是在用 kt-connect 来链接集群网络

pavelpiero

2023-03-20 13:16:51 +08:00 via iPhone

服务发现如果用 cloud alibaba 没理由不用 nacos
配置中心 apollo 真的挺好用的
另过于大规模的团队 nacos 做配置中心有点不够用

jwangkun

2023-03-20 13:17:33 +08:00

我们用 consul

kd9yYw2RyhQwAwzn

2023-03-20 13:17:50 +08:00

@zhenjiachen 服务发现这块打算试试 spring cloud kubernetes 或者干脆不用给所有后端服务配置 svc 然后通过 k8s 内部的服务发现来处理相互调用的问题再后面考虑接入 istio 不过这个时候是不是 springcloud 的我感觉意义不是很大了

waising

2023-03-20 13:18:03 +08:00

@SoulSleep #10 我们用的刚好相反,能用 K8S 的尽量不引入其他服务进来,服务注册用的是 K8S 的,不过配置 cm 这块不是很方便,准备考虑其他方案

kd9yYw2RyhQwAwzn

2023-03-20 13:20:05 +08:00

@waising 您好目前针对 cm 这块的替代方案有什么建议吗

waising

2023-03-20 13:27:14 +08:00

@kd9yYw2RyhQwAwzn #16 暂定自己写一个配置文件管理的功能,根据空间和服务创建对应的 cm,目前还在思考中

SoulSleep

2023-03-20 13:27:42 +08:00

@waising #15 嗯如果你们是上来就搞 k8 ，够用了....我们是从一些老框架迁过来的，有历史债...

biubiuGolang

2023-03-20 13:45:20 +08:00

深度使用配置中心推荐 apollo

kd9yYw2RyhQwAwzn

2023-03-20 14:18:10 +08:00

@biubiuGolang 好的谢谢

cslive

2023-03-20 14:22:59 +08:00

consul

perfectlife

2023-03-20 14:42:25 +08:00

@kd9yYw2RyhQwAwzn nacos 没必要部署到 k8s 集群上，有状态服务部署到集群内你还要考虑独占节点的问题，不然异常情况可能会导致 pod 驱逐等情况，所以才会有可能不稳定，建议直接 k8s 集群外找个服务器部署 nacos ，微服务不太适合研发本地调试，调试就 push 代码自动发布,然后去 dev/test 环境。用 kt-connect 也会存在若干问题，微服务里你的服务通过 kt-connect 连接到集群上,有可能你的版本和别人的不匹配别人调用服务时候就会各种异常，或者你服务不在线时候别人访问又会找不到服务。至于 istio 等要考虑业务了，一般公司感觉实际上没必要上。

kd9yYw2RyhQwAwzn

2023-03-20 15:01:35 +08:00

@perfectlife 谢谢你的建议我发现在 docker 部署的 nacos 的可靠性也会更高一点目前这个项目也算是一个老项目了我觉得去 springcloud 化的改造成本有些大

kd9yYw2RyhQwAwzn

2023-03-20 15:03:28 +08:00

@perfectlife 考虑到交付的便利性上我们选择把很多中间件部署在 k8s 中但是使用下来感觉有状态的服务部署在集群中需要很多额外的调整

gangbinfo123

2023-03-20 15:05:23 +08:00

FeatureProbe 功能开关，不仅可以当配置中心用，还能做功能灰度和实验分析.
https://github.com/FeatureProbe/FeatureProbe

kd9yYw2RyhQwAwzn

2023-03-20 15:08:31 +08:00

@gangbinfo123 好的谢谢

MonkeyJon

2023-03-20 15:30:18 +08:00

@kd9yYw2RyhQwAwzn 为什么要把 nacso 部署到 k8s 呢，买个服务器丢上去就好了

clickhouse

2023-03-20 15:54:23 +08:00

楼上没人用，我用 Spring Cloud Config 。

ThreeK

2023-03-20 15:58:26 +08:00

同四楼直接 k8s 的

Jasonhhh

2023-03-20 16:40:49 +08:00

既然上了 K8s ，直接用 K8s 原生的服务发现

anubu

2023-03-20 16:52:56 +08:00

目前在维护的项目就是 spring cloud alibaba on kubernetes 。
- spring cloud + kubernetes 怎么看都有点“皮裤套棉裤”的感觉，有点奇怪但也是历史项目迁移到 kubernetes 最简单的路径
- 有状态的组件比如 eureka 、nacos 等，在 kubernetes 集群上组建自己的集群实现高可用，比较麻烦，特别是服务注册加上拓扑感知等场景，目的是高可用，实现手法却很不高可用的感觉
- spring cloud kubernetes 是个方向，理想的路径应该是 spring cloud 退化到 spring boot + service mesh + kubernetes 的结构，就是把微服务这个东西基础设施化，由研发侧转到运维侧。但涉及到各种人力、技术、资源匹配问题，推进起来应该也比较困难
- 独立的 spring cloud 也有优势，不用和 kubernetes 耦合，非 kubernetes 或非容器化环境也能部署，交付上可能有一点优势
- 有状态组件最好排除在集群外，或者在较稳定的集群上做刚性资源配置或绑定。云端的话建议使用现成的云服务，rocketmq 、redis 、nacos 云厂商都有提供，比自建稳定性会好很多

kd9yYw2RyhQwAwzn

2023-03-20 17:11:11 +08:00

@anubu 谢谢你的意见目前我们的项目部署在私有云上采购第三方产品估计不太好推动我们决定在测试上多跑跑如果情况不太好的话可能有状态组件就会考虑单独部署了

tairan2006

2023-03-20 17:11:40 +08:00

基于 etcd 做个界面就能当配置中心了…

如果嫌麻烦就 nacos 一把梭

liuhan907

2023-03-20 17:15:59 +08:00

@kd9yYw2RyhQwAwzn 其实我反而建议使用 cm 而不是配置中心。cm 本身其实挺方便的，支持热重载，由 kubernetes 自己管理也不需要你操心可用性的问题。唯一的可能麻烦一点的就是需要配置的人直接去写原始配置文件这点比较难受。但是这里建议考虑使用 operator 模式，让配置人员直接配置 CRD ，由 operator 生成并更新 cm 。这样能同时解决配置复杂性和合法性两个问题。