安信证券容器云平台落地实践


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

建设背景

随着虚拟化技术的发展,我司已完成计算资源虚拟化的建设进程。虚拟化技术一定程度上降低了运维复杂性,提升了资源的利用率。但业务系统的上线仍面临如下问题:
  • 应用系统使用的基础软件一般功能繁多、架构复杂,部署维护门槛较高;
  • 应用系统的规模越来越大,复杂的架构使得应用的安装、部署和更新也比较复杂,业务停机时间和部署成本都有所增加。已有新应用系统开始尝试容器化的形式解决此类问题;
  • 在面对互联网金融等行业的激烈竞争时,业务部门的需求变化越发频繁,同时也希望IT部门缩短软件的交付周期;
  • 以VMWare为代表的虚拟化技术,同样面临硬件利用率相对较低、资源分配调度相对缓慢等问题。


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

驱动力

全面上云

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

容器的优势

安信最初使用Docker的历史是部分的应用使用容器的方式替换传统的VM部署,典型的代表系统有用户中心和安信官网,从试点的业务系统中我们尝试到了使用容器的好处:
  • 更高的资源利用:容器的本质是一个独立的进程,不需要进行硬件虚拟以及运行完整操作系统等额外开销,容器对系统资源的利用率更高。无论是应用执行速度、内存损耗或者文件存储速度,都要比传统虚拟机技术更高效。因此,在单机环境下与KVM之类的虚拟化方案相比,能够运行更多数量的实例,而且多个容器互不影响,彼此独立。
  • 更快的启动部署:传统的虚拟化技术启动系统和应用需要分钟级,容器应用共享宿主内核,无需启动完整的操作系统,因此可以做到秒级、甚至毫秒级的启动时间,大大节约了开发、测试、部署的时间。
  • 更一致的运行:开发过程中一个常见的问题是环境一致性问题,常常表现为动态库、JDK、依赖等版本的差异。容器以标准的方式,使用镜像提供了除内核外完整的运行时环境,确保了应用运行环境一致性。容器可以跨平台运行,无论是物理机、虚拟机,其运行结果是一致。
  • 更快的弹性伸缩:在业务高峰时刻,容器可以根据CPU、内存、甚至业务指标进行快速扩容,提升服务能力。在业务低谷期,可以稳步降低副本数量,节约资源。


云原生基石

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

首先我们说明一下什么是云原生?CNCF官方定义:


云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
实际上,我们可以理解云原生其实是一套指导进行软件架构设计的思想,为用户指引了一条可靠的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。

而Kubernetes在这套设计思想所处的位置,实际上是承上启下。Kubernetes对上暴露基础设施能力的格式化数据抽象,例如Service、Ingress、Pod、Deployment,这些都是Kubernetes本身原生API给用户暴露出来的能力;而对下,Kubernetes提供的是基础设施能力接入的标准接口,比如说CNI、CSI、DevicePlugin、CRD,让基础设施能够作为一个能力提供商,以一个标准化的方式把能力接入到Kubernetes的体系中。

建设方案

总体架构

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

  • 分层架构:以kubernetes为核心组件的PaaS平台,整合EFK,Prometheus,Harbor等附加组件,PaaS服务分为三个平面,分别为管理平面、控制平面、计算平面。
  • 以应用为中心:建设开发、构建、测试、运行流水线,实现应用从构建到发布的全自动化的过程。
  • 自动化运维:智能化的资源调动与分配,通过日志分析,监控指标分析,负载流量等自动弹性伸缩,减轻运维负担。


技术选型

镜像仓库

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

镜像仓库的架构逻辑大体如下:
  • 镜像仓库独立于容器云Kubernetes集群之外部署,双机部署保障高可用
  • 分建开发/测试,交易生产不同的环境,开发测试镜像仓库允许应用负责人随时构建上传镜像制品;而对于交易生产镜像仓库,为了保证镜像来源的安全、可控,我们限制了只能从测试镜像同步(同步方式是pull-based)
  • 生产镜像仓库只同步正式版本的镜像,应用发布需申请变更窗口,从生产镜像库中拉取镜像进行部署
  • 制定策略,容器云平台发布应用的镜像来源只能是我们的私有镜像仓库


2.png

对于镜像仓库的租户权限管理,我们也定制了具体的规则:
  • 定制基础镜像、公共组件镜像,开放给所有业务系统
  • 不同租户(项目)的镜像相互隔离
  • 租户管理员拥有对应项目的全权限(读写),租户管理员下设普通用户,如开发者账号、机器人账号等等分别对应不同的使用场景;
  • 镜像仓提供镜像的查询、更新和删除等功能


3.png

网络方案

网络是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并接入不同的交换机上。

下面是Multus实现的MacVLAN+Canal方案。
4.png

  • 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来进行。


可以选择一组高性能的磁盘如SSD性能数据作为对比基准:
5.png

某存储产品在4k随机写下的时延性能:
6.png

