通过近十年云化的推进，大多数有一定规模的企业已经实现了基础架构资源的云化和池化，这里的资源指的是诸如虚拟机、数据库、网络、存储。用户可以用很短的时间获取业务应用所需的机器、存储和数据库。基础架构资源云化其实并不是目的，而是手段。最终的目标是让承载业务的应用可以更快地上线。但现实是，通过IaaS获取的大量的基础架构资源并不能被我们的最终业务应用直接消费。应用还必须进行或繁或简的部署和配置，才可能运行在云化的虚拟机之上。部署涉及操作系统配置的修改、编程语言运行环境的安装配置以及中间件的安装配置等。部署的过程在一些企业仍然是通过手工完成，低效且容易出错。有的企业则是通过简单的自动化方式完成，提高了效率，但是满足不了后期更高级别的要求，如动态扩容、持续部署。即使勉强通过了简单的自动化实现，后期随着部署平台类型的增多以及复杂化，维护的难度将会陡然增高，无法真正做到随时随地持续交付、部署。

基于这个背景，业界需要有一种手段来填充业务应用和基础架构资源的这道鸿沟。让应用可以做到“一键式”快速的在基础架构资源上运行。为了实现这个目标，业界出现了多种不同的平台，即服务云的容器方案。最终命运之神的棒槌砸到了一个叫Docker的开源项目上。Docker通过对Linux内核已有机能的整合和强化，为业务应用提供了一个绝妙的方案。最后其简单易用的用户命令行，让Docker快速地获取了巨大的用户基础，也成就了今日其在容器界的地位。目前Docker结合Kubernetes的解决方案是业界应用最为广泛的容器云解决方案。Kubernetes是Google开源的容器集群管理系统。它构建Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的Micro-PaaS平台，即第三代PaaS的代表性项目。
在1月25日的线上活动交流中，围绕容器云落地金融行业的可行性分析，容器云和docker/openstack/openshift之间的关系，容器云落地技术细节等方面进行了讨论，得到了各位专家的支持。大家针对容器云如何在金融保险行业落地相关的问题，体现出了高度的参与热情。在此，对大家关注的问题以及针对这些问题各位专家的观点总结如下：

问题分类解答

一、容器云落地金融行业可行性分析

Q1: 在传统应用往容器迁移需要哪些注意事项？是不是所有应用都可以迁移到容器上？
A1:
从理论上来讲，所有的应用应该都是可以迁移到容器环境的。但是，在实际的场景中，往往一些需要弹性伸缩，无状态服务的那些应用，会优先考虑使用容器的场景。传统应用向容器环境的迁移，需要注意到：
1）访问的策略/权限的变化
2）服务拆分，是否是微服务化
3）存储数据，是有状态还是无状态，是临时数据还是持久化存储数据
4）高可用场景

Q2: 传统保险行业转型为微服务架构，原来的老架构的业务如何拆分成符合微服的形式？
A2:
微服务架构在数据层是根据微服务划分把数据分离，但并隔离数据，而是通过提供数据服务（实现数据中台）为其他微服务或业务应用提供数据支持。因此一个微服务可以有自己独立的数据库（可能不需要oracle那么强大的数据库了）。
中间件是需要的，比如消息中间件，需要分布式部署，以支持分布式消息处理。
数据层数据模型的重构必然会影响业务逻辑的封装
服务编排，和容器编排我们觉得还不一样。我们更希望在服务层去考虑业务逻辑的编排。容器更多是使用其弹性、无状态等特性
数据库一般像oracle，mysql都是主从模式或者双主模式，很少有分布式的场景；中间件，像weblogic有分布式的部署方式
业务逻辑有很大的变化，微服务的架构设计总体上是采用了服务注册，服务发布等方式对传统的服务进行了拆分，使得各个服务之间解耦
编排一般采用了k8s的容器部署方式来解决

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

