随着容器技术不断发展和落地推行，越来越多部门的数字化业务选择运行在容器中。在业务容器化向微服务架构转变的过程中，巨大的单体应用被分解为多个服务，单体应用的复杂性也随之分解。在此基础上，每个微服务都可以独立地部署和扩展，敏捷开发、快速迭代和快速部署得以实现。

但任何事情都有两面性。虽然微服务给我们带来了很多便利，但是由于应用被拆分成了多个组件，服务数量大幅度增加。每个组件又有自己的资源文件，并且可以独立地部署与伸缩，这给Kubernetes做应用编排带来了诸多挑战，如：

Kubernetes架构图如下：

Kubernetes提供声明式的API，可以对标准对象进行生命周期管理，比如Pod、Service、Deployment和ConfigMap等。基于这些原子能力，开发人员和运维人员可以自由组合各种k8s对象，以Yaml、Json等格式文件进行自定义，用于构建自己的业务应用。

随着应用自身复杂性的不断增加，依赖条件逐渐变多，部署环境的更加复杂多样后，这种原始的声明式API使用方式显得不够灵活且相对低效；此外，应用和声明式API之间缺少一个构建标准，不利于应用的共享、分发、以及应用市场的健康发展。为提高系统部署中对组件编排的灵活性和应用市场的健康发展，Helm和Operator应运而生，在Kubernetes声明式API的基础支上，进行了一层抽象和封装，成为解决这种困境的两个主要方案。

Helm是基于Kubernetes的应用包管理工具，主要用来管理Charts。可实现对应用程序的封装、应用分发、依赖检查、版本管理，对容器应用所需资源组件进行集中管理，并通过模板化和配置分离提高声明式API的开发效率和使用效率。Chart包则是应用的载体，实现了应用的分发和共享。Helm执行流程如下图：

对于应用发布者而言，创建Helm Charts 有如下好处：

Kubernetes Operator是一种封装、部署和管理 Kubernetes 应用的方法， 可扩展Kubernetes API 的功能，能为Kubernetes 用户自动创建、配置和管理复杂应用的实例，减少了用户的手工输入。

Operator主要包含CRD和Controller两个部分：CRD是在Kubernetes的标准对象之上构建一层直接面向应用的扩展对象，例如Mysql；Operator提供InnoDBCluster和MySQLBackup这两个扩展对象。Controller是指自定义控制器，以Deployment的形式在Kubernetes中运行，监听CRD的配置变化，并转换成标准对象进行实现。

Controller能灵活实现应用生命周期管理能力以及运维能力，是Site Reliability Engineering (SRE)思想在容器集群领域的一个落地实践。

Helm和Operator的比较：

Operator 本质上是针对特定的场景去做有状态服务，或者针对拥有复杂应用的应用场景去简化其运维管理的工具。Helm 则是一个更为普适的工具，更常用在配置分离；Operator 则是针对复杂应用的自动化管理。

CNCF 云原生计算基金会在 Kubernetes 2018 应用调查中将Helm 评为最常用的 Kubernetes 应用管理工具。目前，基于Helm资源模板化配置分离的设计理念，支持全生命周期的编排能力，修改Yaml配置高度灵活、易于部署等特点，德邦证券科技条线的多个项目已采用Helm方式的容器化部署。包括捷豹、信豹、灵豹、融资管理平台等系统，比如捷豹系统的容器化部署时，考虑到该系统子系统较多，配置文件复杂且需复用等特点，在部署时采用Helm的方式进行初次探索，通过编写yaml文件进行一键部署，相较于手工的部署方式大大的提高了容器部署的效率。 

后续，运维团队将继续推进helm的容器化部署，预计分批次将符合要求的系统进行全量helm部署。