我有一些在 Azure 中工作的应用程序。所有这些应用程序都属于同一家公司并相互通信。我想将它们迁移到 Kubernetes。
我的问题是：在这种情况下，最佳做法是什么？为什么？
有些人推荐一个集群和多个命名空间，我不知道为什么。
例如：https://www.youtube.com/watch?v=xygE8DbwJ7c 推荐集群内的应用程序执行集群内多租户，但这个选择的论据对我来说还不够。
【问题讨论】：
标签： kubernetes kubernetes-helm azure-aks
我的问题是：在这种情况下，最佳做法是什么？为什么？
答案是：这取决于...
尝试从我们的经验中总结：
每个应用程序的集群通常是相当浪费资源的，尤其是对 HA 集群的要求，主要是在单个应用程序由大量自然集群在一起的微服务组成的情况下，或者当必须考虑一些特殊的安全考虑。然而，根据我们的经验，这种情况很少见（但这取决于）......
集群中应用程序的命名空间更符合我们的经验和需求，但同样，这也不应过度（因此，这取决于），例如，您的 CNI 可能成为导致在看似无关的情况下，流氓应用程序（或设置）会降低其他应用程序的性能。如果不惜一切代价将所有内容塞进一个集群，负载平衡和推出停机时间、资源冲突和其他事情可能会发生。所以这也有它的局限性。
两全其美 - 我们从单个集群开始，当我们达到自然独立（和独立性能）的用例（例如，qa、开发、舞台环境、具有特殊安全考虑的不同客户端等）时，我们迁移到更多集群，在每个集群中保持合理的命名空间。
总而言之：取决于可用的机器池（节点数量）、集群的大小、应用程序本身的大小（微服务/服务的复杂性）、HA 要求、冗余、安全考虑等......您可能想要将所有应用程序放入一个带有命名空间应用程序的集群中，然后可能再次分离为多个集群（再次在每个集群中使用命名空间应用程序），或者将所有东西完全分开，每个集群一个应用程序。所以 - 这取决于。
【讨论】：
这真的取决于场景。我可以想到一种情况，其中一些应用程序需要专用的更高配置节点（比如 GPU）。 在这种情况下，拥有带有 GPU 节点的专用集群可能对此类应用程序有益。并为其他普通应用程序提供普通 CPU 节点。
【讨论】：