下载掌阅APP，畅读海量书库
立即打开
人们开始考虑在Kubernetes上进行开发时，将会面临一个选择：是共享单个大型的开发集群，还是为每个开发者搭建一个集群。注意，只有在像公有云这样的环境下这个选择才有意义，这是因为在公有云下动态地创建集群非常方便。但是在实际环境中，一个大型集群往往可能是唯一的选择。
如果确实面临这样的选择，你应该考虑每种选择的利弊。如果你选择为每个开发者提供一个集群，将面临更高的成本和更低的效率，而且你需要管理大量不同的开发集群。此外，每个集群未必得到充分的利用，还会产生额外的成本。并且，随着开发者创建的集群越来越多，集群的跟踪和回收会变得更加困难。而为每个开发者构建一个集群的优点也很明显：开发者可以自助地管理集群。而且从隔离性的角度来说，不同开发者之间基本不会互相干扰。
单个开发集群显然会更加高效，在共享的集群上支持同等数目的开发者，你很可能只需要支付三分之一（或更少）的价格。而且，安装共享的集群服务（比如监控和日志）会容易得多，这让搭建一个对开发者友好的集群变得更加简单。而共享开发集群的缺点则是用户管理的复杂性和开发者之间的潜在干扰。由于向Kubernetes集群添加新用户和命名空间的过程目前还不够精简，每次添加新用户时你都需要从头执行一个完整的流程。尽管Kubernetes的资源管理功能和RBAC（基于角色的访问控制）可以减少开发者之间产生冲突的可能，但用户总有可能过度消耗整个集群的资源，以至于其他开发者的应用程序无法进行正常调度。此外，你仍然需要确保开发者不会泄漏和遗忘他们创建的资源，尽管这比为每个开发者搭建独立集群的方式更容易一些。
虽然这两种方式都行得通，但是通常我们建议让所有开发者共享一个大型集群。尽管开发者之间会存在互相干扰，但仍然是可管理的，而且与互相干扰带来的风险相比，其具有成本的优势以及为集群添加组织级功能的便利性。但是你需要建立一套新增开发者、资源管理和垃圾回收的流程。我们的建议是将大型共享集群作为首选。随着组织的发展（或者组织规模已经很大），你可以考虑为每个团队（10到20人）提供一个集群，而不是为数百个开发者提供一个巨型集群，这可以让计费和管理都变得更加简单。