某保险paas容器云平台项目实践

字数 9736阅读 8585评论 1赞 20

# 1	项目背景
## 1.1	PaaS容器云平台概述
进入21世纪，我们的社会和经济发生了巨大的变化，社会对各行业服务的要求越来越高、越来越细致。新的需求如洪水一样滔滔不绝地从市场的第一线喷涌到企业的产品部门和IT部门。为了满足业务的需求，企业IT在不断地变革，而且从未停步。从客户端/服务器模型，变革为浏览器/服务端模型，从庞大的信息孤岛，变革为基于服务的架构（SOA），从物理机，到虚拟化，再到基础架构云（IaaS）和应用云（PaaS）。
通过近十年云化的推进，大多数有一定规模的企业已经实现了基础架构资源的云化和池化，这里的资源指的是诸如虚拟机、数据库、网络、存储。用户可以用很短的时间获取业务应用所需的机器、存储和数据库。基础架构资源云化其实并不是目的，而是手段。最终的目标是让承载业务的应用可以更快地上线。但现实是，通过IaaS获取的大量的基础架构资源并不能被我们的最终业务应用直接消费。应用还必须进行或繁或简的部署和配置，才可能运行在云化的虚拟机之上。部署涉及操作系统配置的修改、编程语言运行环境的安装配置以及中间件的安装配置等。部署的过程在一些企业仍然是通过手工完成，低效且容易出错。有的企业则是通过简单的自动化方式完成，提高了效率，但是满足不了后期更高级别的要求，如动态扩容、持续部署。即使勉强通过了简单的自动化实现，后期随着部署平台类型的增多以及复杂化，维护的难度将会陡然增高，无法真正做到随时随地持续交付、部署。
基于这个背景，业界需要有一种手段来填充业务应用和基础架构资源的这道鸿沟。让应用可以做到“一键式”快速的在基础架构资源上运行。为了实现这个目标，业界出现了多种不同的平台，即服务云的容器方案。最终命运之神的棒槌砸到了一个叫Docker的开源项目上。Docker通过对Linux内核已有机能的整合和强化，为业务应用提供了一个绝妙的方案。最后其简单易用的用户命令行，让Docker快速地获取了巨大的用户基础，也成就了今日其在容器界的地位。目前Docker结合Kubernetes的解决方案是业界应用最为广泛的容器云解决方案。Kubernetes是Google开源的容器集群管理系统。它构建Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的Micro-PaaS平台，即第三代PaaS的代表性项目。
## 1.2	某保险技术转型概述
未来的规划，某保险将以保险行业的产业链延伸、客户导向及互联网+为战略发展方向，需要BI分析、业务动态扩展、以及敏捷的产品与服务对接和装配的能力支撑，基于以上的技术要求，优化建设支撑企业业务及应用运营的基础设施，结合基础资源现状，建立云计算技术能力，形成快速响应，可持续发展的下一代数据中心。
如图所示，对比传统方案，容器云的方案，将在对微服务架构的支持、业务弹性扩容、自动化部署、产品快速上线、敏捷/迭代、全面系统监控等方面对IT部门带来全方位的提升。
![nqfxpfezo1](/home/attachment/201901/16/301729_154761819679095.png)

## 1.3	红帽OpenShift平台概述
OpenShift是一个开源容器云平台，是一个基于主流的容器技术Docker和Kubernetes构建的云平台。作为一个开源项目，OpenShift已有5年的发展历史，其最早的定位是一个应用云平台（PaaS）。在Docker时代来临之前，各厂商和社区项目倾向构建自己的容器标准，如CloudFoundry的Warden、OpenShift的Dear，但是在Docker成为主流及社区的技术发展方向后，OpenShift快速的拥抱了Docker，并推出了市场上第一个基于Docker及Kubernetes的容器PaaS解决方案。OpenShift对Docker及Kubernetes的整合和OpenShift项目最大的贡献方红帽有着很大的关系。Red Hat是OpenShift项目最大的贡献者，同时也是Docker和Kubernetes项目重要的贡献方。OpenShift前几年在容器和PaaS领域的经验积累，叠加上Docker和Kubernetes容器及容器编排上的特性，一经推出就受到了广泛的关注和好评，连续两年获得InfoWorld年度技术创新大奖。
通过OpenShift这个平台，企业可以快速在内部网络中构建出一个多租户的云平台，在这朵云上提供应用开发、测试、部署、运维的各项服务。OpenShift在一个平台上贯通开发、测试、部署、运维的流程，实现高度的自动化，满足应用持续集成及持续交付和部署的需求；满足企业及组织对容器管理、容器编排的需求。通过OpenShift的灵活架构，企业可以以OpenShift作为核心，在其上搭建一个企业的DevOps引擎，推动企业的DevOps变革和转型。