当然,不是说性能相比高性能的数据差太多就无法满足业务的需求,在满足业务使用的情况下,了解与基准的差距更能准确知道存储产品的真实水平。

日志管理方案

我们对容器云平台的日志做了主要两个分类:
  • 管理日志:Kubernetes各个组件的日志、Kubernetes集群节点操作系统日志、容器引擎日志、容器云平台管理/审计日志
  • 应用日志:容器中的业务应用对在进行业务处理过程中的关键结果、状态所进行的记录


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

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


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

因为我司已有建成的统一日志分析平台,因此我们容器云平台不再建设独立的日志平台,只需规范应用日志及收集对接即可。

对于整体的日志方案的基本要求如下:
8.png

针对输出到标准输出接口的容器应用日志,在Docker中标准输出接口日志会默认以json的方式存放在/var/lib/docker/containers/目录,fluentd会自动去读取该目录下的json日志发送到fluentd中。针对容器内对应文件日志,容器云平台上配置workload对应的日志目录,容器云平台会使用Flexvolume驱动程序来创建卷并将日志挂载到主机/var/lib/logging/log-volumes目录,使用fluentd-tail插件自动去读取该目录下的日志发送到Fluentd中。
9.png

监控告警

作为继Kubernetes之后CNCF的第二个托管项目,我们同样使用Prometheus作为容器云平台监控建设的核心组件,对整个容器云平台进行多角度的监控。我们主要关心的核心监控维度有:
  • 核心组件:etcd、api-server、controller-manager、scheduler、kubelet等。
  • 静态资源对象:节点的资源状态、内核事件等。
  • 动态资源对象:Kubernetes中的workload,如Deployment、DaemonSet、Pod等。
  • 应用监控:workload需自定义的监控指标。


整体的监控建设体系如下:
  1. Prometheus抓取到的监控数据本地使用PVC进行持久化,同时转存InfluxDB保存180天。
  2. 对接保存数据到远程ElasticSearch,以满足统一监控要求。
  3. 自定义Grafana Dashboard满足日常工作需求。
  4. 告警通过邮件、短信发送通知,使用webhook对接公司的统一告警平台。


10.png

容器安全

容器安全是一件复杂又重要的工作,我们联合安全团队基于容器云业务生命周期,从攻防两个视角,配合事件、风险两种驱动力,在各阶段制定了一系列的安全保障措施,包含组织、规范、流程、工具四大部分。
  • 组织方面:安全团队为项目设计、建设成员之一,运营、管理成员之一,保障顺畅的信息传递和协作。
  • 规范方面:共同制定了容器管理规范,将安全相关要求融入规范中。
  • 流程方面:在多个流程节点中加入了安全控制措施,确保安全措施能有效执行。
  • 工具方面:建立容器安全管理系统,实时对容器安全状态检查。最终各部分联动形成闭环的安全保障措施,更好的支撑容器平台稳定、安全的运行。


上云推广

容器云平台本身是一个技术产品,如果它无法承载、赋能业务,那则没有存在的价值。因此,在技术平台竣工前期,需要和各业务系统紧密合作,提供良好的客户支持,配合业务系统平滑迁移到容器云平台。为更好的完成协同,对此,我们提出了以下要求:
  • 业务要求:业务是否适合容器化,将直接影响应用能否成功迁移到容器云平台,在建设初期,综合各因素考虑,我们采取了严格的上云条件再逐步放宽策略。
  • 技能要求:业务团队应当具备镜像制作、部署等基本能力;同时我们内部也开展培训,输出上云指南等来协助业务团队进行业务上云。


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

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

未来展望

  • 全面上云:我司云计算建设已经过基础设施上云,应用上云阶段。在万物上云,全面信息化的数字化时代,下一步我们会坚定不移的坚持全面上云,上下衔接形成有机整体,夯实数字化和智能化能力,打造云上大数据、云上中台,为我司全面数字化转型继续赋能。
  • 基于容器云PaaS中间件建设:PaaS中间件作为一个公共的统一服务,不仅可以开箱即用,还能按需变配,有效提高我公司的资源利用率和降低成本。基于容器云的PaaS服务能够让业务系统无需购买业务系统专用的硬件服务器来部署中间件服务,在平台申请即用,统一运维保障服务的高可用。在业务初期,可以申请小规格实例来应对业务压力,随着服务压力和数据量增加,可以平滑升级实例规格,当业务回到低峰时,可以降级实例规格,节约成本。
  • 两地三中心:以同城双中心、异地灾备中心的方案兼具高可用和灾难备份能力,我司科技园机房在去年年底已逐步投入使用,基于容器云平台的两地三中心基础设施建设亦提上了日程。从应用视角出发,两地三中心的建设并不局限于多数据中心多集群,只有从整体上解决应用双活问题,才能更好的落地两地三中心目标。


原文链接:https://mp.weixin.qq.com/s/WXXsmHVd6c3Pw5ORKMUcPQ

0 个评论

要回复文章请先登录注册