作者：梁德汉、熊国章、唐新华、段苏隆、江庆坤、陈光辉、徐凯 / 安信证券股份有限公司

　　容器云平台是近几年受到各行业广泛追捧的技术平台之一，是以容器和 kubernetes 编排为底座的新型 PaaS 平台，打造这样的平台会面临不少的挑战，本文描述了安信证 券容器云平台的落地实践，包括平台架构设计、技术选型、安全防护、运维测试、上云推 广和建设成果，最后展望平台的发展方向。希望能够给建设中的读者有所启发，共同探索 云原生容器领域的最佳实践。

　　随着虚拟化技术的发展，我司已完成计算资 源虚拟化的建设进程。虚拟化技术一定程度上降 低了运维复杂性，提升了资源的利用率。但业务 系统的上线仍面临如下问题 ：

　　应用系统的规模越来越大，复杂的架构使 得应用的安装、部署和更新也比较复杂，业务停 机时间和部署成本都有所增加。已有新应用系统 开始尝试容器化的形式解决此类问题 ；

　　在面对互联网金融等行业的激烈竞争时， 业务部门的需求变化越发频繁，同时也希望 IT 部门缩短软件的交付周期 ；

　　以 VMWare 为代表的虚拟化技术，同样面 临硬件利用率相对较低、资源分配调度相对缓慢 等问题。

　　随着金融科技概念的兴起，IT 部门需要更 好的提升研发和运维团队的生产力，从而更加灵 活、高效、快速的满足业务系统需求，更好提升 业务价值。容器技术的出现，在开发和运维之间 搭建了一个桥梁，是实现 DevOps 的最佳解决方 案。容器云平台以容器技术为基础，支持容器化 应用系统运行的基础平台，以降低应用软件基础 环境的复杂度，将提供容器化应用全生命周期管 理，实现应用的自动伸缩、弹性扩展、灰度发布 以及监控告警、自动迁移、故障自愈等功能 ；同时通过动态调度容器服务的运行，尽可能地共享 或平摊资源，能大幅提高基础资源的利用率，从 而降低基础设施的投入，节约成本。

　　在金融行业，监管部门对于以云计算为代表 的创新技术，一直秉持开放态度。推动“上云” 的政策趋向，多年来，国家高度重视新一代信息 产业的发展。国务院发布《关于促进云计算创新 发展培育信息产业新业态的意见》，工信部制订 云计算“十三五”规划，科技部部署国家重点研 发计划“云计算与大数据”重点专项等，为云计 算的发展提供顶层设计。 我司以全面上云为战 略目标，“安信 IT 会坚定不移走平台化建设道路， 容器 + 服务化 +DevOps 是技术中台建设的重要组 成部分，也是我们团队明确的技术发展路线 容器的优势

　　：容器的本质是一个独立 的进程，不需要进行硬件虚拟以及运行完整操作 系统等额外开销，容器对系统资源的利用率更高。 无论是应用执行速度、内存损耗或者文件存储速 度，都要比传统虚拟机技术更高效。因此，在单 机环境下与 KVM 之类的虚拟化方案相比，能够 运行更多数量的实例，而且多个容器互不影响， 彼此独立。

　　：传统的虚拟化技术启动 系统和应用需要分钟级，容器应用共享宿主内核， 无需启动完整的操作系统，因此可以做到秒级、 甚至毫秒级的启动时间，大大节约了开发、测试、 部署的时间。

　　：开发过程中一个常见的问 题是环境一致性问题，常常表现为动态库、JDK、 依赖等版本的差异。容器以标准的方式，使用镜 像提供了除内核外完整的运行时环境，确保了应 用运行环境一致性。容器可以跨平台运行，无论 是物理机、虚拟机，其运行结果是一致。

　　：在业务高峰时刻，容器 可以根据 CPU、内存、甚至业务指标进行快速扩 容，提升服务能力。在业务低谷期，可以稳步降 低副本数量，节约资源。

