我已经创建了一个 kubernetes 集群，并成功部署了我的 spring boot 应用程序 + nginx 反向代理用于测试目的。
现在我要进入生产环境，test 和 prod 的唯一区别是与数据库的连接和 nginx 基本身份验证（当然缩放参数也不同）。
在这种情况下，考虑到我正在使用云提供商基础架构，kubernetes 的最佳实践是什么？ 我应该只为产品创建一个新集群吗？或者我可以使用同一个集群并使用标签来识别测试和生产机器？
现在拥有 2 个集群对我来说似乎是一种浪费：提供商向我保证我有硬件能力，我可以根据环境设置不同的请求/限制/复制参数。另外，目前，我每个环境只需要部署 2 个图像（即使在生产环境中我会选择 2 的水平缩放）。
【问题讨论】：
标签： azure kubernetes
我绝对会 100% 设置一个单独的测试集群。 （...假设 Kubernetes 的设置足够大；我可能会考虑为您所描述的简单三层应用程序提供更简单的部署系统。）
在财务层面上，这对您应该没有太大影响。您需要一定数量的硬件来运行应用程序的测试副本，并且您的组织将为此付费，无论它是在同一个集群中还是在不同的集群中。额外的成本只会是管理平面的成本，不能过多。
在操作层面，在部署过程中可能会出现各种各样的问题，特别是在某些情况下，一个 Kubernetes 资源可能会“踩到”另一个资源。部署到物理上独立的集群有助于最大程度地降低生产中发生事故的风险；例如，您不会意外覆盖保存其数据库配置的产品部署的 ConfigMap。如果您设置了某种崩溃报告或警报，“它来自测试集群”是一个非常明确的检查，您可以使用它来避免唤醒 DevOps 团队。它还为您提供了一个尝试可能有风险的配置更改的地方：如果您在测试集群中运行一次更新脚本并且它通过了，那么您可以在 prod 中重新运行它，但如果您第一次运行它是在 prod 中并且它失败了，那就是中断。
根据您用于 CI 系统的内容，您可以设置的另一件事是全自动部署到测试环境。如果提交通过了自己的单元测试，您可以让测试环境始终运行当前的master 并在那里运行集成测试。当且仅当这些集成测试通过时，您才能升级到生产环境。
【讨论】：
确实，使用不同的集群绝对是一种更好的做法，因为在您的测试集群中，您可能会做错事（尤其是在资源方面），并关闭您的 prod 环境，但如果您负担不起它，如果你对 k8s 有信心，你可以将你的 prod 环境放在不同的命名空间中。
我不知道在 azure 上，但在 GKE 上，您可以将节点数设为零。如果在 azure 上是可能的，也许你可以在不使用的时候将测试环境的节点数归零，并获得 2 个集群。
【讨论】：
最好使用不同的集群进行生产和开发/测试。请参考here 了解最佳做法
【讨论】：