容器生产落地需要考虑的几点因素

前言：

本文是笔者与同事陈耿共同完成，不代表任何官方观点。

随着容器技术的持续发酵，以及互联网+应用的持续扩张，目前金融行业使用容器云上生产的案例越来越多。在本文正式开始之前，先看看Dockerr和K8S的社区代码贡献情况。

社区中，Docker代码贡献量各厂商排名：

社区中K8S代码贡献量排名：

以Docker和K8S为基础的、作为一款优秀的容器云平台OpenShift，其在金融行业的案例越来越多。那么，有人会问：是否所有的应用都适合容器平台？我们在评估容器能否在自己的生产商落地，都需要考虑哪些因素？

容器在生产上落地需要考虑的几个因素

1. 应用的容器化改造
2. 容器的高可用性
3. 容器的运维
4. 容器的安全性
5. 容器的多租户隔离
6. 容器的持久化存储

第一个因素：应用的容器化改造

针对容器平台，很多容器原生应用可以直接使用。但对于传统应用，容器平台的准入标准是什么？请参照以下5个标准：

那么，针对不符合准入标准的传统应用，如何实现容器化改造呢？

可以通过四个阶段的工作来完成，分别是：制作基础镜像、应用容器化迁移、数据库和中间件容器化、数据库和中间件迁移。

关于容器镜像制作，有三种方法：最常用的方法是手工编写Docker file，手工构建。这种方法简单，但随着容器数量的增加，手工编写Docker file的工作量将会大幅增加。

因此我们需要寻找自动化构建容器镜像的方法。这里我们有两个：通过CI构建和S2I（Source to Image）。S2I是红帽的独创，独立于Docker和K8S之外。

基于S2I的容器镜像构建说明和优势如下：

S2I流程解析如下：

关于应用容器化迁移，应该说，web类的应用迁移起来难度最低；Java、PHP、Python类的应用迁移难度小于C。在数据库层面，Redis、mariadb、Mysql等分布式数据库本身已经有了容器化镜像，因此使用起来不存在太高难度。

第二个因素:容器的高可用性

容器的高可用性，包括两部分内容：容器云的基础架构高可用，和运行应用的容器高可用。

OpenShift的基础架构高可用实现方式如下，即对Master、Registry、Router、Storage均实现多节点部署，消除单点故障。

运行应用的容器高可用是通过K8S的功能实现的。当运行容器的一个计算节点出现故障后，K8S会在其他计算节点上重启这个pod。

第三个因素：容器的运维

容器的运维主要包含两方面：容器的日志管理和容器监控。

在日志管理方面，OpenShift使用EFK。E:Elasticsearch、F:Fluentd、K:Kibana。Elasticsearch负责数据的存储和索引，Fluentd负责数据的调整、过滤、传输，Kibana负责数据的展示。

三者工作逻辑图如下：

在监控方面：OpenShift的监控组件，用于对pod运行状态的CPU、内存、网络进行实时监控，和Kubernetes使用的监控技术栈一样，包括三个部分：如下图

Heapster收集每个Node结点cAdvisor的监控数据，存入Cassandra，由Hawkular 、Metrics展现：

第四个因素：容器的安全性

企业级容器方案的安全，通过四面方保证：容器宿主机的安全、容器隔离、容器镜像安全、补丁安全。

而在容器安全这件事上，红帽做了什么？

第一：宿主机安全。OpenShift中的容器的宿主是Redhat EnterpriseLinux操作系统。红帽的企业级Linux RHEL是业内安全性最高的操作系统。RHEL通过Selinux可以大幅提高Linux操作系统本身的安全性。、

第二：容器隔离。在容器隔离方面，RHEL的Secure computing技术，可以使一个进程进入到一种“安全”运行模式。我们知道，容器对于Linux操作系统而言，就是一个进程。安全运行模式下，容器只能进行有限的Kernel系统调用，从而避免出现容器逃逸的问题。

第三，容器镜安全。红帽提供的容器操作系统和应用是经过红帽安全认证的。根据统计数字表明，在Docker hub上，近1/3的Docker镜像多少存在一些安全方面的漏洞。

而红帽提供了类似一个苹果Appstore的官方镜像仓库，里面包含超过200中基础应用镜像。使用红帽OpenShift订阅的客户可以免费使用这些安全的，经过红帽认证的，提供技术支持的镜像。

https://access.redhat.com/containers/

第四，补丁安全

红帽积极为openshit提供补丁更新，对于红帽OpenShift用户，第一时间主动推送新的安全补丁，保证宿主机操作系统RHEL和容器镜像的安全。

第五个因素：容器的多租户隔离

多租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力。

在OpenShift中，project是一个进行租户隔离的概念，它来源于kubernetes的namespace，并对其进行了功能的扩展。利用Project，OpenShift平台从多个层面提供了多租户的支持。

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

第六个因素：容器的持久化存储

对于基于容器的新型应用来说，容器会被经常性的创建和销毁，也会在不同的主机之间快速的迁移。为了保证容器在重启或者迁移以后能够使用原来的数据，就必须使用持久化存储。所以，持久化存储的管理对于企业容器平台来说就显得非常重要。

Openshift默认配置中就支持NFS、GlusterFS、Cinder、Ceph、EBS、iSCSI和Fibre Channel等存储。

在实际的案例中，openshift对接最多的持久化存储是Gluster。目前OpenShift与GlusterFS可以做到无缝集成，甚至“超融合”架构（OpenShift计算节点同时属于Gluster集群）。初次之外，Openshift在某些应用使用场景下，也可以和Ceph对接（RBD），实现持久化存储，而随着CephFS的成熟，OpenShift与CephFS无缝对接指日可待。

总结：

关于“容器在生产上落地需要考虑的几个因素”这个话题，本文列出的六个仅是比较常见的几个。客户应用和环境不同，需要考虑的因素可能会超出这六个。但无论如何，对于业务稳定性要求较高的金融行业，应选取稳定而可靠的容器云平台。