微策略既有容器化解决方案
在Customer Managed Cloud（CMC）之前，微策略先后推出了若干种容器化解决方案，这些方案秉持了与云平台深度绑定的设计理念，为用户提供开箱即用的便捷性。
一开始，这类解决方案在设计上主要分为云上基础设施和集群内服务两层，如下图所示：
其中，集群中的环境调度服务和环境监控服务主要负责创建、管理和监控容器化环境。而云上基础设施提供网络配置、集群部署、环境管理等功能并为用户提供相应的API。
值得指出的是，集群内的环境调度服务和环境监控服务是无状态服务，与环境相关的状态数据储存在基础设施层，因此并不能脱离云上基础设施单独部署。
因此，对于不同的云平台，都需要单独实现一套独立的基础设施，开发周期长、维护成本高。
在后续的演进中，微策略演进了这一架构，新增了一个管理服务，剥离了一部分原属于基础设施层的业务逻辑，并承担了大部分的API和GUI功能。
但演进后的架构依然与云平台绑定，数据储存在云平台的数据库中。同时新增的管理集群也在一定程度上增加了维护成本。因此新架构主要用于多租户解决方案中。
K8S 自定义资源（Custom Resource） 与Operator模式
在CMC之前，我们就在思考如何解决现有架构的一些痛点。其中最重要的一项就是集群内的环境调度服务和环境监控服务不能持久化环境信息（无状态）的问题，这使得其与上层之间存在双向的依赖。举例来说，当上层调用环境调度服务升级环境时，环境调度服务还要反向查询上层的接口来获取环境数据。
事实上，集群内的环境调度服务和环境监控服务储存的数据是关于环境的结构化信息，客户提供的环境信息与客户需要的环境实际上存在一一对应的关系，因此我们很容易将其与K8S 自定义资源（Custom Resource，CR）联系到一起。CR是对K8S声明式API的扩展。
当用户创建某一种CR时，我们就为其在K8S集群内创建相应的一系列资源；当用户更新这一CR时，我们为其更新资源；删除亦如是。这，就是Operator模式。而这种在CR与资源间同步的过程，通常被称为reconciling。而CR本身作为结构化数据，K8S支持使用Open API schema对其进行定义，这也就是Custom Resource Definition（CRD）。
因此，如果我们用Operator替代集群内的环境调度服务和环境监控服务，最初的架构将变为：
当然，这一设想并未落地，因为我们恰好遇到了CMC。
Customer Managed Cloud（CMC）的客户诉求
CMC客户最核心的诉求其实非常简单：把微策略容器化环境部署在他们自己的集群上。
这类集群可能部署在某个我们不支持的公有或私有的云平台上，甚至也可能是某个客户自己搭建的集群。
CMC与Operator的碰撞
在最初讨论 CMC 的过程中，我们曾考虑让客户通过 Helm 包管理的方式自行部署环境。然而，为了确保客户的使用体验，我们希望将环境底层的安装过程抽象化，以避免客户直接接触和处理安装细节，我们转而选择了使用 K8S Operator。
与其他方式相比，Operator 没有直接的外部依赖，客户可以在任何 K8S 集群中部署 Operator，并通过 CR 来管理环境，所需的依赖项也由客户在 CR 中提供并配置。
Operator还需要解决什么问题？
除reconciling即环境的创建、更新、升级和删除外，Operator及其框架还需要支持：
1. CRD生成：即从代码直接生成CRD，减轻开发负担。
2. CR校验：部分校验可以直接通过CRD完成，另一些则是通过K8S validation webhook实现的，因此Operator还需要提供一个轻量的API Server。
3. 兼容一部分非声明式的API：原本的集群内环境调度服务还支持一部分操作性的API如停止、启动和重启环境，Operator也需要支持这些API；对这类API，用户需要在CR上添加注解，
如重启环境的注解为 cloud.microstrategy.com/actions.restart=all.
4. 状态监测：Operator整合了环境监控服务的功能，在整个环境部署的过程中，Operator都会及时地将状态信息写入CR的status字段中。
Operator的框架及主要实现思路
考虑到微策略的开发环境，我们决定采用 Java Operator SDK 作为我们的 Operator 框架。
需要注意的是，Java Operator SDK 的资源管理方式与我们基于 Helm 的部署方式存在一定差异。Java Operator SDK 更倾向于直接管理所有的 K8S 资源。
因此，在实践中，我们将 Java Operator SDK 的 Reconciler 作为独立的入口层，具体环境操作则由背后的 Environment Controller 执行。整体架构如下图所示。
其中，Environment Controller是一个状态机，负责管理特定环境的完整生命周期。其部分状态及状态转移关系如下图所示。
Environment Installer负责执行环境安装（包括升级及删除）操作，Environment Monitor负责环境监测，其功能与先前的环境调度服务和环境监控服务类似。
以创建环境为例，上述组件及CR间的时序关系如下图所示：
