在企业往数字化转型的过程中，企业IT服务的交付效率一直备受重视，企业的持续部署能力从最初的人力手工交付，脚本自动化交付，到现在PaaS 服务托管进行演进。
而2013年发布的Docker 项目，镜像管理机制更是为 PaaS 服务解决了用户最核心的痛点——环境一致性问题，国内外大量的企业基于容器云来构建自己内部的 PaaS 交付平台，直接为产品、研发、测试部门赋能，把持续交付的效能提升到一个新的巅峰。
容器虽然解决了环境的一致性问题，但是企业内部生产环境使用容器还是会存在大量的挑战：
规模容器管理
基于微服务原则架构分布式应用
多主机容器集群管理
按需扩展，自动伸缩
无停机部署应用
服务发现
……
这些挑战渐渐变成容器编排的核心需求，针对这些需求，出现了很多容器编排的竞争方案，例如：Docker 公司的 Docker Compose、Google 的 Kubernetes、Mesosphere的 Mesos等等；而最终 Kubernetes 凭借着 Google 在过去十多年来在80多个数据中心、100多万台服务器上应用服务管理经验，在这场激烈的编排之战中取得最终的胜利，成为容器编排框架的事实标准。
优维容器编排建设概述
优维科技一直为助力企业实现应用生命周期管理的努力，在IT资源管理国内首次提出应用管理的IT资源管理系统（CMDB），在持续部署领域中，目前有高度标准化的主机环境部署解决方案，为用户提供全可视化部署跟踪和多环境部署实例管理服务。
图：EasyOps 部署可视化跟踪
图：EasyOps 多环境部署实例管理
随着企业数字化转型的浪潮，更多的企业在拥抱多云混合架构，并且使用容器编排提升IT服务交付效能，EasyOps汲取以往应用生命周期管理的经验，配套推出了自己一整套的应用容器管理服务，实现容器编排和多云布局。
Kubernetes管理和使用误区
很多使用 Kubernetes 集群的企业都有这个误区，很容易把 Kubernetes 集群直接交付给业务部门进行授权和管理。优维认为，无论基础设施如何变化，应用生命周期的管理本质和企业中参与协作的角色没有发生任何的变化，例如使用主机交付模式时，由IAAS的管理员对管理私有云服务，提供存储和网络规划等，而业务部门使用PaaS服务进行产品研发和服务交付。
对于Kubernetes集群的使用也是一样的，例如：
IAAS 管理员负责对 Kubernetes 集群进行集群创建、版本更新、节点容量规划、网络规划、存储服务规划，命令空间规划等工作，并且把资源分配到业务线中让其自行使用；IAAS 管理员管理的K8S对象涉及：Namespace、Node、StorageClass、PVC、Ingress Controller 等，例如：EasyOps 为 IAAS 管理员提供 Kubernetes 资源管理系统：
PAAS 管理员对Kubernetes集群进行应用部署、配置管理、负载均衡等工作；PAAS管理员管理的K8S对象涉及：Workload、Service、Ingress、ConfigMap、Secrets等，例如：EasyOps 为 PAAS 管理员提供Kubernetes 应用部署系统。
而优维半年以来规划的思路刚好也和2019年10月17日，阿里巴巴和微软联合推出开放应用模型Open Application Model(OAM) 不谋而合，OAM把Kubernetes的参与者分为 Application Developer、Application Operator、Infrastructure Operator：
应用部署系统领域模型
EasyOps 新一代的应用持续部署系统，在产品上为了达成帮助企业实现多云对接和容器编排而设计的，它帮助用户解决以下的核心痛点：
如何让应用在多种基础设施中管理部署实例和负载均衡，例如同时管理主机和Kubernetes的混合部署环境；
如何让应用在持续交付的多个环境中管理部署实例和负载均衡，例如开发、测试、生产环境；
如何让应用在本地和多云基础设施中快速对接、管理部署实例和负载均衡，例如：同时布局腾讯云和阿里云的服务；
如何让应用的部署能力服务化，从而让其他中间件管理对象也可以享受这些环境管理和持续部署的服务，例如：MySQL的部署、Redis的部署；
如何让应用的环境实例数据全部在IT资源管理系统（CMDB）中有效地落地，从而为企业的其他PAAS系统提供消费元数据，例如：应用监控系统、事件分析平台、应用容量系统等等。
EasyOps为了解决这些痛点对产品的领域模型进行了调整，在应用下提供资源组（Resource Group）的重要对象，IT资源管理系统（CMDB）的核心领域如下：
图：EasyOps 新一代部署系统领域模型
那么，对于基础设施 Kubernetes 的派生实现如下：
图：EasyOps 新一代部署系统领域模型（派生Kubernetes）
资源组的四大核心共功能模块
资源组（Resource Group）承担着应用环境管理和持续部署的最重要的角色，资源组功能分为4大核心模块：
一、工作负载
资源组的工作负载管理着当前环境中的部署实例，负责部署实例的：
创建和销毁；
制品版本的升级和回滚；
扩容缩容；
健康检查；
资源使用控制（CPU和Memory等）；
……
图：资源组的Workload管理
对于Kubernetes的基础设施而言，则资源组的工作负载管理 Kubernetes 的 Deployment、StatefulSet、DaemonSet和CronJob 对象。
二、负载均衡
资源组的负载均衡管理着工作负载中的部署实例的访问方式，负责：
创建、更新和销毁负载均衡的规则信息；
配合部署策略（A/B发布、金丝雀发布等）路由和转发工作负载的流量；
……
图：资源组的Service管理
对于 Kubernetes 的基础设施而言，则资源组的负载均衡管理 Kubernetes 的 Service 和 Ingress 对象。
三、配置中心
资源组的配置中心管理着工作负载的环境信息，负责对当前环境部署实例的程序配置和环境配置进行注入、更新。
对于 Kubernetes 的基础设施而言，则资源组的配置中心管理着 Kubernetes 的 ConfigMap 和 Secret 对象。
图：Kubernetes 集群的 ConfigMap
备注：在配置管理服务中，EasyOps 希望配置中心未来要和云原生应用架构整合在一起，将会寻找和落实一个实时在线，突破基础设施壁垒的配置管理服务。
四、版本列表
EasyOps 在技术上为了快速突破多云布局和容器编排的挑战，使用了IT基础设施蓝图编排的Terraform服务，Terraform 本身是使用配置文件描述基础设施，能够和EasyOps 现有的IT资源管理系统（CMDB）的元数据进行深度整合：
图：EasyOps 的新一代应用生命周期管理方案
因此本质上，资源组在IT资源管理系统中（CMDB）中是一个应用基础设施的配置文件：
对工作负载、负载均衡、配置中心的任何调整都会产生资源组文件的版本变化，这些变化录入IT资源管理系统中（CMDB），产生实例版本；
然后提交给Terraform应用到生产环境，最后由 Terraform 会把环境实例状态回写到IT资源管理系统中，完成变更闭环，从而严格实践基础设施即代码（Infrastructure as Code）的蓝图编排；
应用的环境管理数据可以通过IT资源管理系统（CMDB）共享给企业其他的PAAS服务，例如：应用监控系统、应用容器系统等等。
图：IT资源管理系统的应用环境数据的关联查询
在产品功能上，资源组的版本列表提供给用户对整个应用当前基础设施的历史查看和回滚服务。
未来的RoadMap规划
优维的 Kubernetes 应用部署系统推出不久，因此后续会保持节奏，持续增加服务内容，例如对：
支持用户创建和管理更多类型的Workload对象；
支持用户创建和管理更多的Ingress对象；
支持用户使用 Resource Group作为环境模板，快速在多云环境中进行迁移和扩容；
……
但优维期望不止如此，随着 Service Mesh（服务网格）概念的提出，优维希望能为用户提供基于Istio的应用流量管理服务，从而让用户轻松定制更多的可视化部署策略，例如金丝雀部署、蓝绿部署等。
图：基于 Istio 的部署策略
同时，从部署普通的镜像制品，优维希望可以让用户通过 Helm Charts 的方式来创建 Resource Group，同时对 Helm Charts 定义的资源对象进行深度拆解和管理，帮助用户一键创建和部署应用的Chart。
结束语
Kubernetes 通过对基础设施（Network、Storage、Device、Runtime、Sechduler等）进行抽象，定义一整套标准的 API和Webhook工作机制，将容器编排技术提高到史前未有的巅峰，未来的十年，将会是Kubernetes的天下，希望这篇文章能带给你在企业生产环境使用Kubernetes构建应用交付服务一点灵感，我会感到无比的荣幸。