随着IaaS、PaaS、SaaS等云计算领域的相关体系和服务不断成熟，很多企业都开始推动信息化上云，而基于云平台、容器化的软件部署方式也逐渐成为很多厂商主推的部署方式，通过云平台的模式，可以大大提升软件管理维护的水平，加快信息化建设的速度。数通畅联作为一家致力于综合应用集成、数据治理分析的软件企业，在很早就开始探索云平台的模式，完成了软件平台的云平台部署方式，并开发了UMC实现云平台的管理维护。通过不断在项目中进行应用和完善，目前已经形成了一套完整的云平台部署架构体系。

通过产品的迭代优化以及在实际项目中的应用，目前已经形成了以K8S为核心，结合docker、keepalived、nginx、nfs等组件的一套高可用部署架构，满足产品运行要求的同时，提供容错运行机制，避免运行环境的单点故障，提高运行稳定性。

总体说明

整体部署架构以K8S为核心，通过搭建高可用的K8S集群实现容器的集中管理，将各个产品以及Redis等组件以容器的方式部署在K8S集群中，并通过UMC云管理平台进行K8S集群以及相关容器的管理。

1.部署架构

整体部署架构图如下：

1.docker和K8S部署在所有的服务器节点中，其中master3台，worker2台（及以上）；

2.其中docker作为容器引擎，在系统层面进行容器的创建、启停、销毁等操作，而K8S作为容器管理系统，通过容器编排实现集中化管理；

3.对于服务器节点，3台master主要作为K8S的管理节点，对集群进行调度管理；worker节点作为真正的工作节点，运行IDM、MDM、ESB等产品容器；

4.一般而言，K8S 的核心组件大部分部署在master节点，用于完成集群的管理，并且所有核心组件都为多节点，从而保证K8S集群的高可用。

2.产品访问

1.产品访问主要通过Nginx代理的方式访问，根据实际需要，可以配置内网Nginx和外网Nginx双重代理进行外网或域名访问，也可以只配置内部Nginx进行内网访问；

2.在访问时外部Nginx会指向内部Nginx的访问地址，内部Nginx通过配置文件将访问地址指向K8S集群的Ingress（高可用的Ingress容器一般在master1、master2和master3上）；

3.Ingress作为K8S的管理组件，会构建基于iptables的路由表，基于代理的方式将访问路由指向K8S集群内部的容器，从而实现容器内产品的访问；

4.K8S集群在进行容器管理时，会通过ApiServer组件将容器内部的相关内容发布成API，Ingress等相关组件会通过调用这些API实现容器内部的访问。

3.集群管理

1.UMC对于K8S集群的管理包括K8S集群、Ingress、镜像库、产品容器等；

2.UMC在进行管理时，主要通过调用命令的方式实现K8S集群的管理与操作；

3.在UMC进行集群、Ingress、容器等操作时，在页面中会显示相关的操作命令，可以通过复制的方式复制命令到服务器执行查看。

核心组件

整个部署架构以K8S为核心，但为了保证高可用的集群需要，核心组件除了docker和K8S内部组件外，也包括了haproxy、keepalved、nfs、Redis等内容。

1.部署清单

3.相关配置

针对docker、K8S、haproxy、keepalved、nfs、Redis以及umc产品，在部署和维护的过程中，涉及大量的配置文件，在管理的过程中需要注意各文件的配置方式。

> > > > docker配置文件

/etc/docker

1.该文件为docker的配置文件，如果修改需要重启docker，重启：systemctl daemon-reload && systemctl restart docker；

2.主要参数：insecure-registries:[]，非https的registry地址（私有镜像库），根据部署情况配置，高可用环境：worker虚拟IP:5000；

3.log-driver:""，容器日志的驱动器，一般为json-file；

4.log-opts:{}，容器日志的选项，max-size(日志文件大小)，max-file(保留日志数量)；

5.参考配置：

> > > > haproxy配置文件

/etc/haproxy：

haproxy启动和运行时的配置文件，一般不需要修改。

> > > > keepalived配置文件

/etc/keepalived：

1.keepalived.conf：keepalived配置文件，启动和运行时使用；

2.nfs_check.sh：keepalived运行时的nfs服务监控脚本，用于虚拟IP漂移时的DRBD磁盘切换；

3.notify_stop.sh：keepalived停止服务时的调用脚本，同时会尝试重启keepalived服务。

> > > > K8S配置文件

1./etc/kubernetes/manifests：

（1）以上文件为K8S组件（etcd、apiserver、controller-manager、scheduler）的配置文件，一般情况下无需修改；

（2）以上文件在K8S集群部署时自动生成，除绑定的IP地址外，其他信息未通用信息；