# 2	需求分析
秉承统筹规划、顶层设计原则，围绕“移动、云、大数据”等新技术，提高信息数字化水平，打造信息技术传统与敏捷双模交付能力，驱动业务模式创新和流程再造，支撑公司三大战略实施，最终将数字化打造成某保险的核心竞争力。
对基础架构的建设提出了新的要求：

- 对于渠道类系统（如网销、网关、移动），未来需要实现互联网+战略，将面对需求的波动和动态扩张，此类系统需要资源的动态供给；
- 对于运营类系统（如承保再保系统），未来需要实现系统的微服务化，需要云化平台的可扩展、易管理能力的支撑；
- 对于数据分析类系统（如大数据分析平台、车联网平台），需要实现大数据的分布式存储、大数据分布式流计算、异步消息传输支持，需要云平台的支撑。

# 3	架构设计
## 3.1	整体部署架构
![hpo31cht3hub](/home/attachment/201901/15/1212257_154755839889897.png)

- 在DMZ和内网分别部署彼此独立的2套Openshift，分别为内网和DMZ区两个网段，两套环境彼此隔离。
- DMZ区的Openshift部署对外发布的应用，负责处理外网的访问
- 内网的Openshift部署针对内网的应用，仅负责处理内网的访问

## 3.2	平台架构图
本次采取的产品方案是红帽Openshift3.5（参照应用使用版本，RHEL最新是7.3；使用一主多从模式）。
![56wqtaguht7i](/home/attachment/201901/15/1212257_154755844063749.png)
OCP以Docker技术和kubernetes框架为基础，在此之上扩展提供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程（s2i/jenkins）、统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案。

## 3.3	权限管理
对于企业级的应用平台来说，会有来自企业内外不同角色的用户，所以灵活的、细粒度的、可扩展的权限管理是必不可少的。OCP从设计初期就考虑到企业级用户的需求，所以在平台内部集成了标准化的认证服务器，并且定义了详细的权限策略和角色。

1.	认证：
OCP平台的用户是基于对OCP API的调用权限来定义的，由于OCP所有的操作都是基于API的，也就说用户可以是一个开发人员或者管理员，可以和OCP进行交互。OCP内置了一个基于OAuth的通用身份认证规范的服务器。这个OAuth服务器可以通过多种不同类型的认证源对用户进行认证。
2.	鉴权：
权策略决定了一个用户是否具有对某个对象的操作权限。管理员可以设置不同规则和角色，可以对用户或者用户组赋予一定的角色，角色包含了一系列的操作规则。
![n84m5y29wl2p](/home/attachment/201901/15/1212257_154755847554749.png)
除了传统的认证和鉴权功能，OCP还提供了针对pod的细粒度权限控SCC（security context constraints），可以限制pod具备何种类型的权限，比如容器是否可以运行在特权模式下、是否可以挂在宿主机的目录、是否可以使用宿主机的端口、是否可以以root用户运行等。
Openshift部署环境不与统一认证对接，采取预先创建账户基于Htpasswd存储的模式。

## 3.4	多租户管理
租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力。
在OCP中，project是一个进行租户隔离的概念，它来源于kubernetes的namespace，并对其进行了功能的扩展。利用Project，OCP平台从多个层面提供了多租户的支持。

