基于kubernetes托管虚机后续管理设计

基于kubernetes托管虚机有一些现成的方案，不过今天笔者要聊的是在虚机交付后，该如何实现后续的管理，包括如何实现环境和代码的部署与更新，感兴趣的可以一起看看，本篇是设计篇

1. 虚机应用的托管

由于虚机应用交付流程链路的复杂性，我们无法设计一套机制，能cover住100%的异常场景，所以我们专注正常流的交付，后期可以针对异常的案例来进行复盘，不断提高交付成功率，本节主要介绍我们设计的自动化交付流程、以及用到的k8s相关的机制

1.1 面向终态的交付

虚机应用典型的交付流程大概是这样的：申请机器-》部署环境-》部署代码-》绑定监控-》健康检查-》灰度上线，如果要对标容器则创建机器、部署环境、部署代码相当于完成了一个“虚机镜像”的交付，也是我们主要要自动化的流程

1.1.1 核心状态机

在云原生中通常都是基于面向终态的交付方式， 基于目标状态和当前状态由系统自动进行决策，我们根据现状定义了如下的状态机：

这里重点说下就绪状态，就绪状态表示应用的当前的部署环境、代码完成，并且健康检查都通过了即一个节点可以进行灰度引流了

同时如果一个应用的环境变更则会按照对应的安全频率来进行节点环境的变更，只需要变更节点的环境列表，系统会自动发现当前节点需要进行更新，进行状态机的转换；然后自动化系统会发现这个变更则就会进行检查并且自动化的进行环境的安装

1.1.2 故障转移

如果发现某个节点宕机后，则会由系统首先将系统设置为下线状态（IAAS平台还不支持这个事情）， 然后会根据策略来进行决策是否自动进行修复，如果需要修复则系统会新创建一个节点然后执行上述流程，否则则会修改对应的副本数量

1.1.3 准入机制

为了保障稳定性我们在自动化的流程中加入准入机制，即在对应的阶段允许引入人工节点来进行决策，将控制权交给应用运维，并且提供相关的数据和策略辅助提高运维决策效率

1.1.4 任务列表

那如果如何确定一个节点处于某个状态下该做哪些任务呢？这里其实取决于两部分当前状态和目标状态，首先我们这里通过系统内部（k8s）里面当前的状态来进行计算以确定节点当前该处于哪个状态，每当进入到一个状态就会同时追加一个任务列表，controller则根据外部状态和任务列表进行自动化操作，并更新内部状态，从而不断的完成不同状态的切换，最终达到目标状态

1.1.5 异常流程

异常流程的处理可能是所有自动化系统里面最头痛的了，在我们的系统里面主要通过两种方式来解决：人工和自动化（好像特么的是废话），

首先来说自动化，当节点某些自动化任务无法进行时系统会通知运维，当前系统遇到无法处理的异常了，这时候运维会根据当前问题来修复某些不满足的条件，比如开通网络策略、部署Agent等等，当完成后只需要变更节点状态，后续就会自动化修复

当遇到无法通过上述自动化短时间来解决的时候，运行运维进行手工修复，并强制更新对应的状态，则系统会根据当前的状态进行后续的操作，比如检测到就绪之后就进行负载挂载等

1.2 kubernetes相关机制

那如何利用k8s的相关机制来实现上述交付流程呢，这里主要通道了webhook、finalizer、annotations几个机制

1.2.1 webhook

首先我们通过webhook再server更新的时候通过admission.Mutation机制来根据当前内部状态进行状态的决策，以确定接下来的自动化任务，在这环节我们实现了从部署环境-》部署代码-》就绪状态的转换

1.2.2 finalizer

在主机进行删除的时候，需要等待负载删除、暂停监控、删除虚机等流程全部结束后才能进行节点对象的删除，从而实现了节点信息的异步清理机制

2. 核心设计

2.1 核心对象设计

考虑到应用的环境操作和部署操作两个操作频率的差异性，我们这里参考k8s声明了两个上层控制器，即通过VMReplicaSet来实现程序运行环境的交付，而将部署操作交由VMDeployment来控制，同时两个控制在操作某个实例的时候都会先进行状态检测，然后在进行资源的锁定才能进行相关的操作，从而保障执行流程的稳定性

2.2 状态转换机制

下面我们会按照几个不同的场景来分别介绍下虚机状态的转换以及对应控制器的控制，我们有两个核心的设计理念：

1.人只负责环境配置的描述，由系统完成相关状态和自动化操作

2.状态的确定依赖于当前现状，同时人的决策高于一切

2.2.1 初始化

当检测副本数量发生变化VMReplicaSet首先会发送申请，确认当前是否要进行机器的创建，同时会创建对应的Server的Package配置，通过计算Package状态设置当前状态为Initializing，并同时创建部署环境的任务，然后等待环境部署的结果，同时会挂载Server的负载信息

等待环境部署完成后，控制器会自动检测状态并设置为Deploying，同时通过部署系统进行代码的部署，并将对象重新入队，直到状态部署完成

代码部署完成后，会进行状态检测，如果系统节点健康检查通过并且监控状态未发现异常，则会将节点设置为Ready状态，同时负载控制器和监控控制器都会对应的配置，至此完成虚机的初始化完成，后续如果环境不变，则代码部署只需要重复当前操作

2.2.2 有状态的下线

虚机通常是有状态的应用，如果要下线通常都是选择指定的节点，并标记为下线状态，同时结合finalizer和控制器完成对应负载和监控的同步操作，当所有的finalizer都释放后，最后进行对应节点的删除

2.2.3 故障转移机制

如果对应的节点宕机，则只需要加一个处理转换逻辑即可，如果是短时间可以恢复就只需要将对应的节点标记为UnKnown，同时监控和负载控制器进行对应的操作，然后等待重启后接收到对应的事件后将节点设置为Initializing， 然后系统会自动进行对应的检测逻辑，自动转换为Ready，监控和负载控制器监控自动执行相关逻辑，即可完成上线

如果节点不可修复只需要将状态设置为下线状态，然后对应的副本控制器检测到节点不足，就会自动调用IAAS系统进行自动创建，然后执行初始化流程即可

3. 未完待续

基于流程驱动的跟基于k8s的控制器在实现流程上其实并没有本质的差别，在云原生里面有很多种玩法，虚机应用的管理本质上就是复杂环境的管理。

如何管理复杂的环境，其实就是让环境可描述，系统自治，尽可能减少人的参与，人只参与影响稳定性的决策，而不参与任何关于流程驱动。
编辑：hfy