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

2023-03-20 11:04:48 +08:00
 kd9yYw2RyhQwAwzn

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

4011 次点击
所在节点    Kubernetes
38 条回复
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 。这样能同时解决配置复杂性和合法性两个问题。
iiinspiration
2023-03-20 17:22:55 +08:00
k8s 不是最好用吗。学习配置一个。后面全抄就好了呀
aosan926
2023-03-20 17:25:37 +08:00
之前的项目是用的 nacos ,新的项目在试用腾讯新开源的 PolarisMesh
rrfeng
2023-03-20 17:26:52 +08:00
apollo 真的设计垃圾,之前用了之后很后悔。
bigbigeggs
2023-03-20 21:59:00 +08:00
配置中心,直接用 zk 不就行了?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/925458

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX