云计算架构师分享：容器云在金融企业的落地方案

前言

国内保险业客户向线上迁徙，对于保险产品和服务形式的期望集中在简单、便捷、透明、个性化以及社交化，开始深耕大健康领域，加快为客户打造全场景、全覆盖的保险服务生态圈。作为一家全球大型保险金融服务集团，打造“保险＋医疗养老”生态闭环，引领服务业和供给侧改革，助力民生发展，服务经济社会。伴随互联网、大数据，以及人工智能等技术的发展，新业务形态、新业务需求乃至新业务创新都对现有IT提出了新的挑战。 

这就带来了对IT基础设施的敏捷化需求，计算资源从物理机，到虚拟化，再到IaaS；新一代企业云建设的重点由IaaS来到了PaaS，作为云计算市场的制高点，成了众人追逐的对象。与已经趋向成熟的IaaS和SaaS相比，PaaS仍处于持续演进的过程中，从Openstack和VMware的产品技术动向来看，IaaS与PaaS正快速融合。如今，随着技术和社区的成熟，容器、Kubernetes、微服务等新事物不再只是概念，已在很多企业落地并发挥了生产力，对容器和PaaS的需求也从试探性转向规模化推广和纵深探索，建设企业级容器PaaS平台成为必然趋势。

背景

技术方面：

1.容器 - 量变引发质变，形成PaaS平台新契机

• 容器是2016年软件行业七大趋势之首

• 以Docker为代表的容器技术是一种

• 轻量级 “虚拟化”(隔离)技术

• 实现应用封装标准化，形成混合云部署标准

虚拟机 VS 容器

2.微服务架构引领企业软件架构的变革

• 微服务是一种将应用分割成一系列细粒度服务的应用架构模式

• 微服务与容器成就企业应用开发、部署和性能伸缩的敏捷，

• 围绕企业的业务的关联性拆分微服务，使IT敏捷带动业务敏捷

3.Kubernetes成为容器编排技术标准

• 为PaaS技术演进，PaaS与IaaS融合提供基础

• 云原生为企业生产环境运行容器应用而设计

企业方面：

企业业务应用系统分层

微服务和云原生对PaaS的需求越发强烈，必须要用全新的视角建设容器云PaaS平台；PaaS带来的不只是技术的变化，还有开发模式和运维模式的转变，以及IT资源生命周期的管理等。

容器云PaaS的建设目标

容器云PaaS平台是企业IT集中化建设的基础设施平台，目标一定是结合业务使用场景实际需求，而不是追求大而全，要杜绝技术上的投机主义，做到技术和成本的权衡；构建容器PaaS基础设施，；在容器云PaaS框架下，扩展提供软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、CI/CD、统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案，并配套建设DevOps工具链、微服务管理平台、IT运营/监控平台。

企业需要怎样的一个PaaS平台，首先要认识到云计算技术的复杂性，比如OpenStack，Kubernetes 和Ceph，代表了开源云技术领域的三个典型，企业想用好并不容易，其所涉及到技术栈几乎覆盖全部的计算领域知识，又处于数据中心的底座，牵一发而动全身，企业之大事，存亡之道，不可不察也。不可盲目得追求大而全得功能，花哨的功能，做加法容易，做减法难，PaaS建设的核心需求是数据中心技术底座，健壮、可运维性强、长生命周期支持是根本。

建设原则

技术先进性和成熟性

互联网和开源带来了新技术的迅猛发展，大厂积极参与社区，一定要立足高起点，积极吸收社区的养分，把握技术的方向，选择先进性和成熟度融合较好的技术，在保障平台稳定性的基础上，考虑到技术折旧，满足3-5年的技术需求即可。

开发性和标准化

平台总体设计上一定不能偏离业界标准和实践，充分利用开源社区，例如kubernetes为了保证社区不分裂，推出了一致性认证计划，产品要和主流的技术栈如DevOps工具链、CI/CD、微服务框架保持较好的兼容，松耦合+标准化，易于调整，可较好的适应企业现有技术栈和基础环境，可灵活组合，这样也可最大程度的利用已有技术，降低成本。