Q4: PAAS云平台选型？
A4:
总的来说openshift是基于Kuberentes之上的，所以比k8s 要完善些，稳定性应该说更好些。但openshift商业版费用还是不低，特别是实时费用。不管k8s或openshift其实目前都不算是成熟的平台，都需要很多额外的工作，因此如果选择商用版本成本会比较高。在目前基本上都处于概念验证阶段，投资太大也不见得就一定能有好的收益。所以大多数都是选择开源版本测试，上生产也大多是非核心业务，无关大局。
基于这个背景，业界需要有一种手段来填充业务应用和基础架构资源的这道鸿沟。让应用可以做到“一键式”快速的在基础架构资源上运行。为了实现这个目标，业界出现了多种不同的平台，即服务云的容器方案。最终命运之神的棒槌砸到了一个叫Docker的开源项目上。Docker通过对Linux内核已有机能的整合和强化，为业务应用提供了一个绝妙的方案。最后其简单易用的用户命令行，让Docker快速地获取了巨大的用户基础，也成就了今日其在容器界的地位。目前Docker结合Kubernetes的解决方案是业界应用最为广泛的容器云解决方案。Kubernetes是Google开源的容器集群管理系统。它构建Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的Micro-PaaS平台，即第三代PaaS的代表性项目。

二、容器云和docker/openstack/openshift之间的关系

Q1: Docker是必须要和k8s结合使用么？
A1:
docker是容器，可以单独用
k8s是容器调度管理框架，可以调度docker，也可以调度其他支持的容器
docker可以单独的使用在某些环境中，k8s是一个容器的使用平台，通过一些机制保证了容器在某些流程中的顺利运行。为开发测试生产的流程打通提供了解决方案

Q2：openstack里好多容器相关的项目，各自特色和成熟度怎样？
A2:
1）zun
Zun是Openstack中提供容器管理服务的组件，于2016年6月建立。Zun的目标是提供统一的Openstack API用于启动和管理容器，支持多种容器技术。Zun原来称为Higgins，后改名为Zun。Zun计划支持多种容器技术，Docker，Rkt，clear container等，目前只支持Docker。OpenStack Queens版本发布，由于容器社区的火热，一项值得关注的补充则为“Zun”，它在OpenStack项目中负责提供容器服务，旨在通过与Neutron、Cinder、Keystone以及其它核心OpenStack服务相集成以实现容器的快速普及。通过这种方式，OpenStack的原有网络、存储以及身份验证工具将全部适用于容器体系，从而确保容器能够满足安全与合规性要求。
2）magnum
Magnum是OpenStack中一个提供容器集群部署的服务。
Magnum是一个Pass层的OpenStack项目。
Magnum使用Heat部署一个包含Docker和Kubernetes的操作系统镜像，让容器集群运行在虚拟机（Virtual Machine）或者裸机（Bare Metal）中。
3）kolla
简单来说，Kolla 就是充分应用容器特性，实现容器化部署 OpenStack 服务的 DevOps 工具。
Kolla 显著的特点是「开箱即用」和「简易升级」，前者由编排工具（Ansible/Kubernetes）提供自动化支撑，后者则完全是 Container 的功劳。Kolla 追求为每一个 OpenStack Service 都构建相应的 Container，将升级/回滚的粒度（隔离依赖关系集）降维到 Service 或 Project 级别，实现升级/回滚的原子性。假若升级失败，则直接启动 Old Version Container 完成回滚。
4）kuryr
Kuryr最开始创立的时候，其目的是为了提供Docker与Neutron的连接。将Neutron的网络服务带给Docker。随着容器的发展，容器网络的发展也出现了分歧。主要分为两派，一个是Docker原生的CNM（ContainerNetwork Model），另一个是兼容性更好的CNI（Container Network Interface）。Kuryr相应的也出现了两个分支，一个是kuryr-libnetwork（CNM），另一个是kuryr-kubernetes（CNI）。

Q3：openstack里利用裸机部署k8s容器云平台统一资源池有啥好方法？
A3:
Zun是Openstack中提供容器管理服务的组件，于2016年6月建立。Zun的目标是提供统一的Openstack API用于启动和管理容器，支持多种容器技术。Zun原来称为Higgins，后改名为Zun。Zun计划支持多种容器技术，Docker，Rkt，clear container等，目前只支持Docker。OpenStack Queens版本发布，由于容器社区的火热，一项值得关注的补充则为“Zun”，它在OpenStack项目中负责提供容器服务，旨在通过与Neutron、Cinder、Keystone以及其它核心OpenStack服务相集成以实现容器的快速普及。通过这种方式，OpenStack的原有网络、存储以及身份验证工具将全部适用于容器体系，从而确保容器能够满足安全与合规性要求。

