.net core 服务部署在 k8s 集群中，还有必要自己做服务的发现和注册吗

[presoul]

请问下大家在实际的生产环境中如果服务已经是部署在 k8s 的集群中还有必要使用类似于 nacos 或者 consul 来做服务的注册和发现吗，并没有使用 k8s 的 service mesh ，请教一下，谢谢。

[wandehul]

如果用 k8s 就好好的用 k8s 自己的发现服务。完全不需要再借助其他的发现服务了 。 那样用起来就是一个跑在 k8s 里的虚拟化服务了

[presoul]

@wandehul 非常感谢，我个人认为跑在集群外面服务可能需要这个东西来做心跳检测或者故障处理，现在的 leader 我无法说服，如果要用的话就是自己获取 pod 的 ip 提交给注册中心，我不是做开发的，我个人感觉没有必要

[jxxz]

直接用 k8s 的 service 做发现就行了，之前老服务上 k8s 都把 eureka 去掉了

[nulIptr]

如果是单个集群自带的就够用了，多集群内网 dns 就搞不定了，还是得用 consul 之类的东西。

[rushssss]

Kubernetes in Action 这本书里提到了一条最佳实践： 最好不要让应用感知到它运行在 Kubernetes 上我认为这是有道理的，因为这会使你的应用自身和 Kubernetes 发生联系

[rushssss]

如果想省点事，可以用基于 DNS 的服务发现方案（在 Kubernetes 里是 headless service ），这样将来你想换也非常容易，毕竟 DNS 肯定比 Kubernetes 活得久

[presoul]

@rushssss 谢谢，非常感谢~

[gengchun]

一般 k8s 部署的系统不可能简单到只有几个 web services ，或者并行计算实例。

哪怕部署过 flink 也应该知道上 k8s cloud native 的应用还是需要改不少东西的。默认靠 service 完成不了需求。自己写 operator 或者应用直接调 k8s api 。你要说没有必要，这锅后面就是你的了，这玩意实现，我觉得没有什么难度，但是具体到应用也是一件麻烦的事情。

你的用户是开发，用户说有必要，你“感觉”没有必要。你再想一想说“感觉”合适吗。

[presoul]

@gengchun 感谢你的回复，我的理解比较浅薄，目前我们是通过 k8s 的 api 获取的，用默认的 pod 的有 Service Account 可以获取注册的服务，要自己扩展的情景可以具体讲一下吗

[gengchun]

@presoul 我没做过 dot net ，所以不能直接举相关的例子。但是 flink 这种算是简单的，按理就算没学过 Java 也不难理解。你可以去看一下它的 kubernetes native 实现。应该可以回答你的问题，简单说至少也需要选出 leader 和实现并发锁，这个分布式应用回避不了的。

你这种应该是把原有的应用迁移至 k8s 。比较大的应用肯定是有自己的一套框架的，没有涉及这方面的改动，很可能是框架已经实现了这一部分，只需要一个地方去查找刷新一下活动节点。这种事情多和同事沟通。人家肯定比 v 站上不知道哪来的人，更了解自己的系统，同事不好沟通，也应该好好分析应用的行为和代码。