　　容器提供了一种沙盒的机制，对不同应用能 够进行有效隔离。镜像是它出彩的一个设计，可 以让开发者们快速部署应用。但这对大型应用管 理来说，这是远远不够的，随着容器的大规模使 用，容器编排显得异常重要。在云原生大行其道 的今天，kubernetes 对容器的编排已经成为一种 事实标准，也有人称是下一代的操作系统。

　　云原生技术有利于各组织在公有云、私有云 和混合云等新型动态环境中，构建和运行可弹性 扩展的应用。云原生的代表技术包括容器、服务 网格、微服务、不可变基础设施和声明式 API。

　　实际上，我们可以理解云原生其实是一套指 导进行软件架构设计的思想，为用户指引了一条 可靠的、敏捷的、能够以可扩展、可复制的方式 最大化地利用云的能力、发挥云的价值的最佳路 径。

　　容器云平台是一种使用容器去构建、部署和 编排应用的新型 PaaS 平台，以 Docker 作为容器 运行时在 Linux 环境中创建容器，以 Kubernetes 为容器编排引擎在平台中编排容器。各家的容器 平台架构大体应该都差不多，我司容器云平台在 测试、办公、交易等不同安全域分别部署了集群， 使用 Rancher 对多套集群进行统一管理。在集群 入口，我们使用 F5 进行负载。

　　：以 kubernetes 为 核 心 组 件 的 PaaS 平台，整合 EFK，Prometheus，Harbor 等附加 组件，PaaS 服务分为三个平面，分别为管理平面、 控制平面、计算平面。

　　：建设开发、构建、测试、运行流水线，实现应用从构建到发布的全自动化 的过程。

　　：智能化的资源调动与分配， 通过日志分析，监控指标分析，负载流量等自动 弹性伸缩，减轻运维负担。

　　镜像仓库是容器云平台的建设必不可少的部 分，随着我司的应用上云进程不断深入，应用镜 像制品的安全性、可靠性以及易用性等问题也日 益凸显。我们在建设早期阶段也尝试过其他镜像 仓库产品，比如原生的 registry、nexus，但无论 是可靠性还是权限管理都无法满足我司的需求， 最终我们采用 Harbor 来建设我们的私有镜像仓 库。

　　镜像仓库独立于容器云 Kubernetes 集群之 外部署，双机部署保障高可用

　　分建开发 / 测试，交易生产不同的环境， 开发测试镜像仓库允许应用负责人随时构建上传 镜像制品 ；而对于交易生产镜像仓库，为了保证 镜像来源的安全、可控，我们限制了只能从测试 镜像同步（同步方式是 pull-based）

　　生产镜像仓库只同步正式版本的镜像，应 用发布需申请变更窗口，从生产镜像库中拉取镜 像进行部署

　　网络是 Kubernetes 非常关键的组成部分，默 认的要求是每个 Node（宿主机）之间的容器网 络能够联通，设计的一个基础原则是每个 Pod 都 拥有一个独立的 IP 地址，而且假定所有 Pod 都 在一个可以直接连通、扁平的网络空间中。所以 不管它们是否允许在同一个 Node 中，都要求它 可以直接通过对方的 IP 进行访问。但其本身并 不提供网络解决方案，而是提供 CNI 规范给许多 插件例如 Flannel、Calico、Weave 等实现，在集 群上使用和部署以提供默认网络解决方案。

　　在金融行业，监管和安全要求更为严格，业 务之间跨区访问需要在防火墙中开启白名单规 则。kubernetes 提供了 Network Policy 方案，SDN 技术虽然可以使用标签选择器的方式控制应用之 间的流量以及来自外部的流量，但是在我们建 设初期，该项技术并未很成熟，技术上的创新 更需要很长时间的论证，因此我们选择了“传 统”的网络隔离方式，对 Pod 进行 IP“固定”。 网络功能需要使用多个网络接口分离控制，管 理和控制用户 / 数据的网络平面。为了解决这些 需求，Intel 实现了基于 CNI 的网络插件 Multus， 它能支持同时添加多个网卡到 kubernetes 环境 中。方便用户把管理网络和业务相互隔离。 MacVLAN+Canal 便是基于 Multus 的实现，在 Pod 中拥有两块网卡，其中一块网卡可以用于管理网 络，底层使用 Canal 网络模式，另外一块网卡做为业务网络，底层使用 MacVLAN 模式。为保障 网络的健壮性，要求管理网和业务网使用两块网 卡做好 bond 并接入不同的交换机上。

