【作者】杨梦伦 刘艳春 刘中梅
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.3 IT 运维转型
IT 运维转型-高复杂环境下如何确保系统的高可用性？
金融 IT 运维人员的压力之大众所周知， 这源于金融行业对业务连续性和可用性的严苛要求。然而，随着金融信息化的不断发展，金融 IT 环境正在变得越来越复杂：应用纷繁复杂、IT 架构异构、IT 规模日益增大，这些都导致运维的难度越来越大， 运维部门需要全新的思路来应对复杂环境下 IT 系统运维的压力。
2.4 IT 组织转型
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 Calico
Calico 是一个纯三层的数据中心网络方案(不需要 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 Flannel
Flannel 通过给每台宿主机分配一个子网的方式为容器提供虚拟网络，它基于 LinuxTUN/TAP，使用 UDP 封装 IP 包来创建 overlay 网络，并借助etcd 维护 网络的分配情况。
控制平面上 host 本地的 flanneld 负责从远端的 ETCD 集群同步本地和其它 host 上的 subnet 信息，并为 POD 分配 IP 地址。数据平面 flannel通过 Backend (比如 UDP 封装)来实现 L3Overlay，既可以选择一般的 TUN设备又可以选择 VxLAN 设备。
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 界面查看所有应用上述的运行状态及日志。
实现效果如下:
图-运行应用信息
图-停止应用信息
图-日志信息
图-资源使用信息
3.1.1.6.4 配置文件
平台提供配置参数管理基于配置文件实现对应用配置信息的集中管理， 提供基础配置文件与加密配置文件两种方式。
图-创建配置-命令
图-创建配置-上传文件
图-加密配置文件
3.1.1.6.5 镜像工厂
平台提供镜像工厂，镜像工厂可管理设置过个镜像仓库，集成的 docker 镜像(docker registry)服务，提供便捷公有、私有镜像的*切换功能，提供日常镜像空间维护功能，空间可细化授权为个人及团队管理，针对不同的镜像空间可以通过统筹进行控制空间可存放镜像的数量，支持镜像同步功能支持根据规则实现镜像远程复制，也支持镜像扫描服务。且提供标准运行环境支持 Java、 PHP、Node.js、Ruby、Go、Python 等语言，可定制提供更多语言类型及版本。可通过提供镜像模板以及自定义镜像方式支持更多的应用类型和语言实现效果如下:
图-空间镜像详情及创建空间
图-镜像空间设置
图-空间授权
图-镜像复制
图-基础镜像
3.1.1.6.6 部署管理
平台提供统一镜像标准交付部署，对于日常的迭代变更上线，系统以镜像为管理颗粒度， 所有进行统一通过镜像工厂进行管理， 实现对基础部署、 部署策略、容器管理等功能
实现效果如下:
图-应用部署
图-容器管理
图-灰度部署
3.1.1.6.7 应用商店
模块商店
模块中心包含模块商店与模块管理两个部分， 模块商店由两个部分构成内置模块与定制服务模块两个部分，内置模块即是自主开发通用模块，定制服务模块根据客户实际需求定制的服务应用。模块按照类型划分，每个模块提供对应的概述、截图描述、资源说明、安装说明及技术支持内容。选择需要进行安装的模块进行安装，针对已经安装的模块提供管理功能，设置模块的启动与卸载。
实现效果如下:
图- 模块管理
图- 模块管理-安装
图- 模块管理-安装
图- 模块管理-模块截图说明
模块管理
模块管理是针对已经安装的模块进行管理， 同时可以提供手动安装模块及构建新模块，手动安装模块是通过镜像工程或互联网镜像安装。构建新模块是基于平台提供的开发者平台结合我们开发的 API 进行应用的开发，开发完成后通过镜像的方式存储到镜像工程，然后进行手动安装，已经安装的模块可以进行更新与卸载。
图- 模块管理
容器组
提供容器组下容器的运行状态，包含容器名称、应用、宿主机、镜像、运行中、状态、重启次数、创建时间的信息查询及调试访问与删除功能。
图- 容器组信息
3.1.1.6.8 基于模板部署
平台内置种类丰富的应用模板， 模板管理页面提供名称及应用分类组合定位检索功能，用户可通过管理模块进行模板功能的创建、分类、修改、删除等日常维护， 不同应用之间在部署方面也有一定的相似性，通过模板可以进行快速的构建部署任务。
图- 新增模板
图- 模板详情
3.1.1.7 服务管理
3.1.1.7.1 服务管理
提供可视化界面管理服务，提供服务名称、应用、镜像、状态、创建时间等基础信息查询及日常维护快速入口，可创建和绑定新服务，并对已创建的服务进行监控和生命周期管理。
图-服务查询及日常维护
3.1.1.7.2 服务发现
平台提供基于 etcd 的原生服务发现，同时也支持通过 dns 及微服务erueka 的服务发现机制。
3.1.1.7.3 数据库服务
平台内置支持 Mysql、PostgreSQL、MongoDB、Redis、Memcached、Casandra 服务组件作为基础服务模板，同时亦可提供消息队列、大数据服务、容器服务等组件，支持对数据库服务的搜索、启动、停止、重启、删除等操作，可以对数据 库的基本信息、实例信息、配置信息、日志信息进行管理，可以监控 cpu、内存、磁盘、下行速度等信息，并提供备份管理功能。
图-数据库模板
图-大数据模板
图-日志信息
图-操作日志
图- CPU、内存
3.1.1.7.4 存储
平台提供存储卷管理，提供存储卷基础维护功能，新增、删除及 YAML 的高级安装编排功能。
图-存储
3.1.2 容器平台可扩展性
3.1.2.1 集群规模扩展能力
容器平台软件底层遵循 Kubernetes 核心架构设计， 从集群节点和容器支撑的规模上，核心因素取决于主机性能。集群每增加一个节点，kube-controller计算开销分别增加 0.1CPU/80MB 内存；而创建 namespace 则是 kb 级内存开销，几乎可以忽视其资源占用。
集群内置的用户中心采用 OpenLDAP 实现，OpenLDAP 支持集群技术，可通过持续的横向节点扩展提升用户表规模，支持近乎无限的用户创建。用户中心亦支持用户自行选择 AD 等不同第三方实现标准化接入。
随着集群访问用户的增加，平台控制器单个前端实例默认状态下支持 150左右用户并发访问达到预设资源峰值，当用户并发大于此数值时，可通过增加前端服务 CPU/内存提供更高的并发支撑能力，也可以通过增加前端控制器服务的容器实例数量实现横向的性能扩展。
3.1.2.2 插件扩展能力
由于云原生社区正处于一个快速发展丰富的扩张阶段， 而在整个社区范围中，Kubernetes 仅承载其中很少一部分计算编排的角色，在真实的使用场景中，用户所使用的功能大量来自于其他社区围绕 Kubernetes 扩展的能力，典型例如Ingress，CoreDNS 等都不是 Kubernetes 的自身能力却又不可或缺。因此，平台从设计架构上， 采取插件的模式实现系统在架构保持稳定的基础上提供对新功能组件的扩充。当前集群所使用 Ingress、CoreDNS、HPA、Istio 等均属于在这一体系下持续添加的功能。
插件结合平台 API/SDK 集成开发，以一组独立的镜像打包模块后发布到平台，通过插件管理中心进行安装。
安装后的插件根据规范一般是在独立的 namespace 中运行的一系列容器，其生命周期由平台进行统一管理。
3.1.2.3 OpenAPI 接口扩展能力
容器平台基于 OpenAPI 标准开放接口，兼容使用 Kubernetes 原生 API 调用。进行二次开发时配置接口地址、请求参数和响应参数与使用 Kubernetes 官方 API 完全一致。通过接口创建的对象和通过平台页面操作创建的对象保持一致。
3.1.3 安全合规性对接
3.1.3.1 统一身份认证
容器平台作为 IT 信息化系统，在安全和权限管理上也遵从统一的身份认证和管理方式。采用统一身份系统来实现和企业内部的认证系统的对接，从而获取用户身份验证信息，及获取和更新配置信息。
统一身份认证系统可以对接多种身份管理系统，比如 LDAP,CA 以及还是现有 AD 域安全系统。整个身份对接系统的内部结构如下图:
图-统一身份认证
如上图所示，统一身份认证系统通过一套安全和认证管理的模块，可以完成下述功能:
◼ 身份认证中心:存储企业用户目录， 完成对用户身份、 角色等信息的统一管理。
◼ 授权和访问管理系统:用户的授权、角色分配;访问策略的定制和管理;用户授权信息的自动同步;用户访问的实时监控、安全审计。
◼ 身份认证服务:身份认证前置为应用系统提供安全认证服务接口， 中转认证和访问请求;身份认证服务完成对用户身份的认证和角色的转换。
◼ 访问控制服务:应用系统插件从应用系统获取单点登录所需的用户信息;用户单点登录过程中，生成访问业务系统的请求，对敏感信息加密签名。
◼ AD域管控中心及数字证书受理系统:用户身份认证和单点登录过程中所需证书的签发;用户身份认证凭证(USB 智能密钥)的制作。
3.1.3.2 与现有监控体系对接
当前，在银行为所提供的各类金融服务中，有很大的比例需要依托 IT 系统实现， 因此银行数据中心的稳定可靠运行，是银行能否为提供优质服务的基础保障。对于新增的容器平台，需要纳入到数据中心的整个集中监控体系，对各类设备/应用的运行参数和状态进行监控和管理；对设备/应用的故障状态进行报警输出。
目前， 银行数据中心已经实现了系统监控、 应用监控、 日志监控和交易监控，同时，监控系统内置 HUB，支持收集第三方监控。银行监控系统与 CMDB 实现对接，可通过固定 IP 获取资产系统的映射关系，实现集中告警。
图-监控体系对接
3.1.3.3 与集中日志系统对接
目前，银行不少应用系统的日志单独存放，并通过 ITM 进行日志监控，但单一系统的日志信息量有限，出现故障、告警时，往往需要查询多个关联应用系统的日志信息才能准确定位，故障定位难，效率低。为此，为了更好的进行日志收集、日志存储、日志分析及管理，银行数据中心建设统一的日志中心，中心化的日志处理方案有效地解决了在完整生命周期内对日志的消费需求。
容器平台除了需将平台日志上报给集中的日志中心外， 容器平台上运行的容器日志、应用/服务日志也要集中上报的日志中心。
图-日志对接
容器平台与日志中心集成，需满足如下需求：
◼ 针对动态增减的容器实例，保证日志收集对象的完整
◼ 涵盖平台日志和应用日志
◼ 收集容器的标准输出日志和内部应用的多个文件日志
◼ 容器平台上的应用日志需通过 Kafka 消息队列分发给集中式日志中心
◼ 上传的数据应至少包含收集时间、集群、应用、服务、容器等关键标识
◼ 对接的行内日志中心如出现异常，不能出现日志丢失或不完整的情况
◼ 支持大规模的日志上传，且不丢失数据
◼ 平台日志中心需要对具有“容器感知”能力，建立多级索引，支持复杂条件的查询，支持各种业务监控告警，如基于应用的日志查询，基于容器的查询等。
3.1.3.4 与堡垒机对接
图-堡垒机对接
为了保障网络和数据不受来自外部和内部用户的入侵和破坏， 堡垒机综合了运维管理和安全性的融合，切断了终端计算机对网络和服务器资源的直接访问，而是采用协议代理的方式，接管了终端计算机对网络和服务器的访问，从而具备如下特点：
◼ 运维人员通过堡垒机登录系统，所有操作行为被记录和审批；
◼ 堡垒机保全了全部的生产用户信息；
◼ 应用系统之前相互隔离，运维人员分别登录自己有权访问的系统；
由于容器平台的应用集中管理，带来用户的集中和潜在的操作风险，为了强化容器平台的接入安全，要求各用户接入容器平台进行应用管理时，必须经由堡垒机进行安全接入控制。
另一方面，容器平台也拥有用户管理及权限控制功能，为便于用户管理及权限控制（需支持不同的角色权限，如高级用户具有高权限，普通用户只具有只读或查看权限），以及强化用户单点登录体验，容器平台经由服务流程平台中转，实现用户信息、权限信息的同步。
◼ 容器平台对接到堡垒机中，其中堡垒机中保存用户信息，容器平台中保留资源信息，授权信息。堡垒机的用户按照组织架构分组管理，在容器平台中建立这些组对接的用户。
◼ 用户在日常维护时，使用容器平台的低权用户。用户先登录到堡垒机，堡垒机根据用户的映射关系，使用该用户对应的组用户登录容器平台。
◼ 用户在变更时，使用容器平台的高权用户。用户在服务流程平台提交申请，申请获批后，登录到堡垒机，堡垒机根据用户的映射关系，使用该用户对应的组的高权登录容器平台。
◼ 容器平台提供项目注册以及配额信息的管理，管理员控制项目数量以及各个项目的资源上限。
◼ 容器平台可以维护用户的注册添加，对于本地账号，支持设置强制的密码强度要求。
◼ 容器平台用户的登录， 支持本地账户， LDAP 账户以及 SSO 对接账户的身份验证，对于成功登录的用户，发放 token 用于后续的身份验证。对于连续多次登陆失败的账号，会进行短时间封禁；对于长时间未修改密码或者密码强度不够的账号，会根据配置，推荐或强制其修改密码。
◼ 容器平台的用户安全模块在架构还充当 API gateway 的职责。用户在外部调用容器平台 API 的时候， 请求都会优先转发给用户安全管理组件以便验证Token，确认用户身份和角色信息，并根据用户访问的 Restful API 的方法和路径解析当前用户是否有相应权限，只有有权限的请求会被转发给内部组件处理。
3.2 统一知识库
在企业内部，对知识并没有一个明确的、清晰的定义。企业一经创建，总是会源源不断建设和产生实物资源， 这些实物资源的自然利用是企业应用知识的最初级形式。在应用实物资源的过程中，有些资源可以被改造加工，进而提升了资源的共享化和智能化程度，促进了可用性，使得资源具备了知识的特征。
知识与资源的关系是相对的，资源与知识之间是相互转化的。对特定层次来说，高层次的对象就是知识，低层次的对象就是资源。因此，对企业而言，知识和资源是同一种对象，只不过是层次高低不同罢了。知识工程建设和资源建设之间没有绝对界限，在工程实践中也不需要明确这个界限。从实用的角度讲，凡是对工作有帮助的资源都是知识。因此，在产品研发设计中有用的资源，都可作为知识工程的建设范围。
3.2.1 建设目标
知识应用要实现以下几方面的建设目标：
◼ 实现各类知识的体系化管理与基础性功能应用；
◼ 实现各类知识与应用开发流程的融合，形成对应用开发流程的知识化支撑；
◼ 实现各类知识与开发、运维行为的关联，形成基于个人形成的个人知识空间；
◼ 实现对各类知识应用效果的分析统计；
◼ 实现各类知识的多渠道应用；
◼ 实现各类知识与工程师工作场景的融合， 达到知识 “随需而现” 的效果。
3.2.2 建设方案
为了实现上述几方面的知识应用建设目标， 将从两方面考虑知识应用方案的建设， 第一方面是构建知识应用的基础功能；第二方面是为应用基础功能构建多种应用途径。
(一) 知识应用的基础功能
(二) 知识应用的多途径
知识应用的途径有三种，分别是知识的门户应用、知识的客户端应用、知识的嵌入业务系统应用。
◼ 知识的门户应用：通过构建基于浏览器的知识门户系统，实现对各类知识的体系管理与应用，实现各类知识与应用开发流程的融合等。如：知识搜索、知识地图、知识面向研发流程的知识推送、基于检索频率的知识推送、个性化定制知识推送等。
◼ 知识的客户端应用：通过客户端，将各科室中与每个研制任务相关的知识结构化的组织在一起， 结构化的维度包括：输入、 输出、 流程、 质量、模板组件、 关联任务、 关联知识等。实现以研制任务为主体的知识地图，以及知识与应用开发流程的融合。
◼ 知识的嵌入容器平台系统应用：将知识推送到工程师的工作界面，在容器平台相关界面，嵌入知识链接。实现知识与工程师工作场景的融合。
3.2.3 知识分类
容器平台的知识包括平台自身相关的内容， 同时包括与平台相关的外围系统的知识，我们容器平台知识划分为九类。每类资源可以根据需要进一步细化，形成更小的资源类别。如下表所示。
3.3 统一制品发布
金融 IT 采用容器技术的一个非常大的驱动力就是加速应用交付和迭代， 尤其是那些直接面向客户和内部流程的 IT 系统。以 Docker 为代表的容器技术，为企业的应用交付平台和开发运维联动带来了近乎颠覆性的进步。过去，开发、测试、 运维被分割成独立的阶段， 每个阶段交付不同的内容， 开发人员交付代码，测试人员交付测试包，运维人员搭建环境。这样的模式下，应用交付的速度已经无法满足业务对速度的需求。
Docker 的出现，为持续集成、持续交付（CI/CD） 和开发运维联动带来了新的思路。如下图所示， Docker 将应用的交付件统一为 Docker 镜像 （图中类似乐高积木的模块），使得开发人员、测试人员和运维人员的交付内容都是标准化容器镜像，镜像中已经包括了应用对环境的所有需求，包括操作系统、中间件和应用代码。他们基于镜像进行协作，实现了应用以及其依赖环境的整体交付，从而极大地提升了效率，也降低了安全隐患。
3.3.1 方案架构
图-方案架构
完整的 CI/CD 持续交付解决方案实现 Code to Cloud 全流程自动化,开发者只需要关注最核心的代码层面，接下来的测试、构建、集成、部署等过程，都可以由 CI/CD 平台自动化完成。CI/CD 平台通过镜像进行版本的识别和控制，实现灰度发布和回滚。
开发运维一体化场景中，非常值得一提的是，当前很多金融行业的应用是由外包开发商开发，金融企业内部 IT 人员缺乏对应用的控制能力。通过容器化的应用交付模式，开发商的应用交付形式被标准化了，极大的降低了对开发商的依赖，提高了运维效率。
◼ 全功能产品团队，开发／测试／运维在一个组织架构下
◼ 应用有持续迭代要求，版本的每次更新都需要通过开发、测试、发布全过程
◼ 测试环境和生产环境部署主要靠人工操作，环境的差异性导致部署效率低，大量沟通成本
◼ 应用技术栈趋向于多元化，应用配置／运维／管理差异性大，管理成本高。
通过 CI/CD 平台支撑企业持续交付流程， 打造跨环境无差异软件交付过程，实现软件资产高效和自动的交付。
图-交付流程
3.3.2 代码版本管理
代码版本管理是企业软件资产的重要组成部分， 维护了企业开发过程的代码成果。甚至，在很多现代化企业软件开发方法论中，团队的协作流程也是依据代码版本管理规范展开的，CI/CD 需要支持对接企业常用的代码版本管理系统，包括 Git/SVN/GitHub/GitLab，通过可灵活定制的触发策略，实现由代码驱动的软件持续交付自动化。
3.3.3 自动化测试
通常我们把自动化测试前置到提测前， 以此作为是否达到提测要求的快速验证。因此在定义流水线时,我们应该将自动化测试阶段定义的整个流水线的前半部分,下面将以 RobotFramework 测试框架来说明。有很多理由使得 Robot Framework 非常受欢迎，比如：
◼ 支持简单易用的表格型语法，使得可以用统一方式创建测试用例
◼ 提供可以复用既存的关键字的功能
◼ 提供 HTML 的简单易读的报表和日志结果文件
◼ 平台和应用相互独立
◼ 提供简单的 Libary API，可以使用 Ptyhon 或者 java 进行实现
◼ 提供命令行接口也 XML 格式的输出文件，非常容易进行持续集成
◼ 支持 Selenium，Java GUI 测试，Telnet，SSH 等
◼ 支持创建数据驱动的测试用例
◼ 变量的内建支持，尤其是不同测试环境下的测试
◼ 提供 test case 和 test suite 级别的 setup 和 teardown
◼ 通过平台的内置模块可以很方便的集成 Robot Framework
3.3.4 打包构建
打包构建负责把软件代码转变为应用交付件，包括了代码获取、编译构建、版本标示三个部分。
◼ CI/CD 可以根据预先定义好的触发规则自动启动打包构建过程，实现当代码端进行了指定的变更时，自动从代码版本管理系统中拉取特定的代码版本。
◼ 代码拉取以后，CI/CD 会根据代码中的编译构建描述文件，即 Dockerfile文件，进行镜像构建。整个构建过程都是可追溯的，实现了软件资产和代码资产的关联。
◼ 镜像构建完成后，CI/CD 根据预先定义的策略标示镜像版本，并推送至CI/CD 内置的企业镜像仓库。
同时，编译打包的过程往往对计算和内存资源消耗很大，为了不影响集群已有应用的正常运行，需要把编译打包环境和应用运行环境进行隔离。CI/CD 可以指定集群中的某些节点为专属构建主机，实现计算任务的合理调度。
3.3.5 运行环境
在持续交付流程中，需要提供一个开发、测试、生产环境无差异的应用运行环境，同时对运行环境的访问需要进行权限控制和资源隔离。
◼ 在 CI/CD 之上为不同的环境创建对应的租户空间，并把相应的团队加入到可访问的租户空间中，实现不同租户空间的应用可见性权限控制。
◼ 把不同环境对应的主机添加到租户空间作为租户的专享资源，从而实现资源隔离。
◼ CI/CD 提供完善的应用部署和运维能力支持， 可以让团队快速看到应用运行效果。
3.3.6 持续部署
自动化是持续交付流程的关键， 也是提升软件交付速度和迭代频率的重要能力。通过在 CI/CD 上定义软件持续部署策略，能够实现应用更新和代码更新的联动， 可以极大的减少开发、 测试人员频繁更新环境的繁琐操作， 提升工作效率，鼓励团队持续迭代、稳步提升。
3.3.7 制品交付
针对金融行业的应用交付的特点，一部分是企业开发团队自研应用，一部分是由外包开发商开发。所以需要针对这两种交付模式设计交付流程。企业自研应用交付流程：通过代码交付的 DevOps 流程
图-制品交付流程
◼ 开发团队提交代码到代码仓库
◼ CICD 自动进行编译打包，并提交到镜像仓库
◼ CICD 根据发布规则，自动将镜像发布到预生产环境中
◼ 在预生产环境中通过验证以后，进行版本标记，将镜像发布到生产环境的镜像仓库。
◼ 手动将待发布的镜像，发布到生产环境。
应用开发商通过制品交付流程：
图-应用开发商制品交付流程
◼ 应用开发商直接提交代码到代码仓库
◼ 应用开发商提供应用安装包到代码仓库
◼ 应用开发商提供应用安装包到制品库，更新代码仓库的对应脚本文件
◼ 构建镜像，自动推送预生产环境
◼ 标记镜像，手动更新生产环境
3.3.8 合规性检查
容器平台及服务具体包括了身份鉴别、访问控制、安全审计、通信完整性、通信保密性、软件容错、资源控制和其他安全设计等。
身份鉴别
◼ 在身份识别上， 实现了与统一身份认证平台打通， 实现唯一识别身份的信息。
◼ 可以通过用户所在的组织、角色、姓名来人工识别该用户
◼ 系统提供了重复身份校验功能，新录入的用户、修改的用户都会判断是否存在重复编号。
◼ 在系统中，用户的会话保持在服务端，当用户登录成功时创建会话、登出时注销会话、当用户 15 分钟没有操作时，会话被自动注销。
◼ 系统设定了允许用户登录错误的次数(默认 5 次)，一旦用户连续输错密码导致登录失败，用户账号将被锁定 30 分钟无法登录。
◼ 用户登录时，在日志中会记载登录用户账号、登录端的 ip 地址，登录时间、以遍安全审计时追踪使用人。
◼ 用户密码根据统一认证平台设定，系统默认不少于 8 位，规则由数字和字母混合构成，帐户超过 3 个月不使用会被系统自动锁定，使用找回密码功能重新设定密码。
◼ 重新设置的密码不能与前 3 次设定的原密码相同
◼ 用户设定保存在服务端的密码采用 AES 对称加密算法安全加密
◼ 通过审查系统设计，并进行差距分析项后能够达到
◼ 为用户提供专用的登录控制模块对登录用户进行身份标识和鉴别;
◼ 为用户提供对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别;
◼ 为用户提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用;
◼ 为用户提供登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施;
◼ 为用户提供启用身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能， 并根据安全策略配置相关参数。进而通过以上安全机制设计 我们能够实现:
◼ 提供专用的登录控制模块对登录用户进行身份标识和鉴别;
◼ 提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用;
◼ 提供登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施;
◼ 启用身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能，并根据安全策略配置相关参数;
◼ 对口令长度、 复杂度和定期修改进行设定要求， 必须使用唯一一套帐号标识。
安全审计
容器平台以及服务安全审计设计如下:
◼ 系统保存用户访问日志，会记录用户的任何操作轨迹
◼ 日志有格式，会记录用户在某时候使用何种方式、使用那个 ip 地址登录 和注销，日志会记录登录用户在何时执行了什么操作，做到了操作 100% 覆盖。
◼ 系统所有日志定义了访问人员、一般用户无法触及，只用特定运营人员可以下载、但无法修改，具有不可抵赖性。
◼ 系统提供对审计记录数据进行统计、查询、分析及生成审计报表的功能通过对审核系统设计和审核系统日志设计，并进行差距分析项后能够达到:
◼ 应提供覆盖到每个用户的安全审计功能， 对应用系统重要安全事件进行审计;
◼ 应保证无法单独中断审计进程，无法删除、修改或覆盖审计记录;
◼ 审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等;
◼ 应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。
进而通过以上安全机制设计能够实现:
◼ 应提供覆盖到每个用户的安全审计功能， 对应用系统重要安全事件进行审计;
◼ 应保证无法删除、修改或覆盖审计记录;
◼ 审计记录的内容至少应包括事件日期、时间、发起者信息、类型、描述和结果等;
◼ 系统具备独立审计员角色，审计员可按时段导出审计记录，其他角色不能查看、导出审计记录。
通信完整性
容器平台以及服务通信完整性设计如下:
◼ 为保证通讯完整性， 数据在通讯前， 系统对通讯报文、 数据进行长度记录当数据抵达接受端时，接受端程序会对数据进行长度校验。
◼ 端和服务端程序会对必须数据字段进行非空校验。
通过对审核系统设计和审核系统安装部署设计， 并进行差距分析项后能够达到:采用密码技术保证通信过程中数据的完整性
进而通过以上安全机制设计能够实现:应采用校验码技术保证通信过程中数据的完整性;
通信保密性
容器平台以及服务通信保密性设计如下:
◼ 通讯采用 HTTPS 安全协议， 以保证数据在网络传输过程中即使被截取也 不会被破解。
◼ 敏感数据在传输前会被首先加密(AES 对称加密)， 数据到达目的地之后 才被解密使用。
通过审核系统设计和审核系统安装部署设计， 并进行差距分析项后能够达到:
◼ 在通信双方建立连接之前，应用系统应利用密码技术进行会话初始化验证;
◼ 应对通信过程中的整个报文或会话过程进行加密。
进而通过以上安全机制设计能够实现：
◼ 在通信双方建立连接之前，应用系统应利用密码技术进行会话初始化验证；
◼ 应对通信过程中的敏感信息字段进行加密。
其他
其他安全设计包括了安全手段、提*品、安全隐患、备份与恢复、部署及备份工作、系统管理建议等，其中系统管理建议又包括了数据存储安全设计、信息使用安全设计、 接口调用安全设计、 应用安全措施设计、 其他安全措施设计等。通过以上安全机制设计能够实现:
◼ 系统提供安全手段防止非授权用户的非法侵入、攻击
◼ 提供的产品(包括中间件)不能包含已被发现的漏洞
◼ 能够备份和恢复系统及数据，备份策略粒度可细化，并提供恢复验证的测试环境
◼ 提供本地用户登录时首次强制修改密码功能，登录失败后的解锁时间能进行定制
◼ 提供的所有系统日志能要求兼容 syslog 格式，在本地记录的同时可推送至 syslog 日志服务器
3.4 统一资源申请平台
平台提供用户全生命周期的自助服务功能，包括资源自助申请、审批状态自助查询，可视化部署过程自助查看、日常运维自助操作、资源变更自助申请、监控信息自助查询、自助续租或回收资源等。将用户自助服务从资源自动化交付延伸到资源的增删改查全生命周期，让用户真正体验全面的云服务，并减少管理员简单重复劳动。
3.4.1 自助资源申请服务
租户通过统一云服务目录申请各种多样化的测试资源，包括：
◼ 申请标准 IaaS 服务，至少包括：VM 虚拟机、云主机、安全组、弹性 IP、负载均衡、对象存储等；
◼ 申请自营 PaaS 软件服务，至少包括：Oracle、JDK、Tomcat 等；
◼ 申请容器应用部署服务，申请表单中选择容器镜像、容器规格、容器编排文件 Helm Chart，由云管理平台进行容器应用的自动化部署；
◼ 云资源使用过程中遇到问题，可提交事件、问题、变更等工单服务。
3.4.2 在线审批流程
提供云服务申请的在线审批流程
◼ 通过服务目录申请资源时，可租户和云管理员可遵循不同的审批流程。简单的云资源服务对管理员可以免审；
◼ 租户可以查看自己的审批进度和详情；
◼ 审批人可以修改申请参数，可驳回申请到上一级审批者或直接驳回给申请者；
◼ 当一个云服务包含跨技术服务团队的资源时，需进行多级审批，且不同技术团队可审批、可修改的内容根据其技术专业而有所不同。
3.4.3 自动化部署
通过服务目录申请的云资源服务，可由云管平台自动化部署：
◼ 提供可视化的自动化交付过程可，显示自动化交付进度，显示自动化交付过程详细日志；
◼ 当一个自动化执行过程包含多个云资源时，云管平台应支持获取运行态状态，自行决定多个资源执行的先后顺序和并行度，支持获取运行态数据进行多个资源间配置传参；
◼ 自动化交付过程出现异常时， 云管理平台应以明显图标警示， 并通知管理员。支持管理员解决问题后选择重新执行或从失败处继续执行；
◼ 支持自动化交付完成后将必要的配置信息、访问信息通过邮箱和短信通知申请者；
◼ 云资源自动化交付服务支持灵活的扩展，提供可视化的服务编排、配置服务申请表单、 对自动化参数设置默认值或开放给租户填写。可支持服务的发布、取消、复制服务。
3.4.4 自助运维
提供自助云资源运维功能， 租户可在云资源运维界面对自己所有的资源进行自助运维，包括：
◼ 云主机，支持启停、CPU 内存磁盘扩容、安装软件、堡垒机登录
◼ 弹性 IP，支持弹性 IP 支持绑定、解绑虚拟机
◼ 安全组，支持安全策略的添加、删除
◼ 负载均衡，支持增加节点、删除节点、修改轮询和健康检查策略
◼ 对象存储，支持创建文件夹、上传文件、删除文件
◼ Container 容器镜像，支持更新副本、增加副本、调整规格
◼ 部分涉及资源变更的运维操作，需要遵循审批流程
3.4.5 自助监控告警
提供自助监控告警功能，包括：
◼ 将租户自己的 IaaS、PaaS 资源的监控展现给用户，包括 VM、SLB、OSS、容器 Pod 等；
◼ 将租户自己的 IaaS、PaaS 资源的告警信息展现给用户。
3.4.6 租期回收
提供租期回收功能，包括：
◼ 云资源租期到期后将停止云资源服务，并放入回收站；
◼ 在保留期内（如一个月），租户可申请云管理员将云资源从回收站恢复；
◼ 回收站内资源过了保留期后，将被卸除（同时从云平台中删除）；
◼ 即将到期的资源应发送邮件或站内信息给租户；
◼ 租户可进行资源续租。
3.5 容器统一规范
3.5.1 容器内应用的健康检测
在集群中，可以通过健康检查探针来检查容器的就绪或存活状态，以在集群层面保证业务容器的可用性，集群的健康检查探针的类型：
◼ 存活检查(liveness probe， 存活探针)：使用此探针确认何时重启容器， 当程序处于运行状态但无法正常提供对外服务时，可以通过此探针捕获到这种异常，重启该状态下的容器
◼ 就绪检查（readiness probe，就绪探针）：使用此探针来确认容器是否已经启动完成，已经可以正常对外提供服务，如果 Pod 处于非就绪状态，Pod不会被添加到 Service 的 iptables 转发规则中， 流量不会转发到未就绪状态的 Pod；只有当 Pod 已经就绪， 相应 Pod 才会被添加到 Service 的 iptables转发规则中
3.5.2 应用容器的 DNS 配置
可以在 Pod 级别来设置 DNS，主要涉及到两个配置项“dnsPolicy”和“dnsConfig”，其中：
dnsPolicy 的类型有:
◼ Default：Pod 中 DNS 的配置会使用宿主机上/etc/resolv.conf 中的配置
◼ ClusterFirst （如果Pod没有明确指定dnsPolicy的配置， 默认为此种类型） ：Pod 中的 DNS 配置会使用 10.96.0.2，即 Kube-DNS/Core-DNS 的配置，对于集群 domain 前缀会进行解析， 非集群 domain 前缀转发给 Kube-DNS Pod 所在的宿主机/etc/resolv.conf 中配置的 nameserver 进行解析查询
◼ ClusterFirstWithHostNet：对于使用 hostNetwork 网络的 Pod， 默认会使用宿主机的/etc/resolv.conf 配置，为了在 hostNetwork 模式下也能使用Kube-DNS/Core-DNS，可以使用此种类型
◼ None：清空 Pod 内/etc/resolv.conf 的配置，一般结合 dnsConfig 来做一些自 定义 DNS 的配置dnsConfig 的相关配置条目：
◼ nameservers：指定/etc/resolv.conf 中的 namserver 条目配置
◼ searches：指定/etc/resolv.conf 中的 search 条目配置
◼ options：指定/etc/resolv.conf 中的 options 条目配置
3.5.2.1 使用集群内部的 DNS 服务
如下“ClusterFirst”的 dnsPolicy 可以不指定，默认即使用此策略
3.5.2.2 使用集群外部的 DNS 服务
在 Pod 中可以使用集群外部的 DNS 服务器，这样无需在集群内部 DNS 上 配置转发器，即可直接在 Pod 内解析外部域名
3.5.3 应用容器的应用配置管理
在集群中部署的应用，切忌不要把配置文件打入到应用镜像内，可以利用平台来统一管理应用的配置文件
3.5.3.1 通过集群管理应用配置文件
ConfigMap 可以通过如下两种方式提供给容器使用：
◼ 生成为容器内的环境变量
◼ 以 volume 的形式挂载为容器内部的文件或目录
1. 通过环境变量方式使用应用配置
创建简单的字面格式 literal 类型 Configmap
创建 file 类型的 ConfigMap
在应用的编排文件中，可以通过环境变量方式进行引用
2. 通过 Volume 挂载方式使用应用配置
通过环境变量的方式把 configmap 注入到容器后，只有容器重启，configmap 内的内容才会被更新；通过 volume 的方式挂载， 在更新 configmap 后，容器内的配置文件需要一定时间后才能更新。
3. subPath 挂载
默认情况下，configMap 的 mountPath 所在的路径下如果有文件，其会被隐藏不进行显示，如果只想把单个文件挂载到指定的目录下，可以使用subPath 的属性，其不会影响挂载目录下的其他文件
3.5.3.2 通过外置配置中心管理配置文件
如果使用外置的配置中心，只需要在应用的编排文件中，指定外置配置中心的地址及 Profile 相关环境变量即可
3.5.3.3 应用配置文件的热加载
默认情况下， Spring Boot/Cloud 的微服务如果使用 ConfigMap 来加载配置文件， 其无法实现配置热加载， 可以通过 Spring Cloud Kubernetes （Fabric8团队提供， 从 0.1.3 开始支持） 框架来支持在微服务运行时动态加载 Kubernetes ConfigMap 配置文件,pom.xml 文件中配置 GAV：
为应用创建 bootstrap.properties 文件， 使用上面创建的名为 app-config的 Configmap
3.5.4 应用容器的日志配置
3.5.4.1 容器的应用日志输出
在集群中部署的应用，可以根据日志输出的能力，通过如下两种方式来把日志输出到标准输出上
◼ 对于可以输出到标准输出上的应用，通过 log4j 直接把应用的日志输出到容器的标准输出上，这样可以通过 kubectl logs 进行日志查看
◼ 如果无法将日志输出到标准输出上的应用，可以通过 hostPath 的 Volume方式直接把宿主机上的统一日志存放目录挂载到容器中（推荐方式）
◼ 如果无法将日志输出到标准输出上的应用，另外一种处理方式，可以通过sidecar容器的方式来输出应用容器的日志。这需要在 Pod 内创建相应的卷，以在应用容器和 sidecar 容器之间共享日志文件，然后通过 sidecar 容器来把日志输出到标准输出上。此种方式的优点是日志文件的输出路径和日志格式比较统一，但 sidecar 容器会增加维护成本
1. 应用本身可以把日志输出到标准输出
下面是把应用的日志通过 log4j 输出到容器控制台上配置文件示例
下面是把应用的日志通过 logback 输出到容器控制台上配置文件示例
2. 应用无法把日志输出到标准输出
如果应用无法把日志输出到标准输出上， 可以把日志统一输出到宿主机的指定日志存放目录（例如：/logs/current/appName）
如果应用无法把日志输出到标准输出上， 也可以通过 sidecar 容器来进行日志输出
集群默认把 Pod 中所有容器的日志保存在了/var/log/containers 路径下，文件名采用“Pod 名_命名空间名_容器名”的格式，之后这部分日志可以统一通过相应的日志 Agent 搜集过滤，发送给日志存储和处理的后端。
3.5.4.2 应用日志规范
应用日志输出格式参考：
相关字段的描述：
记录路径：对于无法把日志输出到控制台上的应用，日志记录在 PaaS 平台所部署的宿主机上，不同应用通过路径来区分，应用日志记录路径如下规则（以某系统 appabc 为例）
当前应用日志：/logs/current/appName-(容器ID).log.crn， 日志大小50M，超过 50M 日志进行切换
日志切换重命名规则：在原日志的文件名称中增加切换时间戳， 示例：/logs/current/appName-(容器 ID)-MMddHHmmss.log
3.5.5 集群资源管理规范
3.5.5.1 应用容器的资源配置
在集群中， CPU 是可压缩资源， 内存是不可压缩资源， 这些资源可以被分为两种不同的状态，即期望状态（请求的资源）和当前状态（已使用的资源），根据这两种状态来评估节点的容量， 根据相应的资源需求来调度 Pod， 上面的两种状态在集群中通过如下两个参数配置：
◼ request：容器请求的资源， 如果容器使用超过其请求的资源， 会尽量把其限制在请求值内
◼ limit：容器可以使用的资源最大值，如果容器使用超过其限制的资源，会终止容器，相应的副本控制器会重启启动一个容器实例
◼ 注：如果容器仅指定了 limit，而没有指定 request，表明两者相同
◼ 根据 Pod 容器在 Resource 中配置的 request 和 limit 值来定义 Pod 的QoS 类型，对于每一种 Resource 都可以将容器分为 3 种 QoS Classes：
◼ Guaranteed：如果 Pod 中所有容器的 Resource 定义中的 limit 和 request都相等且不为 0，则这个 Pod 的 QoS 就为 Guaranteed
◼ Burstable：如果 Pod 中所有容器的 Resource 定义中 request 值小于 limit的值，则这个 Pod 的 QoS 就为 Burstable。如果容器的 Request 中资源申请的越多，在因资源不足发生驱逐时，其被驱逐的概率越小
◼ BestEffort：除如上两种类型外，其他的 Pod QoS Class 都是 BestEffort，即 Pod 里面的所有容器都没有设置任何 request 和 limit 值，当 limit 值未指定时，其有效值 为 Node 的容量值
当宿主机资源不足时，则会对 Pod 进行驱逐，其会优先回收 BestEffort 类型，其次是 Butstable，最后是 Guaranteed。所以，对于一些关键的应用（例如：网关，数据库等相关应用），尽量保证让其 request 和 limit 值保持相应，即为 QoS 的 Guaranteed 类型。其他非关键类应用，可以根据需要设置为Burstable 或 BestEffort 类型
Guaranteed 类型资源配置示例
Burstable 类型资源配置示例
BestEffort 类型，在资源定义文件中不指定 resources 的配置即是此种类型
3.5.5.2 集群资源限制和 JVM 的内存分配
在 JDK 1.8 中，JAVA 应用实际占用的物理内存主要包括：堆内存，MetaSpace，非堆内存（线程栈 ，buffers，所有的 jars 的库，JVM 虚拟机代码本身）
◼ 堆内存：主要用于存储类实例或对象
◼ 线程栈：每个线程都有其自身的调用栈，这些 stack 中除了调用栈本身（方法调用列表）外，还存储了原始的本地变量和对象引用，当 stack frames 从上下文移除时，栈会被自动清理，所以这里不会执行 GC
◼ Metaspace：存储了相应对象的类定义以及其他一些元数据信息
◼ Code cache：JIT 编译器会把原生代码存储在 code cache 中以进行重用，来提高性能
◼ Buffer pools：许多 libraries 和 frameworks 在堆外分配 buffers 来提高性能，这些 buffer pools 可以被用于在 Java code 和原生 code 之间进行内存共享，或 者把文件 cache 在内存中
注意，在 Java 中并不是分配越大的堆内存越好，JAVA JVM 会定期对堆内内存进行回收， 在某些特定的时间点， 它会进行一次彻底的 Full GC， Full GC 时，GC 回收器会对分配的对内存进行完整的扫描，这也意味着，Full GC 对 Java 应用的影响和堆内存大小成正比，在 Full GC 过程中应用会被暂停，过大的堆会影响 Java 程序的性能。部署在平台的应用需要根据实际的性能测试数据来合理的进行堆内存分配，非堆内存及 GC 算法及相关参数的配置
在 Java JVM 中，初始堆内存大小通过”-Xms”来设置，最大堆内存通过“-Xmx”来设置，对于运行在集群中的应用，建议把堆内存的最大值和最小值都设置为 request 和 limit 内存值的 80%。
同时，在容器内部，我们可以通过 Downward API 来获取容器设置的request 和 limit 内存值，来动态分配 JAVA 应用的堆内存。
3.5.5.3 租户的资源管理规范
集群在租户级别提供了资源配额管理功能， 可以对当前租户所能使用集群的计算，存储，网络和集群对象资源进行配额限制。
可以根据需要，对当前租户可以使用的集群资源进行限：
3.5.6 投产审核
图-投产审批服务流程平台
服务流程平台是银行服务流程的管理中心， 基于服务流程平台实现投产审批过程的管理， 通过流程规划与建设， 明确流程管理责任， 为投产审批流程的管理、监督、考核和优化提供依据，从而达到企业运行有序、提高效率。
3.5.6.1 配置信息
服务流程平台中部署 CMDB 模块，记录数据中心的应用信息，物理服务器信息、IP 等逻辑信息。监控等系统，将通过 IP 信息从 CMDB 中获得应用等相关信息后进行展现。
容器平台项目上线时，需要在服务流程平台手工录入应用信息，服务信息。针对容器弹性伸缩的特性，未来考虑自动导入 IP 等信息。
3.5.6.2 流程审批
为了更好的驱动基于容器的应用/服务的上线、变更、部署以及应用监控，容器平台需要与行方服务流程平台进行对接，主要实现如下功能：
◼ 权限申请：接入容器平台的用户有高权、低权分，对高权限的用户需向流程管理平台提交申请，审批通过方可接入。
◼ 流程审批：系统内部变更、系统上线，需要通过服务流程平台进行审批。
3.5.7 自动化运维
3.5.7.1 运维范围与目标
❑ 一类运维对象是基础设施部分。指为保障数据中心所管理 IT 设备正常运行所必需的风火水电资源、环境资源等。
❑ 第二类运维对象是在提供 IT 服务过程中所应用的各种 IT 设备，包括计算、存储、容器、服务器、网络、安全等资源。
❑ 第三类运维对象是资产、系统、数据和安全，包括各类 IT 资产和终端、操作系统、数据库、中间件、应用程序等软件资源;还有业务数据、配置文件、日志等各类数据。
❑ 第四类运维对象是管理工具，包括了基础设施监控软件、IT 监控软件、工作流管理平台、报表平台、短信平台等。
❑ 第五类运维对象是资产和人员，包括了数据中心的技术人员、IT 运维人员、管理人员以及提供服务的厂商人员。
3.5.7.2 运维设计原则
1. 统一管理平台
融合 DevOps 理念潜心研发基于 ITIL 的企业级业务服务管理平台。它针对企业的 IT 支持和管理部门，基于 ITIL（IT Infrastructure Library）的 IT 服务管理思想， 整合了业务监控、 系统监控、 应用监控、 网络监控、 可视化监控 （VM） 、工作流、ITIL 式报表和门户等多种技术手段，帮助银行用户解决 IT 支持与管理过程中的难题，提高 IT 服务水平和工作效率的解决方案。
建议有以下功能模块：
业务流监控
流量监控
主机监控
网络监控
存储架构管理
虚拟化架构管理
响应时间管理
应用系统监控
日志监控
业务服务管理
报告报表管理
多方式告警通知
基于 B/S 架构，前后端业务分离，通过 Portal 的统一展现，对业务流程、基础架构和应用系统进行全面监控，提供面向服务的端到端应用性能管理，不断改善用户体验；遵循 ITIL 流程框架，建立业务服务管理；通过有效的报告报表分析，使用户能够动态可视的了解到 IT 基础架构与业务服务之间的变化关系，最终进行帮助企业实现 IT 系统的持续优化和长期规划。
2. 管理体系开放性
管理系统符合业界标准，基于开放的管理平台，遵循业界标准，并提供管理接口以实现对各种资源的统一管理和与其它管理软件的集成。
支持某些第三方厂商的应用集成，为系统管理的选型提供更高的灵活性
开放的 Portal API 支持用户应用软件的界面集成，为系统管理的内容扩充提供发展余地
3. 管理系统安全性
管理系统自身的安全性是保证管理工作正常进行的关键因素，需充分考虑了管理系统的安全性，包括：
登录失败次数限制
管理信息在各个组件之间传输时必须通过加密
提供完整的策略和框架，并能适应组织的变化，灵活地设定管理人员的角色及权限
对用户名、密码等关键信息密文保存。
具有用户登录时间限制等等。
4. 结构化和扩展性
管理规模会随着应用的不断扩展而扩展，因此管理平台的扩展性对保护投资有重要意义。扩展性主要体现在：
管理功能的扩展，本次针对网络设备和主机的管理，以后可在统一平台上扩展应用，数据库，业务服务等管理。
管理范围的扩展，可实现多分支的加入扩展，支持分部式管理。
系统具备具有优秀的功能扩展性，可以在需要时增加管理模块，扩展管理节点，保护现有投资。
全业务 RESTful API 支持，Https+Json+XML
5. 模块化结构和扩展性
管理规模会随着应用的不断扩展而扩展，因此管理平台的扩展性对保护投资有重要意义。扩展性主要体现在：
管理功能的扩展，本方案可随客户业务、应用、网络设备和主机等资源的发展而动态扩展，实时满足客户管理需求。
管理范围的扩展，可实现多分支的加入扩展，支持分布式部署管理，保持业务管理的弹性。
系统具备具有优秀的功能扩展性，可以在需要时增加管理模块，扩展管理节点，保护现有投资。
6. B/S 架构，使用与维护简单
系统全部为 B/S 架构，界面统一，使用门槛低，容易上手且维护简单，可以大大提高系统管理员的工作效率，降低维护工作量。
7. 友好的用户界面，简单易用
系统界面动态美观，例如支持 FLASH 等展现技术等。全中文管理界面，降低管理门槛。
3.5.7.3 自动化运维体系建设
1. 云环境对运维监控需求
架构转型后，应用与基础设施松耦合，对“人”、“工具”、“流程”提出新的挑战。需要针对银行已有的数据中心运维运营体系打造新的运营运维体系，向专业化、服务化运营提供*保障。通过转型后的运维运营体系保证云环境下后续运行过程中的运维安全稳定、成本预算可控、资源服务供给高效，对管控流程、服务规范、供给模式以及组织结构提出新的需求。
图-自动化运维需求
2. 运维框架规划
云运维服务目录体系
基于云、微服务基础架构，将银行数据中心对外及内部提供的能力进行服务化设计，明确 SLA，角色职责，输入输出及流程，形成服务目录。有了明确的服务目录才能更好的进行标准、规范流程和工具，更好的制定服务的考核指标，其中蓝色部分为需要建立的服务目录体系以及需要强化的服务能力。
图-云运维服务目录
云运营规划
图-云运营服务目录
− 底层资源通过统一标准化 API 接口形成产品，对外提*品服务；
− 提供租户身份认证、权限控制、操作审计、订单账单计费管理；
− 集团账户、子账号、项目管理体系多种组织结构；
− 管理各个子公司、部门的云资源的成本和预算；
− 灵活计费方式满足分支机构或部门多种计费场景；
− 提 API 接口管理，提高新产品接入效率，增加云平台迭代敏捷性。
本系统为采用新产品所建设的系统，系统围绕运维的各个业务场景，以功能模块的形式实现运维自动化，包括了传统的运维和虚拟化运维。系统建设完成后将实现与应用系统及其周边系统的全面联动，通过获取现有CMDB 的应用和系统配置，自动化运维平台加以运用和消费，通过各个功能模块，实现对运维日常工作的自动化，并实时或定时将执行过程和结果传输到周边系统，供周边系统分析或加工。
运维自动化平台与应用系统的交互主要通过 agent 代理实现，包括对应用系统的巡检、应用的发布等；与周边系统的交互主要通过 API 或 JSON的方式实现，完成监控、报警的联动处置。
总体架构如下图所示：
3.5.7.4 运维技术栈关键设计
1. 集中化任务调度管理
集中化调度管理要求自动化运维管理平台能够全面覆盖现有各个应用系统，能够支持不同开发环境(windows,Linux 和 Unix)，多种程序语言所开发的自动化任务（如：JAVA，C，perl， shell，windows 图形界面操作等） ， 能够稳定安全地实现任务集中定义， 集中展现， 集中调度， 集中监控，集中事件管理、集中日志管理、集中用户管理等功能，减少任务执行的等待时间和资源消耗。
2. 自动化任务调度管理
自动化任务调度管理要求管理平台能够实现自动化任务自动化调度执行，健康检查，监控预警、容错处理，且支持人工干预等。
3. 标准化任务调度管理
标准化任务调度管理要求管理平台支持自动化任务调度接口、流程、配置、响应信息、命名等规则的标准规范及定义配置，保证存量及增量系统的自动化任务标准化接入和扩展，降低自动化任务整合的复杂度。
4. 高可用模块化调度管理
高可用模块化调度管理要求管理平台具备高可用性、负载均衡等功能，支持平台调整模块资源分配。
5. 性能压力及实现要求
1) 自动化的关键功能是批量下发指令并实时返回，平台同时支持最少1000 台主机的并发执行，并通过异步方式快速返回每台主机的执行结果，大批量并发时对服务器 cpu 会存在一定的压力。
2) 应用系统管理运维自动化平台与受管设备之间通讯带宽主要用于脚本和软件安装介质分发。其中脚本的大小一般不会超过 10KB，假设同时在 500 台设备上执行， 则从应用系统管理运维自动化平台流出的网络流量约为 5MB， 基本不会对网络造成压力。而软件安装介质的大小可能有几百 MB 甚至几个 GB，为避免对网络造成压力，可通过如下手段予以
控制：
❑ 由于软件安装介质的下发采用 FTP 方式，应用系统管理运维自动化平台可在应用层面对 FTP 传输带宽进行限制；
❑ 业务网段、 第三方 DMZ 和办公网段受管设备下发软件安装介质时会首先由核心应用节点向该网络区域内的代理节点传输介质，并由该代理节点缓存后再分别下发至同网络区域内的各受管设备，从而有效减少穿过防火墙的网络流量；
❑ 通过应用系统管理运维自动化平台的任务调度，尽量避免软件介质安装的并发设备数量，并考虑将软件安装部署任务安排在非工作时段执行。
6. 安全控制和要求
数据安全性：运维自动化管理平台的业务数据在物理部署上是安全的，使用我行统一存储和备份平台，提供安全的数据存储、备份环境。
网络安全性：自动化运维管理平台中各组件之间以及服务器自动化组件与受管服务器上代理之间的所有数据传输都使用 SSL 双向加密， 管理用户和操作用户必须通过 ECC 业务网段终端通过 HTTPS 协议访问本系统管理门户，办公网段仅展示只读的报表数据（巡检结果等信息）以供办公环境的查询用户访问。
应用安全性：用户登录管理门户时支持通过业务域 AD 认证，还将实现用户登录时的业务 AD 认证。管理门户中的所有本地应用账号都会被运维账号统一管理系统纳管，用户使用本地应用账号时必须通过运维账号统一管理系统。
3.6 高可用架构体系
3.6.1 方案概述
通过主备数据中心对单体应用备份和多活应用双数据中心部署的方式， 结合应用数据外置挂载和主备数据中心三层网络可达的部署，保障 IaaS 平台应用在某数据中心发生灾难时，应用服务可以在短暂时间内迅速恢复。平台本身实现主备，并可支撑应用双活、冷备部署，满足企业级业务建模的规划和需求。
3.6.2 高可用部署方案
图-高可用部署
容器平台提供多层次高可用性设计，不存在单点故障，保证业务的安全和稳定性：
3.6.2.1 容器的故障恢复
当服务器宕机时， 平台系统会自动在其它服务器上重新启动容器并为其分配资源，从而达到秒级启动，恢复业务。保障业务不掉线，高可用运行。
3.6.2.2 镜像仓库的可用性
通过将单机版的镜像仓库扩展成镜像仓库集群，并在 Registry server pool 中实现负载均衡， 从而提升性能， 并充分强化了镜像仓库的可用性。实现 Registry server 的无状态化，便于实现服务的高可用性。
图-镜像仓库高可用
3.6.2.3 容器的可用性
确保运行在容器中的应用程序和其他容器中的应用程序是完全隔离的， 在通信流量和管理上赋予完全的控制权。可以使用的 Docker 镜像都通过数字签名来确保其可用性，并且资源是受限制的，所以即便其中一个应用程序被黑，也不会影响运行在其它 Docker 容器上的应用程序。
3.6.2.4 集群管理主机的可用性
为了提高 Kubernetes 集群的可用性， 平台会针对每个主机节点创建一个守护线程，通过守护线程定时的去探测主机节点的可用性，当发现主机节点进程失效后， 系统会将该主机节点置为不可用状态， 必要时， 可以重新按照原有的配置，自动重启并重新构建主机节点进程。
图-集群管理主机高可用
系统设计能够跨地域跨数据中心部署云服务， 具备数据中心级别的高可用性。
图-容器平台集群高可用
基于以上高可用性设计，容器平台应可以为用户提供长时间不中断的、可用的服务：
◼ 系统可用度：不低于 99.999%；
◼ 采用集群或双机冗余设计，不存在单点故障；
◼ 应用的可用性，确保运行在容器中的应用程序和其他容器中的应用程序是完全隔离的。当服务器宕机时，平台系统会自动在其它服务器上重新启动容器并为其分配资源，保障业务不掉线，高可靠运行。基于多容器实例负载均衡和弹性伸缩等功能保障该平台上运行应用的容器可用性不低于 99.999%；
◼ 镜像仓库的可用性，镜像仓库以集群的形式提供服务，便于实现服务的高可用性。镜像仓库的可用度不低于 99.999%。
◼ 集群管理主机的可用性,能够提供集群管理主机的可用性方案， 保证集群管理服务不掉线。
3.6.2.5 平台组件备份设计
容器平台提供完善的备份能力，包括但不限于节点配置信息或文件、元数据库备份、服务注册组件、证书、应用镜像仓库、代码库、数据库备份、关键表备份、特殊时点备份、操作系统备份、应用及中间件备份、配置文件备份、日志备份等。
使用容器平台推荐的备份方案所备份出的数据具备数据完整性， 也就是说在整个集群完全故障不可用的情况下，可以通过备份数据完整的恢复集群， 并和备份时点的状态一致，包括平台组件状态、业务应用状态、源代码状态等。
1）备份数据完整性：
容器平台完整的备份如下数据
◼ 系统的各种类型的证书。
◼ Etcd 中存储的所有应用的元数据 （服务注册、 应用配置、 环境配置等） 。
◼ Master 和 Node 的配置文件。
◼ 镜像
◼ 源代码
2）备份方案如下，可以通过 Ansible 配置成定时任务：
恢复方案如下：
3.6.3 总体设计
图-总体设计
3.6.3.1 平台部署
3.6.3.2 部署架构说明
主机房 A：在内网区部署容器管理平台 portal （主） ， 对接机房数据库 （主） ，纳管主机房 A 内网区 K8S 集群、备机房 B 内网区 K8S 集群。
备机房 B：在内网区部署容器管理平台 portal （备） ， 对接机房数据库 （备） ，纳管备机房 B 内网区 K8S 集群。
应用通过主 portal 在主备机房同时发布，不需要灾备的应用正常只会通过主 portal 在主机房发布。
3.6.3.3 负载均衡设计
跨数据中心负载均衡，一般依靠 DNS 智能解析在数据中心之间实现流量负载与冗余。DNS 智能解析的思路是在 DNS 服务器中动态维持几个后台数据中心的出口 IP 地址，针对用户请求按照算法返回最适合的出口 IP。如果其中一个数据中心出口出现问题，DNS 服务器便将其对应的 IP 地址暂停使用，并将后续的用户 DNS 请求引导到其他仍在正常工作的数据中心出口，从在广域网上实现后台资源的负载均衡。
内部负载均衡建议使用平台配置的软件负载均衡器支持。
主备方案情况下：负载均衡器会配置为日常所有请求都调度到主数据中心，只有主数据中心异常，无法提供服务时，才会调度到备用数据中心。
互联网进入的访问流量，在主数据中心整体故障后，流量进入 DMZ 及防火墙等网络后，无论从主数据中心或者备数据中心进入的流量由 DNS 处理后进入备数据中心的云互联/外联网络 F5 负载，根据应用部署架构进入相应的 Web 服务器，再进入内网的应用服务。
内网进入的访问流量，由 DNS 处理后，仅备数据中心内网可进行灾备内网的应用的访问，访问流量进入备数据中心的灾备内网 F5 负载，根据应用部署架构进入相应的 Web 服务器和应用服务器。
本方案推荐采用 F5 或其它的具备 GTM 功能的负载均衡能力，若无，则人为手动去 dns 切换。
3.6.3.4 切换架构
正常情况下通过 DNS 域名访问主 portal 进行平台操作，主数据中心 A 机房出现故障后：
◼ DNS 把流量切到 B 机房备用 portal、备 DB
◼ DNS 也切换到备用镜像仓库。
3.6.4 灾备实现
灾备设计方案主要考虑数据级备份、应用级备份和网络切换。本方案数据层面跟进数据类型，采用主备方式，建议采用内部现有机制，保障数据一致性；应用层根据应用类型和灾备需求，使应用具有多活和冷备的能力，保障应用服务可用性和连续性；网络流量的切割依赖负载均衡 DNS 方案，保障访问流量的自动切割。
3.6.4.1 数据备份
根据采用数据库的类型，设计不同的数据层容灾备份方案。数据库层在一侧数据中心访问，另一侧的数据中心的数据库作为备用数据库，基于数据库的备份技术进行异步复制备份。
数据备份方案如下：
3.6.4.2 应用层备份
主要完成多数据中心的应用同步部署、主备方式的应用服务提供工作。其中应用服务提供主要由应用层保障。对多活/主备方式来说，在应用层的方案都是一致的。
容器云架构下：基于 Docker 容器， 建议通过 “多集群应用统一管理” 方式，实现多数据中心的统一应用部署和应用的灵活漂移。用户通过统一的多集群应用管理入口创建应用，平台将应用拆分到各个集群分别部署。同时，平台会维护统一维护各个应用/服务在各个集群的健康状态、监控负载情况。多集群服务统一管理页面如下：
图-集群服务统一管理页面
图-集群管理页面
根据新环境建设规划，以及容器平台设计的数据情况，采用合适的数据备份方案，具体如下：
冷备应用实现说明：
◼ 当多集群发布后在两个集群标记好主和备，主应用正常运行，备应用副本数自动为 0，及关闭状态。
◼ 备应用通过定时任务每隔 1 小时定期扫描主应用状态， 当发现主应用异常时，备应用自动启动容器。
◼ 建议采用双活 NAS，若无，则只能通过脚本设置同步规则，定时同步相应数据。
3.6.4.3 平台灾备说明
◼ 容器平台 Portal 的故障对容器平台发布的应用无任何影响，因此恢复优先级较低；
◼ 备数据中心启用后，不建议在备容器平台上进行应用创建和发布等操作，仅作为发布应用的状态查看等读操作，一方面减少容器平台 Portal 的数据差异，减少回切工作，另一方面主要考虑此时无法对已经故障主数据中心中 Kubernetes 集群进行应用创建及发布，应用只能在主数据中心故障恢复后通过平台进行重新发布。
3.6.4.4 回切场景
主数据中心恢复后，通过完成以下场景的回切主 portal：
4 方案价值
容器技术之所以能够快速崛起，发展成为云计算领域最热门的技术，最大的法宝就是它标准化了云的交付件。过去，应用软件的存在形式是一个大而全的整体，而在容器的世界里，应用软件是根据业务逻辑切分成不同的模块，然后封装成容器的形式存在。
图-应用的标准交付件
这是一个 IT 方法论的变革， 它将应用软件生产和运维的方式标准化和模块化，而标准化和模块化往往意味着高效。无论是在软件交付之前的研发过程，还是软件交付之后的运维管理过程， 标准化的交付件为企业带来的价值是非常巨大的。也正是因此，有人认为容器技术开启了应用软件的工业 4.0 时代。
如果把企业 IT 划分为两个阶段——应用交付前和交付后， 那么， 容器给企业 IT 转型带来的能力主要体现在两个方面：交付前的快速交付和持续创新能力，以及交付后的高效管理和运维能力。
4.1 IT 交付新能力
IT 交付新能力-持续交付和持续创新
在互联网+金融的趋势下，金融 IT 变革的一个最大的挑战就是如何实现快速迭代， 从而快速响应用户需求， 这也是衡量一个企业互联网化的最重要的指标。然而， 传统的软件开发模式已经成为企业产品迭代速度的瓶颈。传统开发模式中，开发、测试、运维人员被分割成独立的阶段，每个阶段分别交付不同的内容，开发人员交付代码、测试人员交付测试包，运维人员部署运行环境，在这样的协作方式下， 软件迭代达到了极限， 已经无法满足互联网+趋势对于快速迭代的需求。并且， 由于开发测试环境和生产环境不一致， 无法进行统一管理， 存在安全隐患。
Docker 的出现打破了传统软件交付模式的桎梏， 为快速迭代带来了全新的思路。Docker 容器技术统一了云的交付件，无论是开发、测试、还是运维人员都交付容器镜像，并且都基于镜像仓库进行协作。交付前开发人员需要完成迭代和移交镜像和镜像构建的过程，交付后运维团队负责镜像容器的编排和运行。这样就让整个开发过程做到了统一，容器成为了应用交互的一个标准交付件。这不仅大大可以提升软件交付和迭代效率，还能避免交付内容不同导致的人为错误。
4.2 IT 架构新能力
IT 架构新能力-混合云+微服务架构
在烟囱式 IT 架构向混合云架构的转型过程中，有两个关键点：一方面，应用架构由大而全的整体架构向灵活的微服务架构转变；另一方面，计算资源由专用计算资源向分布式架构转变。
以 Docker 为代表的容器技术的出现，为烟囱式 IT 架构向混合云架构转型提供了堪称完美的解决方案。首先，Docker 为微服务架构的实现注入了新的活力。微服务架构本身非常多样化，切分完成后，每个模块都可以由不同的团队来维护，也可以用不同的编程语言来编写，这会加大系统运维的难度。但是Docker 容器将这些模块封装成统一的容器镜像， 这使得平台的自动化运维变得简单。同时，应用以容器镜像的形式存在以后，可以非常容易地进行大规模分布式系统的部署和运维， 为计算资源由过去专用资源向分布式架构转型提供了基础。
4.3 IT 运维新能力
IT 运维新能量-高效运维
高可用性是金融行业 IT 运维的一个永恒的话题。在互联网+金融的趋势下，用户体验至关重要，其中一个非常重要的指标就是服务的高可用性。如何实现复杂 IT 环境下的高可用性是互联网+金融趋势下金融 IT 变革的又一个重大课题。互联网 IT 运维的核心观点是——任何一个 IT 系统都有可能是不可靠的，因此， 运维的关键就变成如何从分布式系统的管理软件层面去确保系统的连续性和高可用性。容器的轻量级特性和秒级启动能力为金融 IT 的运维带来了新的思路。由于容器本身非常轻量级，具有秒级启动的能力，因此，在分布式系统中的任意一个容器出现问题，可以立即秒级启动另一个容器，从而确保整个系统的连续性和高可用性。
本文是2021容器云职业技能大赛团队赛的亚军作品，作者：杨梦伦 中国银行工程师；刘艳春 中银金融商务架构师；刘中梅 中国银行软件工程师