Q4：红帽的openshift平台和kubernets是什么关系？
A4:
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变革和转型。

三、容器云落地技术细节

Q1: 容器的双活解决方案有哪些？
A1:
从问题的提出来看，可能涉及到几个方面：
1）容器平台的双活
这个主要涉及到多个pod节点之间的冗余或者说高可用，这个k8s的架构可以保证其高可用
2）容器自身的双活
这个可以由容器平台来保证，保证同时有>=2个的容器在对外提供服务，如果容器的数量少于2个的话，立即启动一个相同的的容器，来对外提供服务。
应用多活是根本，容器、虚机都只是手段。

Q2: 容器云的持久化存储设计，使用传统存储，还是分布式存储，哪个更加合适？
A2:
持久化存储一般是通过plungin进行驱动的，无论对于传统存储，还是分布式存储，驱动的模式都是一样的。
至于到底是采用传统存储，还是分布式存储，主要还是要看存储场景，内容，以及存储是否需要支持弹性伸缩。传统存储在可靠性，安全性以及易用性方面，都有比较好的技术支持；分布式存储是最近几年兴起的，在不断的完善中形成了对传统存储的挑战，无论在技术的成熟度还是服务的支持力度上，相对传统存储还是有一定的差距的，但是它代表了未来存储发展的方向，有很多企业投入了很大的精力去发展它，未来肯定会取代大部分传统存储的场景。

Q3: 在落地金融保险行业的过程中，对于数据库，对于传统应用的访问策略有什么特别之处
A3:
1）对于传统应用的访问策略
• Openshift产品推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。
• 在F5 VS的Pool Member中配置所有节点，通过Keepalived来实现HA
• 应用系统和用户不用改变现有的访问方式
2）数据库访问方案
内网计算节点可以直接访问数据库
DMZ区计算节点访问数据库有2种方案：
• 计算节点直接通过内网防火墙访问该应用数据库
内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期项目，xxx应用仅使用2个节点，则防火墙仅开通这2个节点访问xxx数据库的权限
• 计算节点经Outbound 路由通过内网防火墙访问内网数据o
这oOutbound路由在Openshift中称之为Egress Routero
因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A仅通过路由节点A和B访问内部数据库，则防火墙仅开通这2个节点访问A数据库的权限

Q4: 容器云平台在监控方面与传统的环境有什么不同？对日志的处理，有什么特别之处
A4:
1）传统应用日志
有别于当前流行的容器应用，的传统应用同时一个中间件会运行多个应用，且应用通过log4j等机制保存在文件中方便查看和排错。因为容器运行的特性，对于这部分的日志我们需要持久化到外置存储中。
日志的分类如下：
• 中间件日志
• dump文件
• 应用日志
日志保存在计算节点上挂载的NFS存储。为了规范和方便查找。日志将会按OCP平台中的namespace建立目录，进行划分。
2）新应用日志
应对分布式环境下日志分散的解决办法是收集日志，将其集中到一个地方。收集到的海量日志需要经过结构化处理，进而交给需要的人员分析，挖掘日志的价值信息。同时不同的人员对日志的需求是不一样的，运营人员关注访问日志，运维人员关注系统日志，开发人员关注应用日志。这样就需要有一种足够开放、灵活的方法让所有关心日志的人在日志收集过程中对其定义、分割、过滤、索引、查询。
OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力：
■ 日志采集，将日志集中在一起
■ 索引日志内容，快速返回查询结果
■ 具有伸缩性，在各个环节都能够扩容
■ 强大的图形查询工具、报表产出工具
EFK是Elasticsearch(以下简写为ES)+ Fluentd+Kibana的简称。ES负责数据的存储和索引，Fluentd负责数据的调整、过滤、传输，Kibana负责数据的展示。
Fluentd无论在性能上，还是在功能上都表现突出，尤其在收集容器日志领域更是独树一帜，成为众多PAAS平台日志收集的标准方案。
Openshift部署环境使用EFK进行日志管理。QA环境和生产环境部署描述如下：
Fluentd以DaemonSet方式部署，将收集宿主机中的docker和OCP日志，并发送到ES。OCP集群内的每个结点都会启动一个Fluentd容器。
ES用于日志存储，会部署在infra结点，同时配置成replicas=2，实现高可用。
3）监控
PaaS平台的监控包括系统监控、容器监控等。监控流程由信息收集、信息汇总和信息展示等几个部分组成。
在Openshift中默认使用kubenetes的监控信息收集机制，在每个节点上部署cadvisor的代理，负责收集容器级别的监控信息。然后将所有信息汇总到heapster，heapster后台的数据持久化平台是Cassandra。最后由hawkular从Cassandra获取信息进行统一的展示。