可靠性与安全性

安全和可靠是整个系统建设的基础，复杂的容器云PaaS平台更是如此，平台需提供良好的可靠性工具，可运维性强、可观测(监控)、可全方位容错、备份恢复与自诊断、良好的debug与故障诊断，确保系统数据的准确性、正确性。

合理的技术演进路线

考虑到容器云PaaS的技术成熟度，哪些应用要上容器云，数据库要不要上，现在不上何时上，上的话需要具备哪些条件，都需要有合理的规划，采取正确的实施策略，分为一期二期三期甚至更多来实现，正确准确得迈出第一步很关键。

风险与应对措施

1、 容器技术的弱隔离性

容器（container），并不是一种虚拟化（virtualization）技术，而是一种进程隔离（isolation）技术，从内核空间、资源和安全等方面对进程做隔离，其不具备和虚拟机以及沙盒（sanbox）一样的隔离能力，目前以kata为代表的轻量级vm容器技术还不能成为主流，目前只能选择Docker(Containerd)作为容器引擎，所以要从业务所使用的技术栈来考虑是否适合容器化，切忌一刀切。

2、 企业多租户隔离

多租户隔离在容器云PaaS主要分为考虑网络上的隔离性，主要分为弱隔离和强隔离。弱隔离的场景适合同一个组织多个租户使用同一个集群，能达到在逻辑上隔离的目的；强隔离的技术需求通过一个集群很难解决，最好采用多集群的方案，容器云在上层做统一纳管即可；

3、 配套的DevOps工具链和CI/CD流水线

容器的应用交付完全不同于vm时代，其模糊了开发和运维的边界，需要通过DevOps去解决，需要建设配套的工具链如Helm、Jenkins、统一镜像仓库、CMDB、代码托管仓库、Dockerfile编写等都需要去解决，涉及到的工具很多，配套跟不上，企业内部的采购流程一般又较长，善于利用开源工具去解决这个问题；

4、 应用的容器化改造

应用要上容器云PaaS，比如进行无状态化改造，日志的标准化输出、监控埋点、CI/CD自动化等；

产品/技术选型

我司从2016年还是对容器技术进行试验性研究，不像现在的Kubernetes一统江湖，当时的container领域docker一家独大，容器编排领域swarm、mesos、kubernetes上演三国演义，Mesos定位数据中心技术底座，天然吸引大型企业，kubernetes戴着谷歌的光环，swarm是Docker自家产品，各怀千秋；国内的容器技术创业公司也雨后春笋般出现，可见其火热程度，炙手可热。一圈下来，编排发现落地太难，不知道从何处下手，尚不敢做容器PaaS的假设。

就这样时间到了2017年，容器编排领域技术一下失去悬念，Kubernetes脱颖而出；上半年我们就迅速确定了kubernetes作为容器PaaS的技术核心，视线开始转向产品解决方案，建设目标也逐渐清晰起来；作为一个技术底座，容器PaaS的底层技术健壮性的重要不言而喻，虽然kubernetes已成编排领域事实标准，但kubernetes本身只专注于编排领域，其余的上下游技术栈都由社区提供，怎样良好的集成就成了摆在眼前的难题；经过研究和试用，我们最终把视角投向了Openshift，OpenShift是一个私有的基于Kubernetes的企业级PaaS（Platform-as-a-Service）解决方案，基于Docker和Kubernetes构建，具有Kubernetes的全部优点，又针对Kubernetes的弱项又做了多方面的功能补充，以满足企业在业务应用、开发及运维用户在生产效率上的诉求。

Openshift VS Kubernetes

OpenShift项目和Kubernetes项目的定位不同，属于不同层次的创新。

Kubernetes项目目的是为了提供一个通用的容器部署和编排平台，侧重于提供基础技术支持应用在容器集群环境中的快速部署和运行管理。

OpenShift项目的关注点在于为用户提供一个可用的基于容器的应用云平台的解决方案（Platform-as-a-Service）。这个方案包含具体的SDN、日志、储存、高可用、编程框架、UI、自动化等开箱即用的方案。