1.	权限控制。通过OCP平台细粒度的权限管理机制，管理员可以对不同的用户和组设置不同project的权限，不同用户登录以后只能操作和管理特定的project
2.	网络隔离。OCP平台使用openvswitch来管理内部的容器网络，提供两种类型的网络模式，一种是集群范围内互通的平面网络，另一种是project级别隔离的网络。每个project都有一个虚拟网络ID（VNID），不同VNID的流量被openvswitch自动隔离。所以不同项目之间的服务在网络层不能互通。
3.	Router隔离。Router是OCP平台一个重要软件资源，它提供了外部请求导入OCP集群内部的能力。OCP提供了Router分组的功能，不同的project可以使用独立的Router，不互相干扰，这样就避免了由于某些应用流量过大时对其他应用造成干扰。
4.	物理资源池隔离。在多租户的环境中，为了提高资源的利用率一般情况下物理资源池是共享的，但是有些用户也会提供独占资源池的需求。针对这种类型的需求，OCP平台利用nodeSelector的功能可以将基础设施资源池划分给特定的project独享，实现从物理层面的隔离。

## 3.5	日志和监控
###3.5.1	传统应用日志
有别于当前流行的容器应用，的传统应用同时一个中间件会运行多个应用，且应用通过log4j等机制保存在文件中方便查看和排错。因为容器运行的特性，对于这部分的日志我们需要持久化到外置存储中。
日志的分类如下：

- 中间件日志
- dump文件
- 应用日志

日志保存在计算节点上挂载的NFS存储。为了规范和方便查找。日志将会按OCP平台中的namespace建立目录，进行划分。

###3.5.2	新应用日志
应对分布式环境下日志分散的解决办法是收集日志，将其集中到一个地方。收集到的海量日志需要经过结构化处理，进而交给需要的人员分析，挖掘日志的价值信息。同时不同的人员对日志的需求是不一样的，运营人员关注访问日志，运维人员关注系统日志，开发人员关注应用日志。这样就需要有一种足够开放、灵活的方法让所有关心日志的人在日志收集过程中对其定义、分割、过滤、索引、查询。
OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力：

- 日志采集，将日志集中在一起
- 索引日志内容，快速返回查询结果
- 具有伸缩性，在各个环节都能够扩容
- 强大的图形查询工具、报表产出工具

![o4c4mwy18y97](/home/attachment/201901/15/1212257_154755865986575.png)
EFK是Elasticsearch(以下简写为ES)+ Fluentd+Kibana的简称。ES负责数据的存储和索引，Fluentd负责数据的调整、过滤、传输，Kibana负责数据的展示。
Fluentd无论在性能上，还是在功能上都表现突出，尤其在收集容器日志领域更是独树一帜，成为众多PAAS平台日志收集的标准方案。
![eh215xq08x98](/home/attachment/201901/15/1212257_154755868677470.jpg)
Openshift部署环境使用EFK进行日志管理。QA环境和生产环境部署描述如下：
Fluentd以DaemonSet方式部署，将收集宿主机中的docker和OCP日志，并发送到ES。OCP集群内的每个结点都会启动一个Fluentd容器。
ES用于日志存储，会部署在infra结点，同时配置成replicas=2，实现高可用。

###3.5.3	监控
PaaS平台的监控包括系统监控、容器监控等。监控流程由信息收集、信息汇总和信息展示等几个部分组成。
在Openshift中默认使用kubenetes的监控信息收集机制，在每个节点上部署cadvisor的代理，负责收集容器级别的监控信息。然后将所有信息汇总到heapster，heapster后台的数据持久化平台是Cassandra。最后由hawkular从Cassandra获取信息进行统一的展示。

1.	组件说明
Openshift的监控组件，用于对pod运行状态的CPU、内存、网络进行实时监控，和Kubernetes使用的监控技术栈一样，包括三个部分：
1）	HEAPSTER
用于监控数据的采集
https://github.com/kubernetes/heapster
2）	HAWKULAR METRICS
属于开源监控解决方案Hawkular，基于JSON格式管理、展示监控数据
http://www.hawkular.org/
3）	CASSANDRA
Apache Cassandra是一个开源的分布式数据库，专门用于处理大数据量业务
http://cassandra.apache.org/

