金融行业容器平台建设方案.docx

金融行业容器平台建设方案 【导读】数字经济时代金融行业面临数字化转型挑战，利用容器云原生技术作为支撑数字经济的数字底座，与公有云云原生采用相同的技术和架构，统一的生态体系，在保障金融机构数据权益和行业监管的同时，能够快速获取大数据、人工智能、数据库等新型云服务能力，满足“安全可靠+应用创新”双重诉求，以快速应对市场变化。本文是2021容器云职业技能大赛团队赛的亚军作品。目录1. 背景概述2. 现状及分析2.1 IT 研发转型2.2 IT架构转型2.3 IT 运维转型2.4 IT 组织转型3. 建设方案3.1 容器平台建设3.1.1 容器可编排性3.1.2 容器平台可扩展性3.1.3 安全合规性对接3.2 统一知识库3.2.1 建设目标3.2.2 建设方案3.2.3 知识分类3.3 统一制品发布3.3.1 方案架构3.3.2 代码版本管理3.3.3 自动化测试3.3.4 打包构建3.3.5 运行环境3.3.6 持续部署3.3.7 制品交付3.3.8 合规性检查3.4 统一资源申请平台3.4.1 自助资源申请服务3.4.2 在线审批流程3.4.3 自动化部署3.4.4 自助运维3.4.5 自助监控告警3.4.6 租期回收3.5 容器统一规范3.5.1 容器内应用的健康检测3.5.2 应用容器的DNS配置3.5.3 应用容器的应用配置管理3.5.4 应用容器的日志配置3.5.5 集群资源管理规范3.5.6 投产审核3.5.7 自动化运维3.6 高可用架构体系3.6.1 方案概述3.6.2 高可用部署方案3.6.3 总体设计3.6.4 灾备实现4. 方案价值4.1 IT交付新能力4.2 IT架构新能力4.3 IT运维新能力1 背景概述“十四五”期间的核心任务之一是科技创新，科技创新是引领发展的第一动力，是推动高质量发展、建设现代化经济体系的战略支撑。传统企业在今天都面临着新兴业务模式的剧烈冲击， 同质化的竞争手段已无法让企业在愈演愈烈的竞争中脱颖而出，包括银行、证券、保险以及政府金融机构在内的传统企业，纷纷致力于数字化转型。在数字经济时代，以大数据、人工智能、数据库为支撑的数字高速路，成为数字世界的基础。且科技创新需要建立在数字化转型成功的基石和底座之上。数字经济时代金融行业面临数字化转型挑战， 利用容器云原生技术作为支撑数字经济的数字底座， 与公有云云原生采用相同的技术和架构， 统一的生态体系，在保障金融机构数据权益和行业监管的同时，能够快速获取大数据、人工智能、数据库等新型云服务能力，满足“安全可靠+应用创新”双重诉求，以快速应对市场变化。可以利用容器云原生上的数据治理能力，实现数据统一管理，挖掘数据价值；可以利用容器云原生上的人工智能开发平台和开发框架，持续积累训练数据、算法模型和知识图谱，储备人才，探索前沿科技；可以利用容器云原生上的应用管理、微服务和 DevOps 技术，落地人工智能、金融级的应用，并且能够提升开发生产效率。倡导各金融机构结合自身实际情况，积极推进混合云的部署和建设，引入业界先进的云服务，支撑金融机构基于容器云原生灵活创新。2. 现状及分析银行的业务应用目前以多种形态运行在不同的技术栈上， 包括互联网技术栈和商业技术栈。大多数系统已经完成新一代的升级，但是随着容器的发展很多银行开始试水分布式架构体系改造。由于银行交易往往比较重要，有哪些系统最适合云原生容器化改造，应用在进行改造后如何符合银行现有规范等问题也显露出来。1.对容器技术没接触或接触少的研发部门会面临新技术的学习成本高， 改造难度大等问题；2.互联网技术栈产品直接进入不符合银行的高可用及安全要求等；3.容器改造期间可能涉及到除容器以外的其他平台或云产品；4.开发测试环节中生成的制品、编排文件需要经过安全审核再投产；5.测试资源申请面临不同云平台产品的统一供给问题；6.运维部门需要在现有运维框架下如何更快上手，并减少运维难度问题。在互联网+金融和自主可控两大趋势的影响下，中国金融 IT 领域掀起了一场规模空前的转型大潮。传统的 IT 流程、基础架构和运维模式已经无法满足业务发展的需求和竞争形态的转变，传统金融机构都在考虑未来的 IT 开发机制、IT 架构等如何变革。2.1 IT 研发转型 IT 研发转型-如何快速响应用户需求？互联网思维的根本就是快， 只有快速响应用户需求才能在激烈的市场竞争中占据优势。在互联网+转型的过程中，金融行业信息化建设的关键是及时响应业务需求、适应多变的商业环境的灵活的 IT 架构，以满足不同部门、客户和合作伙伴的各种需求。然而，传统的研发模型已经成为应用交付和迭代速度的瓶颈，IT 研发流程和亟待转型。2.2 IT 架构转型 IT 架构转型-烟囱式架构如何向分布式架构无痛转型？在 IT 基础架构层面，很多金融企业都是烟囱式架构，烟囱式架构带来的最大问题是能力孤岛，不同的应用系统之间的资源无法实现共享。并且，在金融走向普惠、拥抱长尾市场的过程中，传统金融 IT 架构无法支撑巨量涌入的长尾客户。随着互联网+转型的深入， IT 基础架构需要获得更多的弹性，从而满足互联网业务对弹性伸缩的需求。因此，IT 系统的云化势在必行。大部分金融企业已经意识到从烟囱式向分布式架构转型的重要性。然而，当前许多架构转型的方案需要经历推倒重来的阵痛，这让他们对云化 IT 基础架构裹足不前。他们需要一套能够实现无痛、渐进式向云计算迁移的方案。2.3IT 运维转型 IT 运维转型-高复杂环境下如何确保系统的高可用性？金融 IT 运维人员的压力之大众所周知， 这源于金融行业对业务连续性和可用性的严苛要求。然而，随着金融信息化的不断发展，金融 IT 环境正在变得越来越复杂：应用纷繁复杂、IT 架构异构、IT 规模日益增大，这些都导致运维的难度越来越大， 运维部门需要全新的思路来应对复杂环境下 IT 系统运维的压力。2.4IT 组织转型 IT 组织转型-如何平衡唯快不破和安全第一互联网的业务拓展和产品研发，讲究唯快不破。业务的交付速度、快速迭代和几乎实时的用户响应，是互联网公司所追求的目标；其研发、运营等组织结构的设计，内部流程审批等权力的分配，也都充分考虑了这样的业务特征和目标。金融行业追求安全第一，但在互联网的节奏下，如何平衡唯快不破与安全第一？如何优化组织结构，在使用技术手段保障安全的同时，在运营环节提高效率、精简流程？这是很多金融决策者需要思考的问题， 也是对金融企业管理层提出的新挑战。3建设方案3.1 容器平台建设容器技术在金融行业的应用场景非常广泛，从开发测试环境到生产环境，都可以采用容器技术。以 Docker 为代表的容器技术， 为金融 IT 和业务转型带来了近乎颠覆性的思路。从容器技术的使用场景来看， 非常适合使用容器技术的应用主要包括几个类型：需要经常更新和快速迭代的应用、需要在云中运行的应用，以及需要从DevOps 和微服务中受益的应用等。下面总结了几个适合采用 Docker 容器技术的场景，包括 CI/CD 持续交付、大规模集群管理、混合云、数据分析应用、微服务化应用、以及云原生应用（Cloud Native Application）等。3.1.1 容器可编排性容器云平台技术架构， 需要符合云原生技术的发展方向， 能支持分布式应用，故而选择合适的容器的管理和编排（Orchestration）工具尤为重要。初级的编排，是资源的编排，即针对物理机或者虚拟机；但更高层次的是服务的编排，需要对架构层次在整体上有一个完整的定义。Docker 技术所解决问题的对象是面向“一个应用”。而在真实的云环境中，工程师需要面对的是将数十类应用构成的“综合系统”， 部署为成百上千个具体实例。这样庞大的工作依靠人工来进行实施显然是难度巨大且风险和成本均极高的。因此就需要有对应于容器运行时的编排技术来解决海量容器的生命周期管理工作，Kubernetes 就是原生技术生态中已成为事实行业标准的一种容器编排技术。Kubernetes 这个名字起源于古希腊，译为“舵手”。如果 Docker 把自己定位为驮着集装箱在大海上遨游的鲸鱼， 那么 Kubernetes 就是掌舵大航海时代话语权的舵手，指挥着这条鲸鱼按照舵手设定的路线巡游。Kubernetes 是 Google 开源的容器集群管理系统，由 Google 多年大规模容器管理技术 Borg 演化而来，并赠给云原生计算基金会（CNCF），其主要功能包括： 基于容器的应用部署、维护和滚动升级； 负载均衡和服务发现； 跨机器和跨地区的集群调度； 容器负载自动伸缩； 无状态服务和有状态服务； 开放 API 以获得扩展性支持。图-Kubernetes 定义容器状态的机制如上图所示，Kubernetes 通过符合 YAML 标准的声明式语言定义Kubernetes 内所有允许的资源类型，包括如 Pod、Deployment、Service 等等。作为基础调度单元， 容器组 （Pod） 通过组织一组紧密关联的容器 （Container） ，他们共享网络和文件系统的特性，而对外提供某一项应用服务能力，并接受Kubernetes 对于其生命周期和接口能力的管理。通过这样的机制，Kubernetes 可以为应用提供以下解决方案： 解决了大规模应用运维的规模性问题，自动化支持海量应用的编排及生命周期管理； 通过简单的声明式语言（YAML）描述了应用的拓扑结构和生命周期，解决了 Dockerfile 无法描述应用自身之外的环境问题，将“从代码到应用”演进到“从代码到服务”； 应用负载实时弹性扩容，无需经过冗长的申请资源、安装操作系统、部署应用、测试、负载上线的繁琐过程，轻松面对流量波峰，完整释放Docker 的生产力； 流量切分和发布策略配合， 实现持续交付， 整合精益管理， 支持 DevOps实践落地； 开放 API，实现对各种第三方网络、存储解决方案的支持能力，满足企业用户的生产需求； 抽象底层环境，标准化镜像、标准化编排，大规模应用亦可随时迁移，不用担心被厂商绑定。除功能支持外，对于企业生产级支撑平台的选型考虑，编排引擎作为调度核心能力的实现技术， 应考虑其未来长期可持续扩展的能力是否能够满足企业业务增长需求。Kubernetes 单一集群内最大可支持 5000 个节点部署，支持包含150000 个容器组或 300000 个容器。再加上多集群扩展的能力，从生产规模支持上完全可满足企业未来长期的业务增长需求。Kubernetes 自身提供的是对由一组容器定义的对象 Pod 提供了运维能力、弹性能力、调度能力、及服务访问能力等几个方面的功能，其对容器运行时、存储、网络等等所有会差异化的外围服务均在以接口驱动的形式来提供支持，即Container Runtime Interface（CRI）、Container Storage Interface（CSI）、Container Network Interface（CNI）。如下图所示：图-Kubernetes 的 Interface 设计模式对于极特殊情况， 当原生内部定义的资源对象如存储类型等无法满足企业需求时，也可以通过 Custom Resource Definition（CRD）来实现新的资源定义扩展 API， 使得 Kubernetes 的开放性可以进一步被无限放大。如下图所示 CRD原理：图-CRD 原理通过以上设计，使得 Kubernetes 面对不同的容器运行时、网络、存储实现甚至是特殊的资源形态要求时，均可通过扩展驱动实现有效兼容，而不用更改其核心功能实现， 换言之 Kubernetes 的兼容性设计很大程度上取决于它的设计边界即是操作这些资源驱动程序，而不是操作某个资源实体本身，是一个高度通用的抽象。基于这样的架构设计，使得 Kubernetes 具备了与生俱来的可兼容性，原理上可以认为，只要下游部署实现不修改上游原有的代码，即使各类部署均具备了对 Kubernetes 的一致兼容性。Kubernetes 已经成为事实上的容器管理的标准，世界上大多数公司都使用它作为容器管理和编排，其有以下几大优势： 开源的力量在不断扩大的容器应用领域，Kubernetes 已发展成为事实上的行业标准。因此，您可以选择多种服务提供商来帮助您在组织的 IT 基础架构中实施它。如果出现任何问题，Kubernetes 开发者的开放社区可以指望做正确的事情。更重要的是，Kubernetes 并不是一个开源了就不再活跃的项目，而是一个全年四次大版本更新的项目。 成本效益容器的复杂性和占用空间都很轻， 而且设置它们比设置 VM 要简单得多。这使得 Kubernetes 成为管理容器化应用程序的非常灵活的平台。Kubernetes 配置可减少错误的 CPU 周期和 GB 的 RAM，从而缩短响应时间，最终提高系统性能。并且由于 Kubernetes 的负载平衡引擎，它可以在需要时启动，停止和优先处理给定的容器 - 所有这些都可以保持性能一致。 可移植性由于其多功能性，Kubernetes 可以在您的组织内本地设置和运行在大量底层操作系统上。此外，如果您决定在整个生命周期的部署过程中迁移到备用操作系统， 您可以随身携带现有工作负载，而无需重新设计应用程序或废品并重新构建基础架构。Kubernetes 避免了供应商锁定，您的设置将继续标准化并随着时间的推移而简化。 可扩展性Kubernetes 从头开始设计为模块化容器管理工具 （CM） ， 您可以自由选择混合和匹配组件，实现真正的交钥匙和定制实施。使用 Kubernetes，您可以决定要运行的操作系统，应用运行时（Libs / Bins），文件系统，处理器架构甚至云平台。应用程序开发人员还可以直接调用 Kubernetes API（应用程序编程接口），并加强应用程序的集成，以提高性能和可管理性。 自愈软件将不时遭受奇怪的故障，导致功能瘫痪和系统失败。然而，这些陷阱将使您成为可靠性困境的牺牲品。但不要害怕：Kubernetes 能够定期监控您的完整基础设施（容器，节点，Pod，网络，硬件，操作系统）。如果软件错误导致系统的某些部分崩溃，Kubernetes 将立即重启应用程序。如果错误是由于硬件故障引起的， Kubernetes 将检测到它并将应用程序分布在多个 pod 中。在这两种情况下，应用程序停机时间都减少到最低限度。 云服务因为 Kubernetes 很受欢迎，用户不需要自己处理内部实现，也不需要在硬件上花钱。事实上， 用户可以通过注册托管的 Kubernetes 解决方案来外包流程：PaaS（平台即服务）或 IaaS（基础架构即服务）。用户的角色是专注于通过用户的应用提供最佳体验，将负载平衡和云服务留给 Kubernetes。综上所述，容器管理和编排技术建议选择 Kubernetes，根据开源社区版本迭代计划，融合业内实践，推荐版本为 Kubernetes 1.16 及以上稳定版本。容器平台提供应用可视化编排部署的相关管理功能，包括拓扑可视化、组件可视化、配置可视化等核心功能。在此基础之上，容器平台还提供了 F5、数据库、DNS、软件负载均衡等常见平台组件及服务的封装功能，实现组件的配置管理、可视化编排支持等功能。容器平台支持的编排功能如下: 应用模板管理与认证:应用模板管理功能支持应用模板新建、删除、修改等操作。同时容器平台提供丰富的应用模板管理能力，比如批量上传应用模板、添加/修改模板变量、展示和修改应用模板描述信息、展示模板与相关应用的关联情况、提供从模板部署应用的向导、支持模板分类和搜索。模板功能还支持验证公有/私有模板，并且支持模板权限配置，设定访问权限。 应用编排管理:容器平台的应用编排管理功能较为丰富。不仅支持与数据库、 F5 等周边系统混编， 还支持更为完善的应用编排管理能力， 比如支持 Kubernetes YAML 编排标准、支持图形化展示编排、 同时编排基础设施资源、 支持编排时指定日志策略/调度策略、 支持图形化修改和维护编排。 应用配置管理:容器平台可以为应用编排设置应用程序日志、 应用端口等配置信息。 容器信息查询:容器平台支持用户以应用系统为维度， 查看应用中容器名称、软件版本、配置信息、所属应用、所属宿主机、运行状态等信息。同时容器平台根据企业级用户的需求，展示更多可用信息，包括镜像层级信息、镜像改动记录、容器内进程信息、容器网络信息、容器存储信息、应用/容器操作审计日志信息、应用可视化拓扑以及编排信息等。 容器操作功能:在编排功能下， 容器平台提供了常用的应用容器操作功能，包括启动、停止、创建、删除等。并且容器平台为了方便企业级用户的操作，额外提供了更为丰富的容器操作功能，包括从容器内下载文件、向容器上传文件、 支持打开容器内部 Shell 控制台、 支持从容器一键制作新镜像、重启容器、暂停以及恢复容器、在不中断容器内业务服务的情况下修改容器资源配额。 负载均衡展示:容器平台提供内置负载均衡， 并能够展示应用整体负载情况，同时容器平台可对接 F5 等外部负载均衡系统或设备，并且支持提供应用级别的负载均衡，应对微服务架构。 服务到容器的自动负载分发:容器平台负载均衡默认采用 Linux 内核中的 LVS 技术，相对于其他软件负载性能较高，并且负载均衡可以配置SSL 证书，当服务的容器扩展后，负载均衡可以自动发现后端服务变化并自动适配，负载均衡可提供多种负载策略，可以通过环境变量进行配置，具备会话保持的功能。 版本管理/灰度发布:针对企业级发布应用的场景，容器平台支持应用版本升级时对各集群进行灰度升级，保证业务的不间断运行，同时容器平台还支持更高级的灰度发布选项，比如设定并行发布实例数、设置发布失败后的错误处理机制、配置发布时 旧版本实例优雅下线策略。3.1.1.1多模式应用编排3.1.1.1.1 应用容器编排云原生技术平台管理系统提供了应用可视化编排部署的相关管理功能， 包括拓扑可视化、组件可视化、配置可视化等核心功能。在此基础之上，云原生技术平台管理系统还提供了 F5、数据库、DNS、软件负载均衡等常见平台组件及服务的封装功能，实现组件的配置管理、可视化编排支持等功能。云原生技术平台管理系统支持的编排功能有: 应用模板管理与认证:应用模板管理功能支持应用模板新建、删除、修改等操作。同时云原生技术平台管理系统提供了更为丰富的应用模板管理能力， 比如批量上传应用模板、 添加/修改模板变量、 展示和修改应 用模板描述信息、 展示模板与相关应用的关联情况、 提供从模板部署应 用的向导、 支持模板分类和搜索。模板功能还支持验证公有/私有模板， 并且支持模板权限配置，设定访问权限。 应用编排管理:云原生技术平台管理系统的应用编排管理功能较为丰富。不仅支持与数据库、F5 等周边系统混编，还支持更为完善的应用编排管 理能力，比如支持 Kubernetes YAML 编排标准、支持图形化展示编排、 同时编排基础设施资源、支持编排时指定日志策略/调度策略、支持图形化修改和维护编排。 应用配置管理:云原生技术平台管理系统可以为应用编排设置应用程序日志、应用端口等配置信息。 容器信息查询:云原生技术平台管理系统支持用户以应用系统为维度，查看应用中容器名称、软件版本、配置信息、所属应用、所属宿主机、运行状态等信息。同时云原生技术平台管理系统根据企业级用户的需求，展示更多可用信息，包括镜像层级信息、镜像改动记录、容器内进程信息、 容器网络信息、 容器存储信息、 应用/容器操作审计日志信息、 应 用可视化拓扑以及编排信息等。 容器操作功能:在编排功能下，云原生技术平台管理系统提供了常用的应用容器操作功能，包括启动、停止、创建、删除等。并且云原生技术平台管理系统为了方便企业级用户的操作，额外提供了更为丰富的容器操作功能，包括从容器内下载文件、向容器上传文件、支持打开容器内部 Shell 控制台、支持从容器一键制作新镜像、重启容器、暂停以及恢复容器、在不中断容器内业务服务的情况下修改容器资源配额。 负载均衡展示:云原生技术平台管理系统提供内置负载均衡，并能够展示应用整体负载情况， 同时云原生技术平台管理系统可对接 F5 等外部负载均衡系统或设备，并且支持提供应用级别的负载均衡，应对微服务架构。 服务到容器的自动负载分发:云原生技术平台管理系统负载均衡默认采用 Linux 内核中的 LVS 技术， 相对于其他软件负载性能较高， 并且负载均衡可以配置 SSL 证书，当服务的容器扩展后，负载均衡可以自动发现后端服务变化并自动适配， 负载均衡可提供多种负载策略， 可以通过环境变量进行配置，具备会话保持的功能。 版本管理/灰度发布:针对企业级发布应用的场景， 云原生技术平台管理系统支持应用版本升级时对各集群进行灰度升级，保证业务的不间断运行，同事云原生技术平台管理系统还支持更高级的灰度发布选项，比如设定并行发布实例数、设置发布失败后的错误处理机制、配置发布时旧版本实例优雅下线策略。3.1.1.1.2 应用混合编排现有的应用开发流程中，为了提高研发效率，相关部门会预先配置好一部分数据库服务用于研发测试。根据研发业务的不同， 数据库服务包括:Oracle 服 务，MSSQL 服务以及 DB2 服务。随着业务量的增长，相应的研发生产线也呈多样化发展，向研发测试提供数据库服务部门的压力也越来越大。现有的情况下，研发测试面临着申请数据库服务流程周期长， 服务部门向不同研发生产线交付相应的数据库服务的压力也越来越大。云原生技术平台管理系统的数据库混合编排借鉴了公有云的数据库编排服务， 经过了大规模使用的验证。云原生技术平台管理系统的数据库混合编排主要有以下几点特征: 服务注册:当服务部门配置好相关数据库服务后，可通过 WEB 页面向服务注册模块注册该数据库服务，供研发测试部门使用。可通过选择不同的数据库服务类型来注册数据库服务，包括:Oracle 数据库服务、MSSQL 数据库服务、DB2 数据库服务等。 服务管理:可通过 WEB 页面对已注册的数据库服务进行管理，管理操作包括:增加新数据库服务，删除已有数据库服务，更新已有数据库服务配置，删除数据库服务。 服务绑定:可通过应用的页面将数据库服务绑定到应用容器内， 服务绑定将数据库的信息设置到应用容器的环境变量内，供应用容器取用。 服务发现:该方案依托客户端服务发现的场景，“数据库服务发现应用”提供了一系列 RESTAPI 供客户端调用，并可将数据库配置信息以结构化数据的形式返回供客户端使用。云原生技术平台管理系统的混合编排方案架构图如下所示:图-混合编排架构图云原生技术平台管理系统数据库混合编排服务将云原生技术平台管理系统与数据库资源池深度集成。“数据库服务编排应用”以插件的形式部署在云原生技术平台管理系统平台上。该应用将提供对接云原生技术平台管理系统用户权限控制模块的功能。通过对 API 进行授权访问，可控制特定用户访问特定的数据库服务资源。“数据库服务发现应用”将对接云原生技术平台管理系统的用户权限控制，避免二次配置用户权限。3.1.1.2 负载均衡云原生技术平台管理系统支持两种负载均衡方案:7 层负载均衡和 4 层负载均衡，需要在不同的应用场景下选用不同的负载均衡方案。云原生技术平台管理系统负载均衡方案整体架构图如下所示:图-负载均衡3.1.1.2.1 内置 4 层负载均衡解决方案云原生技术平台管理系统的 4 层负载均衡 IPVS 解决方案主要用于弹性伸缩的场景，通过端口转发将请求转发至多个容器内，应用场景如下图所示:针对该场景，云原生技术平台管理系统内置了一套 IPVS 负载均衡的解决方案。LVS 是一个高性能的负载均衡，并能够支持自动的服务发现功能。云原生技术平台管理系统的 4 层负载均衡解决方案架构图如下所示:使用 IPVS 作为负载均衡解决方案的优势: Docker 内置机制 基于内核 LVS 技术，高效转发高性能请求转发 高可用架构(如果云原生技术平台管理系统有多个节点) 自动适配后端应用变化 自动检测后端状态，并实现容错 热更新，无中断的配置更新3.1.1.2.2 内置 7 层负载均衡解决方案云原生技术平台管理系统内置的 IPVS 能力之上提供了一套 7 层负载均衡组件如 Nginx、 HAProxy 和 Traefik 等， 该组件通过自动获得集群中服务的域名配置(目前通过服务 label 实现)，自动更新负载均衡转发策略。下图表示以 Traefik 为例的解决方案整体架构图:使用七层负载均衡解决方案的优势: 友好的图形界面管理能力 支持用户/租户级别的 LB，适应微服务场景 高性能请求转发 高可用架构(如果云原生技术平台管理系统有多个控制器) 自动适配后端应用变化 优雅的中断 HTTP 连接 自动后端健康检查，并实现容错 热更新，无中断的配置更新 提供简单的性能监控报表 HTTP2 支持 Websocket 支持 HTTPS/SSL 支持3.1.1.3 存储管理3.1.1.3.1 数据持久化容器运行期间产生的数据是不会在写镜像里面的，重新用此镜像启动新的容器就会初始化镜像，会加一个全新的读写入层来保存数据。如果想做到数据持久化，就必须寻求其他解决方案来保存数据。云原生技术平台管理系统通过存储卷(volume)用于持久化存储 Docker 容器的数据，存储卷分为本地卷和远程卷和快照，其中本地卷是对本机磁盘的映射，远程卷和和快照需要在集成中心集成第三方存储服务(比如 ScaleIO)才可以使用: 本地存储卷:本地卷没有容量或读写性能的限制(上限由磁盘的规格和性能决定)。本地卷亦不可创建快照。一般地，在创建应用时，可以通Compose YAML 指定。 远程存储卷:远程卷的创建以及使用过程同本地卷类似。云原生技术平台管理系统远程存储卷包括 NFS 存储卷和其他远程存储卷。NFS 远程卷的创建需要增加设备、读写权限、设备目录的信息。其他远程存储卷主要包括支持 ScaleIO 等存储软件的 REXRAY 驱动存储卷，以及 VMDK 存储卷。3.1.1.3.2 数据持久化保护与恢复云原生技术平台管理系统通过对存储卷创建快照，来保护数据。以ScaleIO 为例，查看 ScaleIO 详情，可以看到云原生技术平台管理系统提供的创建快照按钮:点击创建快照，填入快照名称，点击创建快照。云原生技术平台管理系统提供了 UI 界面供恢复快照用，进入快照详情页面，点击恢复即可:3.1.1.4 网络方案云原生技术平台管理系统完全支持 Kubernetes 多种网络方案。只要符合CNM 模型的网络插件都可以被云原生技术平台管理系统接入用于管理容器间网络通信。云原生技术平台管理系统目前产品内置支持的网络技术包括:Flannel、 Calico，同时可以通过插件支持 Macvlan 网络。下图为基于云原生技术平台管理系统的网络方案整体架构图:3.1.1.4.1 CalicoCalico 是一个纯三层的数据中心网络方案(不需要 Overlay)，并且与OpenStack、Kubernetes、AWS、GCE 等 IaaS 和容器平台都有良好的集成。Calico 在每一个计算节点利用 LinuxKernel 实现了一个高效的vRouter 来负 责数据转发，而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路 由信息像整个 Calico 网络内传播小规模部署可以直接互联，大规模下可通 过指定的 BGP routereflector 来完成。这样保证最终所有的 workload 之间的数 据流量都是通过 IP 路由的方式完成互联的。Calico 节点组网可以直接利用数据 中心的网络结构(无论是 L2 或者 L3)，不需要额外的 NAT，隧道或者 Overlay Network。此外，Calico 基于 iptables 还提供了丰富而灵活的网络 Policy，保证通过各个节点上的 ACLs 来提供 Workload 的多租户隔离、安全组以及其他可达性限制等功能。Calico 主要由 Felix、etcd、BGP client 以及 BGP RouteReflector 组成 ： Felix，CalicoAgent，跑在每台需要运行 Workload 的节点上，主要负责配置路由及 ACLs 等信息来确保 Endpoint 的连通状态; etcd，分布式键值存储，主要负责网络元数据一致性，确保 Calico 网络状态的准确性; BGPClient(BIRD),主要负责把 Felix 写入 Kernel 的路由信息分发到当前 Calico 网络，确保 Workload 间的通信的有效性; BGP RouteReflector(BIRD)，大规模部署时使用，摒弃所有节点互联的 mesh 模式，通过一个或者多个 BGP RouteReflector 来完成集中式的路由分发。3.1.1.4.2 FlannelFlannel 通过给每台宿主机分配一个子网的方式为容器提供虚拟网络，它基于 LinuxTUN/TAP，使用 UDP 封装 IP 包来创建 overlay 网络，并借助etcd 维护 网络的分配情况。控制平面上 host 本地的 flanneld 负责从远端的 ETCD 集群同步本地和其它 host 上的 subnet 信息，并为 POD 分配 IP 地址。数据平面 flannel通过 Backend (比如 UDP 封装)来实现 L3Overlay，既可以选择一般的 TUN设备又可以选择 VxLAN 设备。除了 UDP，Flannel 还支持很多其他的 Backend: udp:使用用户态 udp 封装，默认使用 8285 端口。由于是在用户态封装和解包，性能上有较大的损失; vxlan:vxlan 封装，需要配置 VNI，Port(默认 8472)和 GBP; host-gw:直接路由的方式，将容器网络的路由信息直接更新到主机的路由表中，仅适用于二层直接可达的网络。3.1.1.5 弹性伸缩3.1.1.5.1 弹性伸缩策略简介弹性伸缩(AutoScaling)是根据不同的业务需求与策略， 自动调整应用的 弹性计算资源， 最终达到优化资源组合的服务能力。通过自动伸缩和手动伸缩这 两种工作模式， 应用便能在无运维人员介入的情况下实现自动调整计算资源， 当 访问量上涨时增加计算能力， 而当访问量下降时减小计算能力， 既保障了系统的 稳定性与高可用性，又节约了计算资源成本。弹性伸缩在业界有两个方向，一个是垂直化的扩展(Scaleup)，一个水平化的扩展(Scaleout)。从业务发展的角度来看应该是水平扩展的能力，这要求业务都是无状态的， 通过负载均衡技术将访问请求分配到集群每一台机器上， 不管 是增加还是减少机器，业务的连续性都不应受到影响。3.1.1.5.2 云原生技术平台管理系统的弹性伸缩策略云原生技术平台管理系统同时支持自动伸缩和手动伸缩两种策略。自动伸缩方面，对于不同的应用，云原生技术平台管理系统通过平台内置的弹性伸缩引擎来灵活地提供弹性伸缩功能。目前，云原生技术平台管理系统的弹性伸缩策略支持从内存、CPU 负载、线程池剩余线程数、会话数等维度来进行弹性扩缩容。自动伸缩的架构如下图所示:相比较其他平台的弹性伸缩功能， 云原生技术平台管理系统平台的弹性伸缩具备如下特点: 容器化部署，最高程度提高部署的灵活度。弹性伸缩作为云原生技术平台管理系统的一个模块，通过应用模板的方式容器化部署，可以做到针对每个服务提供不同的弹性伸缩策略而不会相互影响。 伸缩策略灵活且可定制化。弹性伸缩和应用紧密耦合，根据不同应用的特点和表现需要设定不同的弹性策略，云原生技术平台管理系统的弹性伸缩内置根据容器资源(CPU 和内存使用情况)和中间件资源(Tomcat 的线程数和会话数)， 除此之外， 用户可灵活设置应用特定的弹性策略如MySQL 数据库并发量、应用的网络连接数等。 开放接口，方便二次开发。云原生技术平台管理系统完全兼容 Docker原生 API，同时还提供平台相应的二次开发 API，云原生技术平台管理系统自动伸缩模块也是根据云原生技术平台管理系统的 API 进行开发而 成。如用户需要根据平台进行深度二次定制开发， 云原生技术平台管理系统弹性伸缩模块可以很好支持和对接。 伸缩资源广泛，粒度可调。云原生技术平台管理系统应用平台提供南向北向的集成，除容器管理功能外，云原生技术平台管理系统可以很好集成 Vmware 和 Openstack 实现对虚机的动态创建和管理。除自动伸缩功能，平台也支持方便的手动伸缩功能。手动伸缩在应用测试、不方便设定容器阈值和容器缩容等场景下具有较强的需求， 通过在云原生技术平台管理系统应用的服务页面选择服务扩展和缩小后的容器数量， 便可快速实现手动的容器弹性扩缩。3.1.1.6 应用管理功能3.1.1.6.1应用生命周期管理图形化界面针对应用的整个生命周期进行管理， 提供多种部署方式一键部署、通过镜像部署、YAML 编排、基础镜像部署四种方式，同时提供包括应用的启动、 停止、下线、重新启动、版本更新等功能及可手动调整 CPU、内存、实、应用制 作镜像、上传文件、下载文件、重命名、更新应用镜像等操作。实现功能如下:部署方式提供多种部署方式一键部署、 通过镜像部署、 YAML 编排、 基础镜像部署四种方式图-部署方式应用基础功能同时提供包括应用的启动、停止、下线、重新启动基础维护功能。图-应用基础功能版本更新提供应用镜像版本更新功能，可进行新版本更新亦可进行历史版本回滚。图-应用镜像版本更新弹性伸缩平台自带弹性伸缩功能，提供 CPU、内存等阈值规则设置，通过阈值进行自动扩展或收缩实例，已扩展实例通过标签自动接入平台负载均衡能力，支持通过 拓扑关系展示当前应用于其他应用、服务等资源的关系。图-弹性伸缩配置图-应用拓扑3.1.1.6.2 应用资源资源平台提供可视化界面管理应用资源管理， 针对应用初始化发布提供缺省资源配置，对已经发布运行的应用可进行资源调整包括应用实例数、内存、磁盘、路由、服务、容器发布、容器调度策略等信息。实现效果如下:图-应用镜像版本更新图-应用负载路由配置图-自动配置路由信息图-手动配置负载路由3.1.1.6.3 应用状态查询平台支持简单方式，供租户查询其发布的所有应用及每个应用的运行状态，包括应用运行状态、实例数量、资源使用情况、服务使用情况等。可查询应用发布日志、运行日志以及应用中定义的各种日志输出。平台管理员可以通过统一的web 界面查看所有应用上述的运行状态及日志。实现效果如下:图-运行应