作为基础技术，Kubernetes提供尽可能广泛地支持各种技术和提供最大的可能性。

作为接近用户侧的解决方案， OpenShift倾向于从众多的可能性中实现某一种或多种具体的方案。

通过OpenShift，企业可以快速搭建稳定、安全、高效的容器应用平台。在这个平台上：

1、 可以构建企业内部的容器应用市场，为开发人员快速提供应用开发所依赖的中间件、数据库等服务。

2、 通过OpenShift，用户可以贯通从应用开发到测试，再到上线的全流程，开发、测试和运维等不同的角色可以在一个平台上进行协作，可以有效地帮助企业推进DevOps，提高资源利用率，提升生产效率。

3、 支持LDAP用户权限管理，支持细粒度的权限资源管理。

4、良好的开源社区支持。

5、 强大的厂商支持和长生命周期管理。

6、 支持软件自定义网络（SDN）。通过OpenVSwitch，为用户提供了灵活强健的软件定义网络。可实现跨主机共享网络及多租户隔离网络模式；此外，Openshift还支持与红帽认证过的第三方软件定义网络产品进行集成，例如：Cisco Contiv、Juniper Contrail、Nokia Nuage、Tigera Calico、VMware NSX-T。

7、 支持性能监控及日志管理。Openshift提供了开箱可用的性能监控及日志管理组件。能快速获取业务的运行状态指标，对业务日志进行收集及分析。

8、 支持多用户接口。可以通过友好的Web用户界面、命令行工具及RESTful API放访问和使用Openshfit提供的各项功能。

9、 支持自动化集群部署及管理。Openshift通过Ansible实现了集群的自动化部署，为集群的自动化扩容提供了接口。

架构方案

主机：

虚拟机方案：

双方各有千秋，虚拟机部署优点是灵活部署与配置，节点扩容方便，可借助已有IaaS层的能力。迁移灵活，虚拟机使用户能够使用image轻松地在主机之间移动工作负载，回滚方便。从平台健壮性上考虑，相当于上了2道保险：虚拟化层和paas层；缺点：多了一层虚拟化，从复杂度上讲，整体可靠性会下降；

裸金属方案：

高性能，无虚拟化层的性能开销，根据性能测试，在裸机上运行Kubernetes和容器，实现了显着降低的延迟 - 比在虚拟机上运行Kubernetes低大约3倍。社区和厂商也在探索Container-native Virtualization，比如kubevirt；从成本上看，虚拟化和容器都是弹性计算的方案，从license成本上考虑，作为用户没必要同时为2个技术买单，因为容器解决了问题。综合和长远上看，推荐私有云环境下直接上裸金属部署；(备注：本次主要讨论裸金属方案)

高可用：

对于openshift集群来说，有两种类型的高可用。一种是集群自身不同组件的高可用，另一种是运行在集群内部的应用的高可用。Openshift从设计之初就考虑了这两种不同类型的高可用。

对于集群组件高可用来说，openshift有多种类型的组件，包括master，etcd，node，router，registry等，每个组件都默认支持高可用的部署。Openshift的router组件可以通过oc scale命令随时进行扩展，最多可以达到集群node的数量。

对于运行在集群内部的应用来说，openshift可以将应用的多个实例分散在不同的物理拓扑的domain概念上，比如node，机架，机房等，这样尽可能的保证应用的实例不会再同一时间发生故障。Openshift可以提供对于应用实例运行情况的健康检查探针，当openshift发现某个实例异常时，它会在其他的node上重新启动一个新的实例来代替故障的实例，并保证集群内部的应用总实例数量和管理人员配置的是一致的。Openshift节点主要分为主控节点(Master)和受控节点(Node)，受控节点根据用途又分为基础节点(Infra)和计算节点(Compute)，Master * 3 + Infra *2 + Infra *n，具体角色

硬件配置配置示例(企业可根据自己情况进行定制)：

Master控制节点 *3

Infra-node节点 *2

Compute-node节点 *n

