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

[kd9yYw2RyhQwAwzn]

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

[Kyle18Tang]

配置中心 Apollo 吧

[kd9yYw2RyhQwAwzn]

@Kyle18Tang 谢谢 我去看一下

[MonkeyJon]

nacos 不好用么，

[zhenjiachen]

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

[perfectlife]

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

[leeUp]

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

[LeegoYih]

k8s consul nacos eureka(停止维护)

[leozzf]

国产的都不敢用

[kd9yYw2RyhQwAwzn]

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

[SoulSleep]

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

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

[kd9yYw2RyhQwAwzn]

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

[pavelpiero]

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

[jwangkun]

我们用 consul

[kd9yYw2RyhQwAwzn]

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

[waising]

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

[kd9yYw2RyhQwAwzn]

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

[waising]

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

[SoulSleep]

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

[biubiuGolang]

深度使用配置中心推荐 apollo

[kd9yYw2RyhQwAwzn]

@biubiuGolang 好的 谢谢

[cslive]

consul

[perfectlife]

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

[kd9yYw2RyhQwAwzn]

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

[kd9yYw2RyhQwAwzn]

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

[gangbinfo123]

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

[kd9yYw2RyhQwAwzn]

@gangbinfo123 好的 谢谢

[MonkeyJon]

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

[clickhouse]

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

[ThreeK]

同四楼 直接 k8s 的

[Jasonhhh]

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

[anubu]

目前在维护的项目就是 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]

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

[tairan2006]

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

如果嫌麻烦就 nacos 一把梭

[liuhan907]

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

[iiinspiration]

k8s 不是最好用吗。学习配置一个。后面全抄就好了呀

[aosan926]

之前的项目是用的 nacos ，新的项目在试用腾讯新开源的 PolarisMesh

[rrfeng]

apollo 真的设计垃圾，之前用了之后很后悔。

[bigbigeggs]

配置中心，直接用 zk 不就行了？