　　Canal 网络 ：主机和主机间通过 Canal 网 络插件建立的 vxlan 网络进行通信，主要用于应 用之间管理流量。

　　MacVLAN 网络 ：实现各个业务固定在一 段 IP 范围内自动分配 IP 和 MAC 地址需求，流 量不封装直接可以经过二层交换机进行转发。在 我司的环境中，底层的物理机上分为两块网卡并 做好 bond，其中网卡 1 做为管理网络流量，网卡 2 做为 MacVLAN 业务流量，网卡 2 交换机端口 配置为 trunk 模式，并允许对应的 vlan-tag 通过。

　　默认网络 ：默认只有 Canal 网络，当启用 MacVLAN 时，Pod 默认网络为 MacVLAN 网络。 此时，Pod 默认网络与主机网络在同一扁平网络 空间。

　　存储的核心需求是可靠、可用，应用对存储 的要求是稳定、高性能，企业考虑的则是可扩展 和低成本。通常我们会通过模拟各种组件异常， 比如拔网线、磁盘、节点电源等方式来衡量存储 的核可靠性 ；模拟长时间使用的边界情况，满足 的性能指标，容量使用超过 90% 下的性能和稳 定性。相对传统的集中式存储，分布式存储拥有 更好的可扩展性和低成本优势，前者则拥有更高 的性能。

　　可靠性 ：可靠性是指存储不丢失数据的概 率，一般情况需要满足最大的故障节点数、最大 故障盘的提前。评估方式是直接拔盘，比如说存 储提供 3 副本策略，拔任意 2 块磁盘，只要数据 不损坏，则说明该产品是可靠的。存储采用不同 的冗余策略，提供的数据可靠性也不一样。

　　可用性 ：可用性和可靠性经常被混淆，可 用性是指存储是否提供 HA（High availability）和 写保护机制。在抖动的异常场景，是否能够满足 应用的持续访问。在机房异常断电的情况，是否 能够在集群恢复正常后，数据可以正常访问。评 估的方式是拔服务器电源和网线，检查是否存在 单点故障或者数据不一致。

　　存储性能：评估一个存储产品的性能主要是三大指标 ：IOPS、时延 (latency) 和带宽 (bandwidth)。性能测试需要一个基准，首先需要 正确地描述需求，之后选择合适的工具进行持续 的运行，收集数据，分析结果数据。fio 是常用的 基准测试工具。通常我们会使用随机读写 ( rand read / write ) 测试 IOPS 和时延，使用顺序读写测 试带宽。分析结果数据最好的方式是使用绘图工 具如 gnuplot 来进行。

　　管理日志相对比较好处理，我们 Kubernetes 各个组件都是容器化部署，其他的管理日志也都 有固定的输出位置，配置好规则一一收集即可。

　　而应用日志，在弹性伸缩、快速故障恢复和 迁移、大规模微服务化部署等场景下，应用容器 实例会扩展到集群中的各个节点上，应用生成的 日志随之分散存放到各容器所在的主机上，这给 整个应用系统的日志监控和故障排查带来极大的 挑战。和很多传统的大型应用将日志持久化在本 地不同，容器应用需要考虑将分散在多个容器中 的日志统一收集，再汇集到外部的集中日志管理中心，以满足对应用日志的管理需求。因此我们 与应用方同事沟通制定了相应的日志输出规范 ：

　　1. 日志输出到标准输入输出接口，一部分 应用进行了改造，将日志输出到标准的输入输出 接口

　　2. 日志写入到日志文件，部分没有经过改 造的应用将日志直接写入到指定日志文件中

