如果你使用Kubernetes作为应用程序的操作平台，那么你应该会遇到一些有关使用集群的方式的基本问题：
- 你应该有多少集群?
- 它们应该多大?
- 它们应该包含什么?
本文将深入讨论这些问题，并分析你所拥有的一些选择的利弊。
问题所在
作为一个软件创建者，你应该开发并运行了多个应用程序。而且，你应该在不同的环境中运行这些应用程序的多个实例——例如，你应该有开发、测试以及生产环境。那么，不同的环境和应用程序的组合，我们可以得到一个“矩阵”：
在以上例子中，有3个应用程序和3个环境，两两组合为9个应用程序实例。每个应用程序实例是一个独立的部署单位，可以独立运行。
请注意，一个应用程序实例可能由多个组件组成，如前端、后端、数据库等。在一个微服务应用程序中，一个应用程序实例将由所有微服务构成。
那么作为一个Kubernetes用户，此时会遇到一些问题：
应该在一个集群中运行所有应用程序实例吗?
或者每个应用程序实例都应该有一个单独的集群吗?
或者应该以上两者相结合?
以上这些都是行之有效的方法——Kubernetes是一个灵活的系统，它并不会直接告诉你某一条指定的使用方法。
关于集群的搭配你有以下选择：
- 一个大型的共享集群
- 许多小型的一次性集群
- 每个应用程序有一个集群
- 每个环境中有一个集群
前两种方法分别是大型集群和小型集群的极端，其规模大小关系如下：
总而言之，如果一个集群包含了大量的节点和Pod，那么它就可以被定义为大于另一个集群。例如，一个有10个节点和100Pod的集群大于有1个节点和10个Pod的集群。
厘清了概念和选项，那么我们现在开始吧!
一个大型共享集群
这个方法是指将你所有的工作负载都运行在一个集群中：
通过这种方法，我们可以像通用基础架构平台一样使用该集群——无论你需要运行什么，都可将其部署到现有的Kubernetes集群中。
Kubernetes中有一个命名空间的概念，可以 在逻辑上将集群的各个部分彼此分开。在上述情况下，你可以为每个应用程序实例创建单独的命名空间。
接下来，我们来看看这个方法的优劣势。