2.	架构概述
如下图所示，Heapster收集每个Node结点cAdvisor的监控数据，存入Cassandra，由Hawkuar Metrics展现：
![2dlj96veecb8](/home/attachment/201901/15/1212257_154755873132627.png)
QA环境和生产环境部署描述如下：
HEAPSTER, HAWKULAR, CASSANDRA组件都以容器方式运行在OCP计算结点中，并且分别配置成replicas=2，实现高可用。

3.	与OCP系统集成
1）	Web控制台
部署Metrics组件后，在OCP的Web控制台，可以看到监控信息。
在”Overview”页面，可以看到每个pod的CPU、内存、网络信息。
![s9v200psg8yv](/home/attachment/201901/15/1212257_154755876663305.png)
点击pod的Metrics按钮，可以看到一段时间内监控信息的变化数据：
![27n199qfw4q4](/home/attachment/201901/15/1212257_154755878622251.png)
2）	弹性伸缩
目前OCP系统可以基于CPU阈值的配置，对pod的复制数量进行弹性伸缩。而弹性伸缩的CPU数据，基于Metrics采集获取。相关介绍如下：
https://docs.openshift.org/latest/dev_guide/pod_autoscaling.html
3）	资源初始化
OCP系统可以基于类似pod资源消耗情况，对新部署pod的消耗资源进行预判，并以此分配初始资源。
4）	提供RestAPI
Hawkular Metrics提供了RestAPI接口，可以调用该接口进行监控、报警等进一步定制，参照：
https://github.com/openshift/origin-metrics/blob/master/docs/hawkular_metrics.adoc
Openshift部署环境使用自带的监控方式对容器和平台进行监控。

## 3.6	DMZ区计算节点应用部署方案
在DMZ区应用部署遵循以下策略：

- 已有应用迁移至容器云平台时的资源申请按现有配置设置，申请的服务器将仅供该使用
- 如果需要横向扩展，也仅在已分配的计算节点上，如果资源不足，应用项目组可再申请新的计算资源
- 本期项目中，XXX部署在DMZ区平台上，使用2个计算节点；XXX部署在内网平台上，使用2个计算节点
- 在实施时需要为相应的计算节点标记标签，使应用部署时部署到指定的计算节点上。

例如在DMZ网段对XXX应用所使用的2台计算节点打上标签
在部署XXX应用使，nodeSelector需要指明使用的节点的标签为XXX=XXX。

## 3.7	传统应用访问策略

- Openshift产品推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。
- 在F5 VS的Pool Member中配置所有节点，通过Keepalived来实现HA
- 应用系统和用户不用改变现有的访问方式

![i1cpxdglecm8](/home/attachment/201901/15/1212257_154755886650289.png)
配置了NodePort，应用的SVC显示为如下：
![5gbtq9hkablm](/home/attachment/201901/15/1212257_154755890853408.png)
![wca326fm0mxp](/home/attachment/201901/15/1212257_154755890838342.png)
我们可以直接通过端口30001访问应用。

## 3.8	数据库访问方案及防火墙策略
内网计算节点可以直接访问数据库
DMZ区计算节点访问数据库有2种方案：
•	计算节点直接通过内网防火墙访问该应用数据库
内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期项目，xxx应用仅使用2个节点，则防火墙仅开通这2个节点访问xxx数据库的权限
![st4d573o8ii9](/home/attachment/201901/15/1212257_154755894589533.png)
•	计算节点经Outbound 路由通过内网防火墙访问内网数据o
这oOutbound路由在Openshift中称之为Egress Routero
![xxf0ytr5dfc](/home/attachment/201901/16/301729_154761826945317.png)

因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A仅通过路由节点A和B访问内部数据库，则防火墙仅开通这2个节点访问A数据库的权限
![ult0k4j6la](/home/attachment/201901/16/301729_154761829144472.png)

## 3.9	高可用
###3.9.1	外部镜像仓库高可用
外部镜像仓库独立于OCP平台之外，用于存储平台构建过程中所使用的系统组件镜像。因为外部无法直接访问OCP平台的内部镜像仓库，所以由QA环境CD推送到生产环境的镜像也是先复制到外部镜像仓库，再由平台导入至内部镜像仓库。
为了保证外部镜像仓库的高可用， 使用了2台服务器，前端使用F5进行负载均衡，所有的请求均发至F5的虚拟地址，由F5进行转发。后端镜像仓库通过挂载NFS共享存储。
![nbeimwli0sbq](/home/attachment/201901/15/1212257_154755903626645.png)
###3.9.2	Master主控节点高可用
Openshift的Master主控节点承担了集群的管理工作，
![opl2ifj201o](/home/attachment/201901/16/301729_154761831780433.png)