　　我们容器云平台使用 Fluentd 作为容器日志 收集组件，Fluentd 使用 Ruby 语言开发的，也是 CNCF 基金会官方项目之一。Fluentd 的整体处 理过程如下，通过 Input 插件获取数据，并通过 Engine 进行数据的过滤、解析、格式化和缓存， 最后通过 Output 插件将数据输出给特定的终端。

　　4. 告警通过邮件、短信发送通知，使用 webhook 对接公司的统一告警平台。

　　组织方面 ：安全团队为项目设计、建设成 员之一，运营、管理成员之一，保障顺畅的信息 传递和协作。

　　流程方面 ：在多个流程节点中加入了安全 控制措施，确保安全措施能有效执行。

　　工具方面 ：建立容器安全管理系统，实时 对容器安全状态检查。最终各部分联动形成闭环 的安全保障措施，更好的支撑容器平台稳定、安 全的运行。

　　在上线部署运行之后，安信容器云团队对容 器云平台进行了测试，并得出了最新的测试成果 《安信证券容器云平台系统测试报告》，对容器云 平台系统进行功能测试和性能测试验证。

　　测试场景通过 3 台 master 的高可用，10 台node 的计算节点，环境如下 ：

　　按照非功能性需求制定测试指标，为测试结 果是否通过提供参考依据。测试结果部分指标如 表 2。

　　容器云平台本身是一个技术产品，如果它无 法承载、赋能业务，那则没有存在的价值。因此， 在技术平台竣工前期，需要和各业务系统紧密合 作，提供良好的客户支持，配合业务系统平滑迁 移到容器云平台。为更好的完成协同，对此，我 们提出了以下要求 ：

　　在梳理好上云要求后，我们大致圈定了上 云的系统范围。截至目前为止，我司已完成了支付中心系统、投资秀、互联网运营平台、条件选 股、资管网站、投行存续期管理系统等 20 多套 生产应用上云 ；计划 2021 年完成全部自研类系 统上云。

　　在增效降本方面，与虚拟化相比，资源利用 率提升是容器技术的关键优势。kubernetes 对底 层的抽象屏蔽了基础设施的复杂度，将整个平台 的资源进行池化，带来相当直接的好处。安信容 器云开发测试集群资源利用率提升尤为明显，与 虚拟化相比，CPU、内存分别只占 22% 和 38%， 并随着应用项目的增多，资源利用率还会继续提 升。同时，应用资源的交付耗时将降低到分钟级 别，资源申请只需简单的 quota 分配即可，替代 传统的虚拟化安装操作系统、配置 IP 等复杂的 操作，用户获取资源的成本大大降低。此外，得 益于镜像打包技术，应用部署时无需再次配置依 赖环境、组件，部署效率也会大幅提高，由之前 的数天降低到分钟级别。

　　全面上云 ：我司云计算建设已经过基础设 施上云，应用上云阶段。在万物上云，全面信息化的数字化时代，下一步我们会坚定不移的坚持 全面上云，上下衔接形成有机整体，夯实数字化 和智能化能力，打造云上大数据、云上中台，为 我司全面数字化转型继续赋能。

　　基于容器云 PaaS 中间件建设 ：PaaS 中 间件作为一个公共的统一服务，不仅可以开箱即 用，还能按需变配，有效提高我公司的资源利用 率和降低成本。基于容器云的 PaaS 服务能够让 业务系统无需购买业务系统专用的硬件服务器来 部署中间件服务，在平台申请即用，统一运维保 障服务的高可用。在业务初期，可以申请小规格实例来应对业务压力，随着服务压力和数据量增 加，可以平滑升级实例规格，当业务回到低峰时， 可以降级实例规格，节约成本。

　　两地三中心 ：以同城双中心、异地灾备中 心的方案兼具高可用和灾难备份能力，我司科 技园机房在去年年底已逐步投入使用，基于容 器云平台的两地三中心基础设施建设亦提上了 日程。从应用视角出发，两地三中心的建设并 不局限于多数据中心多集群，只有从整体上解 决应用双活问题，才能更好的落地两地三中心 目标。