节点自愈定义在 K8s 节点池之上，指无需人为干预，工作节点即可自行从故障状态中恢复。因此节点自愈的一个核心问题是故障状态处置及其恢复。 比如硬件故障（内存板卡损坏、磁盘坏道、 卡控制器故障）、软件故障（软件 OOM、进程句柄泄露、IO hang、磁盘满、 络断链）、机房断电跳闸、光缆故障、系统负载过高等。

图 1  专家经验

基于专家经验的好处是，一线运维人员对故障的细节最清楚，因此也成功总结了相应故障解决方案的最优流程，精准把控细节。但不能忽视的一个缺点就是：专家经验的覆盖面是相当有限的，不能覆盖未知故障的解法，而现实场景中已知的故障场景会慢慢收敛，未知故障会逐渐增多，这就造成专家经验会逐渐滞后，从而自愈的效果会被大打折扣。

那么是否有更加统一的方案来覆盖尽可能多的场景，同时又不会带来经验滞后问题呢/p>

自愈问题的本质（自愈困境）

这里我们需要探寻一下自愈难度大的根源。从一个开发运维熟知的 Devops 例子开始。

我们在讲 DevOps 的时候会强调开发测试和运维的鸿沟，运维抱怨应用没有充分测试就提交部署，而开发则抱怨我这里明明运行的好好的一定是你的使用姿势不对，然后经过一番痛苦的排查后，会发现问题是开发和运维运行应用的环境差异导致的，这样的事情在 Devops 时代频繁发生。Docker 的出现为开发和运维屏蔽了这个问题，docker 通过标准的镜像格式，将应用依赖的运行时环境统一打包成标准镜像作为交付，完美解决了这个环境问题。当然，里面还涉及其他的一些应用运行时标准。 当我们回头看看构建持久稳定的自愈系统时，其实也面临着同样的问题。运行时环境的变化给系统带来了极大的不确定性，这种不确定性（或者叫环境变化）是自愈难度大的根源。系统在运行的过程中会产生不稳定性，系统垃圾、未处理告警堆积、代码 Bug 累积、未处理的边缘异常 Case、一些人为故障源、都会引发的系统 Fail，无法穷举这些不确定性进一步决定了不可能 100% 的覆盖所有修复 CASE，因此需要人为时刻照看。

所以我们说自愈难度大，原因在于我们无法事先穷举所有可能的故障，也就无法完全覆盖故障解法。并且维护复杂多样的自愈方案对人类的脑容量来讲将会是灾难。千奇百怪的故障总会突破任何一个人脑容量的上限。

2. 第二阶段：基于 Replaceable 的重生

因此，如果想要解决这个问题，我们就需要转换思路。我们不需要穷举每个可能引发故障的 Case 逐个修复，只需要在故障发生的时候驱逐故障节点上的应用，然后使用一个全新的标准副本简单地替换掉故障源即可。
全新的副本替换与重置方式无需考虑复杂而未知的错误，只需要确认错误属于同一类别即可，因此能显著的缩小自愈的问题域，求解的复杂度大大降低。

与标准的 docker 镜像异曲同工之处在于，他们都使用标准的环境来重新初始化节点，这样不会有运行时的 Surprise，结果可预期。

下图是 K8s 集群下节点自愈的整体方案架构：

容器服务 ACK 托管节点池通过这种混合的方式实现了灵活可配置的节点自愈，让用户从节点的运维中解放出来，对应用提供一个统一的池化视图，无需关心底层基础设施。

自愈的未来

1. 节点自愈 vs 集群自愈

我们今天重点讨论的是节点维度的自愈，如果我们跳出节点维度，在更大的范围看待这个事情，是否也有同样的效果如集群维度（集群自愈）、PaaS 维度（PaaS 自愈）、公共云维度（公共云自愈）。

如果每个维度都是一个无差别化的副本，那么通过副本替换与重置是否能达到最佳的自愈效果何解决时间成本与业务代价些我们曾经以为绝对不可能的事，是否也会随着技术的进步被一次次突破如 IP 地址数、内存地址。

因此，未来不仅仅是节点的自愈，不仅仅是节点的 Replaceable。

2. 应用标准化

应用标准化是自动化到智能化的前提。每个应用、每个节点、每个集群在地位上都是对等的，标准的规格、标准的集装箱。

没有规矩不成方圆，一套全新的云原生应用标准势在必行，让应用的重启、流量的平滑迁移、数据状态存储与迁移成为常态，应用标准化促成规模效应。应用的标准化为自愈提供坚实的实践基础。

3. 构建智能化的系统

智能化是系统发展的终态，从工具的发展可以看尽人类的发展史，我们的终极目标就是发明一个工具可以为我们发明工具，这便是智能化。自动化运维让我们向智能化的方向迈进了一小步，自愈是则是自动化的排头兵。

一个高度自治的系统，会形成系统自愈的闭环，故障的发现到隔离，替换或重置修复，可以是软件故障的修复，甚至可以是硬件故障的自我替换。或许是人类指导人工智能，也可能是人工智能指导人类的决策。总之，系统会自我驱动运行。

托管节点池详细信息请参考文档。