###3.9.3	计算节点（容器应用）高可用
计算节点高可用指计算节点上运行的容器应用的高可用。一个计算节点异常停机后，其上的容器将会被逐步迁移到其他节点上，从而保证了高可用。
同时可以通过标签的方式来管理计算节点，在不同的计算节点划分为不同的可用区或组。在部署应用时，使用节点选择器将应用部署至带有指定标签的目标计算节点上。为了保证高可用，标签组合的目标计算节点数要大于1。这样可以避免一台目标节点宕机后，调度器还能找到满足条件的计算节点进行容器部署。
###3.9.4	应用高可用
基于软件（HAproxy）负载均衡服务，容器服务弹性伸缩时无需人工对负载均衡设备进行配置干预，即可保证容器化应用的持续、正常访问；可通过图形界面自定义负载均衡会话保持策略。
由于平台内部通过软件定义网络为每个应用容器分配了IP地址，而此地址是内网地址，因此外部客户无法直接访问到该地址，所以平台使用路由器转发外部的流量到集群内部具体的应用容器上，如果应用有多个容器实例，路由器也可实现负载均衡的功能。路由器会动态的检测平台的元数据仓库，当有新的应用部署或者应用实例发生变化时，路由器会自动根据变化更新路由信息，从而实现动态负载均衡的能力。
![jusrd15f3nxh](/home/attachment/201901/15/1212257_154755909992390.png)
## 3.10	docker本地存储
docker运行过程中会将镜像下载到本地，此存储空间称为docker storage 。
在我们的平台中，每一台服务器都挂载了100GB的本地存储，通过运行docker-storage-setup，由平台自动设置。设置方法参考安装手册。
OCP平台自动设置后的sdb如下图：
![od0lo3ktc8t4](/home/attachment/201901/15/1212257_154755913115940.png)
##3.11	持久化存储
持久化存储分为平台内置组件的持久化存储和应用的持久化存储。
###3.11.1	平台持久化存储
在平台中需要使用到持久化存储的组件包含以下

- 外部镜像仓库：共享NAS
- 内部镜像仓库：共享NAS
- ES服务器：独占SAN

# 4	项目总结
云计算使传统意义上的数据中心从原来的成本中心转变成服务中心，支持向公司内部输出规范的、有质量保证的服务，降低服务成本、运营成本的同时促进IT部门运维模式发展变革，简化系统建设、运维工作，提升工作效率。
项目建成后，将会对保险IT业务带来如下提升：
**缩短上线周期**
云计算的引入能够显著缩短硬件资源、平台环境、应用系统的部署周期，支持各部门在最短时间内以“随需即取”的方式获取系统部署所需的一切服务资源，运维管理团队即可根据服务模板实现远程快速部署和动态调整，减少重复性建设工作，支撑业务的快速发展变化。
**进一步实现绿色节能**
云计算构建于池化的硬件资源基础上，并进一步实现服务化封装及更高层级的细粒度服务复用，从而相应降低对数据中心机房的电力、制冷、空间消耗，实现机房绿色节能。
**促进运维模式发展变革**
针对业务需求部门提供自助式服务，需求部门依据定制的云服务目录选取所需的计算资源、存储空间、网络服务、基础平台环境等服务项并提交申请，运维管理团队根据定制成型的服务模板，依靠自动化技术及云管理平台来交付规范的、有质量保证的服务，将传统运维模式转变为以服务为中心的方式，降低系统建设、运维、管理工作量。

保险容器云平台项目规划需求分析项目实施 PaaS

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论1 条评论

wuwenpin软件开发工程师南京
2019-01-16 14:08

收藏了！！

Ctrl+Enter 发表

匿名评论

某保险paas容器云平台项目实践

添加新评论1 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料