容器云落地金融行业的选型及技术细节探讨
通过近十年云化的推进，大多数有一定规模的企业已经实现了基础架构资源的云化和池化，但通过IaaS获取的大量的基础架构资源并不能被我们的最终业务应用直接消费。应用还必须进行或繁或简的部署和配置，才可能运行在云化的虚拟机之上。而部署的过程在一些企业仍然是通过手工完成，低效且容易出错。有的企业则是通过简单的自动化方式完成，提高了效率，但是满足不了后期更高级别的要求，如动态扩容、持续部署。即使勉强通过了简单的自动化实现，后期随着部署平台类型的增多以及复杂化，维护的难度将会陡然增高，无法真正做到随时随地持续交付、部署。
基于这个背景，业界需要有一种手段来填充业务应用和基础架构资源的这道鸿沟。让应用可以做到“一键式”快速的在基础架构资源上运行。Docker通过对Linux内核已有机能的整合和强化，为业务应用提供了一个绝妙的方案。其简单易用的用户命令行，让Docker快速地获取了巨大的用户基础，也成就了今日其在容器界的地位。目前Docker结合Kubernetes的解决方案是业界应用最为广泛的容器云解决方案。
在1月25日的线上活动交流中，围绕容器云落地金融行业的可行性分析，容器云和docker/openstack/openshift之间的关系，容器云落地技术细节等方面进行了讨论，得到了各位专家的支持。在此，由社区专家顾文俊对大家关注的问题以及针对这些问题各位专家的观点总结成文，供大家参考。
以下分享主要来自：Garyy、Steven99
一、容器云落地金融行业可行性分析
Q1: 在传统应用往容器迁移需要哪些注意事项？是不是所有应用都可以迁移到容器上？
■ Garyy
从理论上来讲，所有的应用应该都是可以迁移到容器环境的。但是，在实际的场景中，往往一些需要弹性伸缩，无状态服务的那些应用，会优先考虑使用容器的场景。传统应用向容器环境的迁移，需要注意到：
1）访问的策略/权限的变化
2）服务拆分，是否是微服务化
3）存储数据，是有状态还是无状态，是临时数据还是持久化存储数据
4）高可用场景
Q2: 传统保险行业转型为微服务架构，原来的老架构的业务如何拆分成符合微服的形式？
A2:
■ Steven99
微服务架构在数据层是根据微服务划分把数据分离，但并隔离数据，而是通过提供数据服务（实现数据中台）为其他微服务或业务应用提供数据支持。因此一个微服务可以有自己独立的数据库（可能不需要oracle那么强大的数据库了）。
中间件是需要的，比如消息中间件，需要分布式部署，以支持分布式消息处理。
数据层数据模型的重构必然会影响业务逻辑的封装。
服务编排，和容器编排我们觉得还不一样。我们更希望在服务层去考虑业务逻辑的编排。容器更多是使用其弹性、无状态等特性。
■ Garyy
数据库一般像oracle，mysql都是主从模式或者双主模式，很少有分布式的场景；中间件，像weblogic有分布式的部署方式。
业务逻辑有很大的变化，微服务的架构设计总体上是采用了服务注册，服务发布等方式对传统的服务进行了拆分，使得各个服务之间解耦。
编排一般采用了k8s的容器部署方式来解决。
Q3: 容器云对业务办理有哪些方面的改革和提升？
■ Garyy
云计算使传统意义上的数据中心从原来的成本中心转变成服务中心，支持向公司内部输出规范的、有质量保证的服务，降低服务成本、运营成本的同时促进IT部门运维模式发展变革，简化系统建设、运维工作，提升工作效率。
项目建成后，将会对大地保险IT业务带来如下提升：
缩短上线周期
云计算的引入能够显著缩短硬件资源、平台环境、应用系统的部署周期，支持各部门在最短时间内以“随需即取”的方式获取系统部署所需的一切服务资源，运维管理团队即可根据服务模板实现远程快速部署和动态调整，减少重复性建设工作，支撑业务的快速发展变化。
进一步实现绿色节能
云计算构建于池化的硬件资源基础上，并进一步实现服务化封装及更高层级的细粒度服务复用，从而相应降低对数据中心机房的电力、制冷、空间消耗，实现机房绿色节能。
促进运维模式发展变革
针对业务需求部门提供自助式服务，需求部门依据定制的云服务目录选取所需的计算资源、存储空间、网络服务、基础平台环境等服务项并提交申请，运维管理团队根据定制成型的服务模板，依靠自动化技术及云管理平台来交付规范的、有质量保证的服务，将传统运维模式转变为以服务为中心的方式，降低系统建设、运维、管理工作量。
Q4: PAAS云平台选型？Openshift开源版稳定性怎么样？
■ Steven99
总的来说openshift是基于Kuberentes之上的，所以比k8s 要完善些，稳定性应该说更好些。但openshift商业版费用还是不低，特别是实时费用。不管k8s或openshift其实目前都不算是成熟的平台，都需要很多额外的工作，因此如果选择商用版本成本会比较高。在目前基本上都处于概念验证阶段，投资太大也不见得就一定能有好的收益。所以大多数都是选择开源版本测试，上生产也大多是非核心业务，无关大局。
■ Garyy
业界需要有一种手段来填充业务应用和基础架构资源的这道鸿沟。让应用可以做到“一键式”快速的在基础架构资源上运行。为了实现这个目标，业界出现了多种不同的平台，即服务云的容器方案。最终命运之神的棒槌砸到了一个叫Docker的开源项目上。Docker通过对Linux内核已有机能的整合和强化，为业务应用提供了一个绝妙的方案。最后其简单易用的用户命令行，让Docker快速地获取了巨大的用户基础，也成就了今日其在容器界的地位。目前Docker结合Kubernetes的解决方案是业界应用最为广泛的容器云解决方案。Kubernetes是Google开源的容器集群管理系统。它构建Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的Micro-PaaS平台，即第三代PaaS的代表性项目。
二、容器云和docker/openstack/openshift之间的关系
Q1: Docker是必须要和k8s结合使用么？
■ Steven99
docker是容器，可以单独用。
k8s是容器调度管理框架，可以调度docker，也可以调度其他支持的容器。
■ Garyy
docker可以单独的使用在某些环境中，k8s是一个容器的使用平台，通过一些机制保证了容器在某些流程中的顺利运行。为开发测试生产的流程打通提供了解决方案。
Q2：openstack里好多容器相关的项目，各自特色和成熟度怎样？
■ Garyy
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容器云平台统一资源池有啥好方法？
■ Garyy
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是什么关系？
■ Garyy
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: 容器的双活解决方案有哪些？
■ Garyy
从问题的提出来看，可能涉及到几个方面：
1）容器平台的双活
这个主要涉及到多个pod节点之间的冗余或者说高可用，这个k8s的架构可以保证其高可用
2）容器自身的双活
这个可以由容器平台来保证，保证同时有>=2个的容器在对外提供服务，如果容器的数量少于2个的话，立即启动一个相同的的容器，来对外提供服务。
■ michael1983
应用多活是根本，容器、虚机都只是手段。
Q2: 容器云的持久化存储设计，使用传统存储，还是分布式存储，哪个更加合适？
■ Garyy
持久化存储一般是通过plungin进行驱动的，无论对于传统存储，还是分布式存储，驱动的模式都是一样的。
至于到底是采用传统存储，还是分布式存储，主要还是要看存储场景，内容，以及存储是否需要支持弹性伸缩。传统存储在可靠性，安全性以及易用性方面，都有比较好的技术支持；分布式存储是最近几年兴起的，在不断的完善中形成了对传统存储的挑战，无论在技术的成熟度还是服务的支持力度上，相对传统存储还是有一定的差距的，但是它代表了未来存储发展的方向，有很多企业投入了很大的精力去发展它，未来肯定会取代大部分传统存储的场景。
Q3: 在落地金融保险行业的过程中，对于数据库，对于传统应用的访问策略有什么特别之处？
■ Garyy
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: 容器云平台在监控方面与传统的环境有什么不同？对日志的处理，有什么特别之处？
■ Garyy
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: 容器可以像虚拟机一样漂移么？
■ Garyy
容器的属性不依赖于某一个固定的虚拟机或者物理机，可以在不同的物理机和虚拟机之间漂移。
需要注意的是，在漂移的过程中，其网络属性需要能够随之进行迁移。这个需要在配置中将其网络标签支持漂移。
Q6: 容器云平台在落地金融机构的过程中，如何进行安全、鉴权方面的设计？
■ Garyy
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从设计初期就考虑到企业级用户的需求，所以在平台内部集成了标准化的认证服务器，并且定义了详细的权限策略和角色。
1. 认证：
OCP平台的用户是基于对OCP API的调用权限来定义的，由于OCP所有的操作都是基于API的，也就说用户可以是一个开发人员或者管理员，可以和OCP进行交互。OCP内置了一个基于OAuth的通用身份认证规范的服务器。这个OAuth服务器可以通过多种不同类型的认证源对用户进行认证。
2. 鉴权：
权策略决定了一个用户是否具有对某个对象的操作权限。管理员可以设置不同规则和角色，可以对用户或者用户组赋予一定的角色，角色包含了一系列的操作规则。
Q7: 容器一定要基于虚拟机么？
■ Steven99
选择虚拟机或者物理机一般基于公司实际情况决定，如果已经做了虚拟化，建议考虑基于虚拟化建设容器平台，这样对于基础节点的管理会方便些，可以利用虚拟化快捷部署的优点。特别在达到一定量的情况下，资源共享是云计算的一个重要特征。虽然虚拟化一层会造成性能损失，但当前机器配置通常是可以接受的。虚拟化也提供了一层隔离，安全性应该说更好。
Q8: 如何保证容器云架构的高可用？
■ Garyy
容器云的高可用包括了几个方面：
1）外部镜像仓库高可用
外部镜像仓库独立于OCP平台之外，用于存储平台构建过程中所使用的系统组件镜像。因为外部无法直接访问OCP平台的内部镜像仓库，所以由QA环境CD推送到生产环境的镜像也是先复制到外部镜像仓库，再由平台导入至内部镜像仓库。
为了保证外部镜像仓库的高可用， 使用了2台服务器，前端使用F5进行负载均衡，所有的请求均发至F5的虚拟地址，由F5进行转发。后端镜像仓库通过挂载NFS共享存储。
2）master主控节点高可用
3）计算节点高可用
计算节点高可用指计算节点上运行的容器应用的高可用。一个计算节点异常停机后，其上的容器将会被逐步迁移到其他节点上，从而保证了高可用。
同时可以通过标签的方式来管理计算节点，在不同的计算节点划分为不同的可用区或组。在部署应用时，使用节点选择器将应用部署至带有指定标签的目标计算节点上。为了保证高可用，标签组合的目标计算节点数要大于1。这样可以避免一台目标节点宕机后，调度器还能找到满足条件的计算节点进行容器部署。
4）应用高可用
基于软件（HAproxy）负载均衡服务，容器服务弹性伸缩时无需人工对负载均衡设备进行配置干预，即可保证容器化应用的持续、正常访问；可通过图形界面自定义负载均衡会话保持策略。
由于平台内部通过软件定义网络为每个应用容器分配了IP地址，而此地址是内网地址，因此外部客户无法直接访问到该地址，所以平台使用路由器转发外部的流量到集群内部具体的应用容器上，如果应用有多个容器实例，路由器也可实现负载均衡的功能。路由器会动态的检测平台的元数据仓库，当有新的应用部署或者应用实例发生变化时，路由器会自动根据变化更新路由信息，从而实现动态负载均衡的能力。
推荐资料：
某保险容器云平台实践
http://www.talkwithtrend.com/Document/detail/tid/421969
点击阅读原文关注社区 ”容器云“技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”