部署架构图

网络架构图

网络

Openshift使用软件定义网络（SDN）提供集群内部统一的网络环境，可以使集群内部不同节点之间的Pod进行通讯。Openshift的SDN框架是非常灵活的，可以通过配置切换不同的SDN实现。当前版本的Openshift使用的是基于Open vSwitch的VXLAN方案。该方案为用户提供了两种不同类型的选择，ovs-subnet可以提供一个整体连通的平面网络，所有集群中的Pod默认都是可以直接通讯的;ovs-multitenant 提供了Project相互隔离的方式，每个Project有一个独特的 Virtual Network ID（VNID），Project内部的资源可以互通，但是不同Project之间的Pods和服务是无法相互访问的。管理人员可以手动的打通Project之间的网络，使其可以相互访问。此方案对企业既有网络无侵入性，可快速部署；

多租户支持：

每个用户项目分配一个惟一的虚拟网络ID (VNID)

• 防止交叉项目沟通；

• 项目VNIDs可以合并以允许通信；

• VNID 0预留给管理服务，不受限制；

节点内的SDN 流量

存储

持久化存储分为平台内置组件的持久化存储和应用的持久化存储。

平台的持久化存储可根据企业已有的存储平台确定，openshift本身支持NFS、GlusterFS、Cinder、Ceph等存储。

应用系统需要使用持久化数据的，优先建议使用对象存储，其次是使用nas。

监控和日志

推荐和企业已有的统一监控和日志平台。

监控推荐直接使用内置的Prometheus，可定制多层次丰富的告警策略，node节点的基础监控可使用zabbix之类的工具作为平台带外监控工具补充，除此还需重点关注OCP内部基础组件的监控，如etcd、ovs-sdn、router等监控，另外还要增加syslog关键字监控用来探查平台整体的监控状况，提前处理。

平台调度

Openshift从API Server接收到创建Pod的请求以后，会为其安排一个可以运行的节点。在调度的过程中首先会选取所有满足Pod要求的节点，然后根据不同的算法为所有的节点进行打分，最后将Pod调度到合适的节点上。结合Node labels和NodeSelector的使用，可以实现复杂的pod调度策略。管理员可以为基础设施打上多级标签（比如region=r1, zone=z1, rack=s1），部署应用时可以通过Label指定该应用需要运行的基础设施。部署人员可以指定Pod之间的亲和关系（Affinity），将互相访问频繁的Pod同时部署在网络距离短的节点上（比如同一个节点、机架）。也可以指定服务的反亲和属性，使同一个服务的多个Pod尽可能的在集群上分散部署（不同的节点、机架、机房），这样也就提高了服务的高可用性。

权限和多租户管理

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

1. 权限控制

2. 网络隔离

3. Router隔离

4. 物理资源池隔离

5. 对接外部LDAP，可实现细粒度的权限控制；

6. 根据要求定制个性化scc角色；

负载均衡

router本身可做平台层内部的多层次的7层控制，外部还需增加一个负载均衡层，对接企业已有的F5、LVS、Nginx等负载均衡设备，建议新增一层7层控制，分为内网负载均衡器和外网负载均衡器。

https证书也置于这一层，这样router直接启用http的80服务即可。

团队组织架构

应用系统上云方案

上容器云流程

开发测试环境流程

生产环境流程

应用上容器云评估(架构梳理)

1. 了解目前项目的架构，确定哪些组件采用容器化方案

2. 目前数据库采用传统架构，部署到物理机或虚机

3. 微服务架构，单体应用

4. 主流微服务框架(SpringCloud、dubbo)的kubernetes方案；

混合云下的交付

Jenkins + Helm，这里不做展开

应用容器化改造过程中应注意的几个问题

应用的无状态化，日志输出

1、jdk版本是否要升级

参考：https://developers.redhat.com/blog/2017/04/04/openjdk-and-containers/#more-433899

java开发时企业应用的主力，相信java类开发上容器云是第一要务，jdk11提供原生容器(containerd)支持，另外Java 8u131及以上版本开始支持了Docker的cpu和memory限制。如果应用不能升级jdk11，那就升级到Java 8u131。

