下载掌阅APP，畅读海量书库
立即打开
由于每个企业的基础设施环境不同，读者需结合实际的企业基础设施现状做适当调整。我们仅给出通用的单个集群的高可用架构，如图3-1所示。
图3-1体现了大部分情况下OpenShift高可用部署架构的形态，也是我们落地实施最多的一种部署架构。
OpenShift集群要求有且只有3个Master节点，如果集群的Worker节点数量很多，可以增加Master节点的CPU、内存资源，而不必再增加Master节点的数量。每个Master节点上运行一个Etcd进程实现Etcd高可用集群。对于Master API层面则通过软件负载均衡实现高可用，提供集群管理的入口。
计算节点分为Infra节点和App节点，App节点运行业务应用，Infra节点运行基础组件，图3-1中Infra节点有三个，每个节点上运行一个Router容器、一个内部镜像仓库容器，Router作为应用访问的入口，同样通过负载均衡实现高可用；内部镜像仓库需要将数据存储挂载到后端存储上，这样无状态的应用直接启动多个实例就可以实现高可用。这些内容正是我们上一章所介绍的，可以根据需要增加Infra节点和App节点。非生产环境如果资源有限，可以不单独配置Infra节点，和App节点混用即可。
在很多实际客户的落地情况中，仅仅有一个集群是不够的，会根据环境创建开发、测试、生产等多套集群，如图3-2所示。
图3-1 单集群高可用部署架构
图3-2 实际客户的多套OpenShift环境
当然，也有些客户为了节省资源，会将开发集群和测试集群合并为一个集群，在OpenShfit层面通过项目实现逻辑隔离。在图3-3中，生产环境和非生产环境做物理隔离，在非生产集群中，通过项目隔离，实现开发和测试两个环节。
图3-3 OpenShift集群隔离和项目隔离
在部署了多套OpenShift集群后，多套集群之间如何联动？例如，在图3-3所示的测试环境与生产环境中，测试通过的镜像要发布到生产环境。最直接的方法是通过手动或者工具将镜像拷贝实现交付物流转，更高级的方法是引入CI/CD实现交付物在不同环境的流转与发布，这将在本书的第7章进行介绍。
到此为止，OpenShift的架构及规划就介绍完了，下面我们以最常见的部署架构进行实际的安装部署配置。