（3）以上配置绑定的IP为服务器的真实IP，即创建虚拟机时绑定在网卡上的IP地址。

2./opt/K8S：

（1）以上文件为K8S集群初始化创建时的配置文件，主要用于指定K8S相关的配置信息；

（2）以上文件在K8S集群初始化后不需要进行调整；

（3）custom-resources.yaml、tigera-operator.yaml文件一键部署时使用，手动部署时不需要，kubeadm-config.yaml都需要；

（4）注意在进行K8S集群初始化前，需要确认kubeadm-config.yaml文件的IP和端口，高可用环境：IP为K8S集群的虚拟IP，端口为16443，非高可用：IP为master服务器IP，端口6443。

3./opt/K8S/addons：

（1）该文件为在K8S集群中创建用户使用，在部署Ingress时使用；

（2）该文件在一键部署时使用，手动部署时可以不使用该文件。

> > > > K8S证书文件

1./etc/kubernetes：

2./etc/kubernetes/pki：

3./etc/kubernetes/pki/etcd：

（1）以上全部文件均为K8S集群的证书和密钥文件，这些文件K8S集群初始化的时候生成；

（2）在没有出现K8S集群证书过期的情况下，这些文档都需要修改，如果出现K8S集群证书过期，需要将这些文件全部备份删除，之后全部重新生成；

（3）K8S证书的检查命令（一共14个证书）：

> > > > flannel配置文件

/opt/K8S/addons：

1.该文件为在K8S集群中部署flannel时使用；

2.该文件在部署时使用，一般不需要修改。

> > > > Ingress配置文件

/opt/K8S/addons：

1.以上文件为Ingress配置文件，在部署Ingress时使用；

2.nginx-ingress.yaml为Ingress创建时的参数信息配置文件，手动部署时该文件也会命名成mandatory.yaml；
nginx-ingress-configmap.yaml为Nginx参数文件，用于在nginx-ingress中添加参数，优化外部访问，手动部署时该文件也会命名成configmap.yaml。

> > > > NFS配置文件

1.挂载目录：/opt/mnt/volumes；

2.IP网段：当前K8S集群所在服务器网段；

3.权限：rw（读写访问），no_root_squas（root用户具有根目录的完全管理访问权限）；

4.参考配置：

> > > > 集群自启脚本

/opt/K8S/script：

1.container-clean-log.sh：每天检查删除容器内10天之前的日志文件，crontab定时调用；

2.container-cut-log.sh：定时拆分产品日志，减少日志文件大小，crontab定时调用；keepalived-delay-start.sh：延时启动keepalived，保障系统开机稳定后再调用nfs高可用脚本，开机自启，
keepalived-delay-start.service服务调用；

3.K8S-failover-redis.sh：容器化redis重启后故障转移，开机自启，
K8S-failover-redis.service服务调用；

4.K8S-reset-pod.sh：重启启动产品容器，开机自启，K8S-reset-pod.service服务调用；

5.redis.sh：启动传统模式redis实例集群，重新加入集群，故障转移，开机自启，redis-start.service服务调用

6.umc-clean-log.sh：每天检查删除UMC10天之前的日志文件，crontab定时调用；

7.umc-cut-log.sh：定时拆分UMC日志，减少日志文件大小，crontab定时调用；

8.umcstart.sh：启动UMC服务，开机自启，umc-start.service服务调用。

> > > > 外部Redis配置文件

/usr/local/redis-5.0.4：

1.redis_cluster_start_5.0.4_pwd.sh：Redis集群启动和重置的脚本，开机自启，redis.sh启动脚本调用；

2.redis.conf：redis启动和运行的配置文件，内部通过bind绑定服务器IP。

> > > > UMC配置文件

UMC部署路径（参考项目部署清单）：

1.hotweb.properties：数据库配置文件，包括数据库连接信息，以及Redis集群（外部Redis集群）连接信息；

2.server.xml：UMC产品配置文件，集群模式下需要在Engine下定义jvmRoute="umc_"；

3.context.xml：UMC产品配置文件，集群模式下需要指定Redis集群（外部Redis集群），参考配置：

产品体系

主要针对UMC、平台产品以及Redis组件等相关内容的汇总，包括产品相关的架构体系，通过UMC平台进行产品管理维护的方式等。

1.UMC架构

UMC的部署架构图如下图所示：

1.高可用的UMC采用双节点部署，一般部署在K8S集群的worker1和worker2节点上；

2.UMC采用传统的部署，即直接将安装介质上传到服务器，然后在服务器上进行解压启动运行；

3.由于UMC产品运行需要依赖Redis和java环境，所以需要部署在服务器上部署Redis和JDK；