cpu limit

即如果没有显式指定-XX:ParalllelGCThreads 或者 -XX:CICompilerCount, 那么JVM使用docker的cpu限制。如果docker有指定cpu limit，jvm参数也有指定-XX:ParalllelGCThreads 或者 -XX:CICompilerCount，那么以指定的参数为准。

memory limit

在java8u131+及java9，需要加上-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap才能使得Xmx感知docker的memory limit。

2、Debug工具：

不建议将基础镜像搞大，添加过多的dubug工具，BusyBox 是一个集成了三百多个最常用Linux命令和工具的软件。BusyBox 包含了一些简单的工具，例如ls、cat和echo等等，还包含了一些更大、更复杂的工具，例grep、find、mount以及telnet。有些人将 BusyBox 称为 Linux 工具里的瑞士军刀。简单的说BusyBox就好像是个大工具箱，它集成压缩了 Linux 的许多工具和命令，也包含了 Android 系统的自带的shell。

平台运维过程的几点问题

1、 一次Node节点hang死的处理记录

查看系统syslog发现一下关键日志：

rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "open /proc/self/task/124250/attr/exec: too many open files in system"

更改文件数解决

2、 扩容计算节点，新节点的pod报”dial tcp:lookup …no such host”错误

经查，是新增节点的dnsmasq信息未同步到其他节点上，需重启其他节点的dnsmsq服务；

3、 扩容新节点后，新节点报错；

atomic-openshift-node[2588]: E0701 19:02:26.547994    2588 summary.go:102] Failed to get system container stats for "/system.slice/atomic-openshift-node.service": failed to get cgroup stats for "/system.slice/atomic-openshift-node.service": failed to get container info for "/system.slice/atomic-openshift-node.service": unknown container "/system.slice/atomic-openshift-node.service"

经查此为openshift的一个bug,参考

https://bugzilla.redhat.com/show_bug.cgi?id=1623261

https://github.com/openshift/origin/pull/21138

涉及到的文件（cat /etc/systemd/system.conf.d/origin-accounting.conf）修改如下，

[Manager]

DefaultCPUAccounting=yes

DefaultMemoryAccounting=yes

# systemd v230 or newer

#DefaultIOAccounting=yes

# Deprecated, remove in future

DefaultBlockIOAccounting=yes

最后，需重启主机；

4、 平台升级

应用迁移的一些脚本：

# 1.全量导出项目

## 切换project

oc project <projectName>

# 新建$projectName

mkdir <projectName-export>

# 导出配置

for object in ingress route configmap service  rolebindings serviceaccounts secrets imagestreamtags podpreset cms egressnetworkpolicies rolebindingrestrictions limitranges resourcequotas pvcs templates cronjobs statefulsets hpas deployments replicasets poddisruptionbudget endpoints dc role

do

  oc get -o yaml --export $object > $object.yaml

done

## 2.复制到新系群环境下

scp ...

## 3.导入新集群

# 切换project

oc project <projectName>

# 导入配置

for object in ingress route configmap service  rolebindings serviceaccounts secrets imagestreamtags podpreset cms egressnetworkpolicies rolebindingrestrictions limitranges resourcequotas pvcs templates cronjobs statefulsets hpas deployments replicasets poddisruptionbudget endpoints dc role

do

  oc create -f $object.yaml

done

总结

企业要想落地容器云平台，人是第一位的，需要数据中心团队、架构团队、开发团队及项目管理团队的密切配合，容器云PaaS自2018年初正式上线，数据中心的运维交付模式发生了变化，逐渐向服务中心和价值中心转变，在计算资源利用率上得到了显著提升，经评估，开发资源池的资源利用率相比虚拟化提升5倍以上；部署上通过helm+Jenkins的交付真正可以做到了一键式交付，GitOps威力逐渐显现；k8s+springboot对微服务的支持可以直接替换负载的springcloud架构，微服务治理的压力得到了极大释放。

上云一时爽，一直上云一直爽。