是否有关于kubernetes服务名称如何包含在微服务中的推荐实践？

Question

我知道这是一个奇怪的问题，我敢打赌这可能取决于情景或偏好。

如果我有一组微服务，我们只需要将它们称为A，B和C.它们中的每一个都在自己的身体中运行。

如果A需要访问B和C来处理请求，那么我希望依赖Kubernetes DNS解析并创建一个将路由到B的服务，以及另一个将路由到C的服务。 我们一般称这些ServiceB和ServiceC。

现在，我只是将服务名称存储在发出请求的客户端代码中定义的常量中。

根据您自己的经验，是否有充分的理由将这些存储在配置文件（或configmap）中？我无法想象它们会在应用程序的整个生命周期中发生很大变化。

你在练习中做了什么，为什么？

Answer 1

  

根据您自己的经验，是否有充分的理由将这些存储在配置文件（或配置图）中？

• 作为一般的最佳实践指南，我们倾向于避免＆＃34;魔术事物＆＃34;代码硬编码。即使只是为了能够稍后重定向它，例如，从开发服务到qa服务进行一些错误搜索或测试。

  

你在练习中做了什么，为什么？

• 如果它是可远程配置的 - 我们将其置于某种形式的配置中，即配置文件，ConfigMap或环境变量。我们更喜欢暴露它而不必更改它而不是硬编码然后后悔...根据我们预期更改的频率，我们将它（按升序排列）放入：在docker图像中捆绑的一些配置文件，具有文件内容的ConfigMap，具有环境变量的ConfigMap，直接在容器定义中的环境变量，应用程序正在读取的数据库字段。