4.由于是高可用环境部署，所以Redis采用cluster集群模式，即三台服务器六个节点，所以Redis使用master部署，三个master服务器各部署两个节点，端口分别为master1：7000、70001，master2：7002、70003，master3：7004、70005；

5.为了保证UMC的高可用，通过Nginx实现负载均衡，通过keepaived实现虚拟IP绑定，虚拟IP通过keepalived默认绑定在worker1服务器，访问时通过woker1的虚拟IP访问worker1的Nginx，再通过worker1的Nginx在worker1和worker上负载均衡；

6.但worker1服务器出现宕机时，keepalived自动将虚拟IP漂移到worker2服务器，再由worker2的Nginx提供服务，但worker1恢复后，keepalived自动将虚拟IP漂移回worker1。

2.产品容器

1.产品容器通过UMC统一进行管理维护，包括镜像上传、容器启动、容器重启，配置修改、补丁替换等；

2.一般按照实际情况，UMC会部署开发、测试、发布、生产等多个环境，其中开发环境一般是单节点，即一个产品一个容器（单机模式），测试、发布一般为集群模式（2个以上容器），具体可以根据服务器资源和容器数限制进行调整，但生产环境一定为集群模式（2个以上容器）；

3.多环境管理，每个环境使用不同的数据库和配置文件，保证产品独立访问，同时不同环境可以进行配置文件等资源的同步：

4.数据库连接：

5.产品补丁及配置文件：

6.容器镜像、数量及CPU、内存配置：

7.容器状态及操作命令查看:

3.Redis容器

1.Redis容器通过UMC统一进行管理维护，包括镜像上传、容器启动、容器重启等；

2.按照实际需要，Redis容器支持单机和集群两种模式，单机模式为一个容器，集群模式为多个容器（一般为6个）；

3.Redis容器部署有两种方式，一是在产品上部署Redis容器，一种是在环境上部署Redis，两种部署方式产生的连接地址不同，但在使用上没有区别；

4.单机模式:

5.集群模式:

6.产品连接:

高可用机制

高可用机制是整个部署架构中非常重要的内容，是保证产品和集群稳定运行的重要依据，在集群以及产品运行过程中，高可用机制的存在能保证即使整个集群出现单点故障，也能保证产品的稳定运行，降低对生产业务的影响。

1.虚拟IP

1.虚拟IP主要是为了保证K8S集群的高可用，所以只有高可用环境下需要配置虚拟IP，非高可用环境只需要使用服务器IP即可，不需要虚拟IP；

2.高可用环境的虚拟IP有两个，一个是部署在master1和master2上，主要为了保证K8S集群的高可用，通过一组keepalived实现虚拟IP漂移；另一个部署在worker1和worker2上，主要为了保证UMC和Nginx的高可用，即产品平台访问的高可用，也是通过一组keepalived（和K8S的不是同一组）实现虚拟IP漂移。

2.K8S集群

1.该虚拟IP主要是主持K8S集群内部的交互，K8S容器以及组件通过虚拟IP访问K8S的apiserver，从而实现内部调用，探针检查等机制；

2.默认绑定在master1节点，在master1宕机时通过keepalived漂移到master2节点，在master1节点恢复后，keepalived会将虚拟IP漂移回master1节点，从而保证单节点故障的高可用；

3.另外，master节点上还通过haproxy进行负载均衡，通过haproxy代理16443端口，通过配置文件haproxy.cfg将代理地址指向master1、master2、master3的6443端口（K8S集群中apiserver的对外访问端口），从而实现K8S集群的负载均衡。

3.访问地址

1.该虚拟IP主要是支持外部对UMC、IDM、MDM、ESB等产品的外部访问；

2.虚拟IP默认绑定在worker1节点，在worker1宕机时通过keepalived漂移到worker2节点，在worker1节点恢复后，keepalived会将虚拟IP漂移回worker1节点，从而保证单节点故障的高可用；

3.在worker1和worker2节点分别部署UMC和Nginx，Nginx通过反向代理将K8S的产品容器地址代理成虚拟IP的形式，便于外部访问，同时在Nginx代理时配置负载均衡，减小容器的压力；

4.UMC产品也是通过Nginx进行代理，形成虚拟IP的访问地址，再通过Nginx配置成负载均衡模式，同时worker1和worker2的多节点部署，也能保证UMC和产品访问的高可用。

4.DRBD

> > > > 工作原理

如图为官网的DRBD架构图：