Q5: 容器可以像虚拟机一样漂移么？
A5:
容器的属性不依赖于某一个固定的虚拟机或者物理机，可以在不同的物理机和虚拟机之间漂移。
需要注意的是，在漂移的过程中，其网络属性需要能够随之进行迁移。这个需要在配置中将其网络标签支持漂移。

Q6: 容器云平台在落地金融机构的过程中，如何进行安全、鉴权方面的设计？
A6:
1）多租户管理
租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力。
在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独享，实现从物理层面的隔离。
   2）权限管理
   对于企业级的应用平台来说，会有来自企业内外不同角色的用户，所以灵活的、细粒度的、可扩展的权限管理是必不可少的。OCP从设计初期就考虑到企业级用户的需求，所以在平台内部集成了标准化的认证服务器，并且定义了详细的权限策略和角色。
5. 认证：
   OCP平台的用户是基于对OCP API的调用权限来定义的，由于OCP所有的操作都是基于API的，也就说用户可以是一个开发人员或者管理员，可以和OCP进行交互。OCP内置了一个基于OAuth的通用身份认证规范的服务器。这个OAuth服务器可以通过多种不同类型的认证源对用户进行认证。
6. 鉴权：
   权策略决定了一个用户是否具有对某个对象的操作权限。管理员可以设置不同规则和角色，可以对用户或者用户组赋予一定的角色，角色包含了一系列的操作规则。

Q7: 容器一定要基于虚拟机么？
A7:
选择虚拟机或者物理机一般基于公司实际情况决定.如果已经做了虚拟化,建议考虑基于虚拟化建设容器平台,这样对于基础节点的管理会方便些,可以利用虚拟化快捷部署的优点.特别在达到一定量的情况下,资源共享是云计算的一个重要特征.虽然虚拟化一层会造成性能损失,但当前机器配置通常是可以接受的.虚拟化也提供了一层隔离,安全性应该说更好.

Q8: 如何保证容器云架构的高可用？
A8:
容器云的高可用包括了几个方面：
1）外部镜像仓库高可用
外部镜像仓库独立于OCP平台之外，用于存储平台构建过程中所使用的系统组件镜像。因为外部无法直接访问OCP平台的内部镜像仓库，所以由QA环境CD推送到生产环境的镜像也是先复制到外部镜像仓库，再由平台导入至内部镜像仓库。
为了保证外部镜像仓库的高可用， 使用了2台服务器，前端使用F5进行负载均衡，所有的请求均发至F5的虚拟地址，由F5进行转发。后端镜像仓库通过挂载NFS共享存储。
2）master主控节点高可用
3）计算节点高可用
计算节点高可用指计算节点上运行的容器应用的高可用。一个计算节点异常停机后，其上的容器将会被逐步迁移到其他节点上，从而保证了高可用。
同时可以通过标签的方式来管理计算节点，在不同的计算节点划分为不同的可用区或组。在部署应用时，使用节点选择器将应用部署至带有指定标签的目标计算节点上。为了保证高可用，标签组合的目标计算节点数要大于1。这样可以避免一台目标节点宕机后，调度器还能找到满足条件的计算节点进行容器部署。
4）应用高可用
基于软件（HAproxy）负载均衡服务，容器服务弹性伸缩时无需人工对负载均衡设备进行配置干预，即可保证容器化应用的持续、正常访问；可通过图形界面自定义负载均衡会话保持策略。
由于平台内部通过软件定义网络为每个应用容器分配了IP地址，而此地址是内网地址，因此外部客户无法直接访问到该地址，所以平台使用路由器转发外部的流量到集群内部具体的应用容器上，如果应用有多个容器实例，路由器也可实现负载均衡的功能。路由器会动态的检测平台的元数据仓库，当有新的应用部署或者应用实例发生变化时，路由器会自动根据变化更新路由信息，从而实现动态负载均衡的能力。