看自身条件,包括资金、人员等。
生产环境最好是单独的集群,毕竟稳定性和可用性压倒一起。当然也有例外,例如不打算投入太多,只在容器平台上跑一些有容忍的内部系统的时候,可以考虑混部。
开发和测试环境通常可以混部。但如果考虑做一些适配性自研,涉及到对容器云平台自身的改造时,就需要注意到这里所说的开发环境在容器应用开发的基础上多了一类用途。这类开发工作会导致容器平台的不可用,有条件的话,针对这类进行单独部署。
总的来说,只要条件允许,单独部署更好。对于运维同学来说,增加了工作量,但是没有明显的工作复杂度增减;而如果混部的话,可能会直接导致复杂度的增加。但单独部署的时候,就需要设计流程,如何将镜像和配置等在多个集群或平台间流转。而混部的话,可以考虑用同一套镜像仓库和配置仓库,但同时也意味着要做好明确的规范和权限管理。
混部的时候,如果条件尚可,那么可以将节点打上不同分区label,将节点划分出不同的组,用于开发的、用于测试的、用于生产的,等等。这样做的好处是故障区的切分,但同时你需要为生产组多分配一些节点,以满足反亲和的目的来提升可用性。
----更新----
关于镜像和配置的流转设计,可以认为这和CI/CD相关,当然也要结合企业自身情况。在没有CI/CD的情况下,以镜像为例,需要由项目开发组自己负责镜像构建,当需要提测的时候,为镜像打上约定好的tag,这时利用harbor的replication机制,针对提测tag将镜像同步到测试环境的镜像仓库。测试人员针对提测镜像进行测试后,为通过的镜像打上可以投产的tag,再有harbor将这类镜像流转到生产的仓库。
一般来说,开发、测试规模不大,多在一个部门。可以考虑开发/测试环境用一套容器云平台,设置多个集群。可以按项目分,也可以按团队分。
生产环境,由于需要物理隔离,一般是需要单独一套容器云平台。可以考虑在不同网络区域部署多个容器集群。如:DMZ、内网、专网分别部署容器集群。也可以考虑给某个应用一个专属集群,具体就要重要程度了。
还有一点需要注意,就是网络规划。
如果IP地址充足,可以考虑用underlay网络方案,性能比较好。
如果IP地址有限,则可用overlay网络方案,性能约有20%损耗。应用对网络性能要求高时,不建议选择。