DRBD包括一个活动节点，一个备用节点，当活动节点接收到数据后发往内核的数据通路，DRBD在数据通路中检查数据，当发现接收到的数据是发往到自己管理的存储位置，就复制另一份，一份存储到本机的DRBD存储设备，另一份就发给TCP/IP协议栈，通过网卡网络传输到另一节点主机的网上TCP/IP协议栈；而另一节点运行的DRBD模块同样在数据通路上检查数据，当发现传输过来的数据时，就存储到DRBD存储设备对应的位置。

如果活动节点宕机，备用节点可以在高可用集群中成为活动节点，当接收到数据后先存储到本地，当原主节点恢复上线时，再把宕机后的节点变动数据镜像到原节点。

> > > > 模块说明

1.DRBD是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案，简单说DRBD是实现活动节点存储数据变动后自动复制到备用节点相应存储位置的软件；

2.DRBD是运行在节点服务器的内核中，所以DRBD是内核模块，在Linux 2.6.33版本起开始整合进内核，如果系统内核不够，需要升级内核或者通过RPM包安装整合到内核中；

3.DRBD包括一个活动节点，一个备用节点，同一时间，只能有一个活动节点，原则上只有活动节点能够通过文件系统进行访问，备用节点无法直接访问；

4.DRBD需要构建在底层设备之上，然后构建出一个块设备出来，对于用户来说，一个DRBD设备，就像是一块物理磁盘，可以在DRBD设备内创建文件系统，所以在Linux上部署DRBD时，不能直接使用系统盘进行构建，必须是单独挂载的独立磁盘；

5.DRBD配置工具：

（1）drbdadm：高级管理工具，管理/etc/drbd.conf，向drbdsetup和drbdmeta发送指令；

（2）drbdsetup：配置装载进kernel的DRBD模块，很少直接使用；

（3）drbdmeta：管理META数据结构，很少直接使用。

> > > > 部署说明

1.在K8S部署架构中DRBD为NFS共享存储提供高可用镜像备份，再结合keepalived的高可用机制对DRBD进行自动切换；

2.当主节点宕机后，keepalived自动进行虚拟IP漂移，keepalived的监控脚本检测到虚拟IP漂移后，发出DRBD的切换命令，将备用节点升级成主节点，继续提供存储服务；

3.在K8S集群架构中，DRBD主要存储：产品镜像文件、产品运行日志、产品配置文件、产品补丁文件以及MDM、ESB等产品动态部署的接口、运行文件等；

4.由于DRBD“无共享”的特点，不同节点存储设备空间是镜像，在访问也只能访问活动节点的目录和文件；

5.在进行DRBD部署时，DRBD需要部署在master1和master2节点，一方面需要借助master1和master2的keepalived实现高可用，另一方面能保证产品容器的正常部署；

6.因为DRBD的“无共享”，DRBD从节点可以进行文件备份，但是正常是无法直接访问的，这也就导致产品容器启动时无法从从节点的DRBD中读取配置文件，也不能生成日志文件，所以DRBD只能部署在master1和master2（一般master1和master2不部署产品容器）上。

总结分析

当前的云平台部署方式，是经过多次优化迭代以及产品完成才形成，基于当前的部署方式，不仅能保证产品运行的稳定性，对于环境日常的监控和管理也是非常便捷的，能大大提升运维的效率。

1.部署方式

目前云平台的部署，采用“脚本+产品”的方式进行，脚本采用ansible脚本，可以自动化的进行部署维护，提升了部署过程的效率，同时采用脚本自动运行，也避免了人为操作时由于误操作产生的一系列问题。同时结合UMC产品预置的部署功能，也降低了对部署人员的技术能力的要求，更加方便地进行环境部署运维的工作。

2.产品优化

由于现在K8S集群部署大部分的部署工作是在UMC平台完成，在部署过程中对UMC产品的相关功能也在不断的进行优化完善，从使用者的角度出发，提升相关功能使用的便捷性，后续云平台的部署、维护将会更加便捷和快速，有效提升工作效率。

3.部署方案

通过不断的使用和优化，并通过众多项目的实践，目前基于K8S的云平台部署架构已经比较稳定和成熟，并且也对部署过程不断进行优化，将原来手动部署几周提高到了一周之内就能完成一套高可用集群的部署，并且结合相关的部署资料，大部分技术人员都可以快速掌握整套部署方式，有利于后续的项目实施与推广。

基于K8S的云平台部署方式是目前数通畅联产品和方案统一的部署模式，无论是内部POC还是实际项目，都是采用这种方式，所以对于UMC以及部署脚本要充分考虑实用性和便捷性，才能提升部署效率和效果。在架构层面将部署架构和体系不断优化，提升集群的稳定性和安全性。同时UMC产品也在不断的升级迭代，将部署过程更加简化，便于后续直接交付伙伴或客户进行使用。