作者 | 谢瑶瑶（初扬）
起源 | 阿里巴巴云原生公众号

随着容器技术的一直倒退迭代，Kubernetes 已成为云原生时代的规范操作系统，那么如何构建一个稳固自愈的云原生操作系统事关重大。尤其是分布式环境下，各类硬件和软件故障已成为常态，间接导致 Kubernetes 集群工作节点时常处于一种不稳固的状态，人肉运维不仅效率低下，误操作及 24 小时 OnCall 也是微小的挑战，因而容器服务通过托管节点池为用户提供了一个自愈的免运维的云上 Kubernetes 集群服务。本文将重点介绍如何通过托管节点池实现 Kubernetes 节点自愈能力。

首先，咱们须要定义什么是节点自愈？

什么是节点自愈？

Kubernetes 集群作为一个典型的分布式系统，是由一组 Master 管控节点，加上若干个运行工作负载的节点组成。其中若干个具备雷同个性的节点逻辑上组成一个节点池，如果某个节点池的节点运维及生命周期治理由容器服务托管，则称该节点池为托管节点池。

节点自愈 定义在 K8s 节点池之上，指无需人为干涉，工作节点即可自行从故障状态中复原。因而节点自愈的一个外围问题是故障状态处理及其复原。比方硬件故障（内存板卡损坏、磁盘坏道、网卡控制器故障）、软件故障（软件 OOM、过程句柄泄露、IO hang、磁盘满、网络断链）、机房断电跳闸、光缆故障、零碎负载过低等。

由此咱们形象了几类故障档次。

1. 刹时故障（网络抖动，负载升高，利用申请超时，组件 OOM，异样重启）。
2. 继续故障（环境变动触发未预期状态）。
3. 谬误（配置谬误，误操作，逻辑 Bug。该类型谬误可能被立刻反馈，也可能会很久后能力反馈，它的特点是须要人为的常识干涉，即便替换正本也无奈解决，智能决策，智能纠错）。

刹时故障通常在内部条件复原后自行复原，此类故障通常会在能触发响应之前曾经复原。

继续故障通常是咱们须要人为干涉的，通常预示着零碎产生了某些比较严重的问题，须要专家教训染指，通常能够通过自动化的伎俩应答，属于本文关注的重点，也是自愈的领域。

谬误层须要意识的参加，比方配置谬误，逻辑 Bug，没有意识参加修复，最终依然会向谬误的方向演变，因而不在本文探讨范畴之内。

为什么须要自愈？

自愈的一个出发点是，基础设施是不稳固的；零碎环境是一直变动的，不确定的，因而随时可能产生故障，须要 24 小时待命，干涉修复，这对运维提出了十分大的挑战，因而构建一个自复原、免运维的 Kubernetes 节点管理体系意义重大。

自愈的价值：

• 自愈的外围出发点是免运维，将工作人员从沉重的运维事务中解放出来，让他们专一于翻新和更高价值的工作，置信中午被故障报警折腾起来是每个运维人员都经验过的痛。
• 规模化集群的运维效率，进步人效与时效。（一个节点的运维与一万个节点的运维在工夫上与工作量上具备实质的区别，大规模的节点故障已齐全超出了人肉运维的可控范畴，保姆式的运维是人力资源的极大节约，老本低廉）。
• 主动感知节点故障，相比于人肉运维具备更短的响应工夫，在故障被终端用户感知前自行复原。
• 程序化的工作能解决人为误操作引发的故障。

节点的自愈能显著晋升运维效率（时效与人效、降本），升高人为误操作导致的问题，减速利用业务翻新。

节点自愈的演进

1. 第一阶段：基于专家教训的进化

自愈的第一种形式是基于专家教训，将专家教训利用于自愈零碎是最不言而喻的计划。

专家教训计划是指将过往的专家运维教训打包成规定列表，造成故障到解法的预案，当匹配到具体故障的时候触发对应的修复计划。

图 1  专家教训

基于专家教训的益处是，一线运维人员对故障的细节最分明，因而也胜利总结了相应故障解决方案的最优流程，精准把控细节。但不能漠视的一个毛病就是：专家教训的覆盖面是相当无限的，不能笼罩未知故障的解法，而事实场景中已知的故障场景会缓缓收敛，未知故障会逐步增多，这就造成专家教训会逐步滞后，从而自愈的成果会被大打折扣。

那么是否有更加对立的计划来笼罩尽可能多的场景，同时又不会带来教训滞后问题呢？

自愈问题的实质（自愈窘境）

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

咱们在讲 DevOps 的时候会强调开发测试和运维的鸿沟，运维埋怨利用没有充沛测试就提交部署，而开发则埋怨我这里明明运行的好好的肯定是你的应用姿态不对，而后通过一番苦楚的排查后，会发现问题是开发和运维运行利用的环境差别导致的，这样的事件在 Devops 时代频繁产生。Docker 的呈现为开发和运维屏蔽了这个问题，docker 通过规范的镜像格局，将利用依赖的运行时环境对立打包成规范镜像作为交付，完满解决了这个环境问题。当然，外面还波及其余的一些利用运行时规范。当咱们回头看看构建长久稳固的自愈零碎时，其实也面临着同样的问题。运行时环境的变动给零碎带来了极大的不确定性，这种不确定性（或者叫环境变动）是自愈难度大的本源。零碎在运行的过程中会产生不稳定性，零碎垃圾、未解决告警沉积、代码 Bug 累积、未解决的边缘异样 Case、一些人为故障源、都会引发的零碎 Fail，无奈穷举这些不确定性进一步决定了不可能 100% 的笼罩所有修复 CASE，因而须要人为时刻照看。

所以咱们说自愈难度大，起因在于咱们无奈当时穷举所有可能的故障，也就无奈齐全笼罩故障解法。并且保护简单多样的自愈计划对人类的脑容量来讲将会是劫难。千奇百怪的故障总会冲破任何一个人脑容量的下限。

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

因而，如果想要解决这个问题，咱们就须要转换思路。咱们不须要穷举每个可能引发故障的 Case 一一修复，只须要在故障产生的时候 驱赶 故障节点上的利用，而后应用一个全新的规范正本简略地 替换 掉故障源即可。
全新的正本替换与重置形式无需思考简单而未知的谬误，只须要确认谬误属于同一类别即可，因而能显著的放大自愈的问题域，求解的复杂度大大降低。

与规范的 docker 镜像殊途同归之处在于，他们都应用规范的环境来从新初始化节点，这样不会有运行时的 Surprise，后果可预期。

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

这里咱们无意淡化故障的发现形式、面向不同基础设施的管制通道、metrics 收集、智能决策、工作编排等介绍，这是一些自愈计划的共性因素。咱们重点关注修复计划，即精细化的专家教训修复（Pets）还是正本替换与重置（Cattle）。

这也是 Kubernetes 哲学根底，也是咱们常说的 Cattle vs Pet. 节点资源在集群中该当被当做标准化的正本（无差别 Box），因而故障正本替换与重置是最经济老本的形式，最能达到效用最大化。

正本替换与重置的挑战

正本替换与重置计划会应用一个洁净的正本从新初始化节点，其后果可控（参考 Docker 镜像的思路）。它可能保障提供一个全新的运行时环境，一个工作合乎预期的集群，合乎最终一致性准则。同时相比于专家教训可能笼罩更加宽泛的故障场景，后果可控。

但同时也面临着两大重点挑战：

第一个是 工夫老本 ，当节点替换可能在 1s 内实现，这能够称为简直没有老本，当正本的替换须要 5 分钟能力实现的话，咱们会感觉这几乎不可忍耐，还是原地修一下更快。那么造成这种差别的因素又是什么呢？没错，就是人们的预期：对于不同故障断定工夫的预期，修复故障所破费工夫的预期。所以你的零碎在故障继续多久后会失去急躁？ 这须要咱们尽可能升高正本替换与重置的工夫老本 ，比方正本要足够轻量，使替换的工夫老本可控。第二个是 业务代价。正本替换是否会造成业务的抖动、中断？这个影响在多大程度上是咱们可能承受的？是否有解决业务影响的相干计划。个别业务影响的起源次要有几个方面，利用被重启后已有连贯会被迫中断，利用重启中间状态可能失落，利用迁徙时未保留的长期数据失落等。因而须要利用在设计上可能容忍重启，具备响应驱赶信号的能力。

从另一个角度来说，即便不做正本替换，故障肯定还会存在，业务代价也不会打消，所以最坏的状况是正本替换不会让事件变的更糟。

那么如何升高业务代价呢？

答案是构建一套全新的云原生利用规范，面向失败的利用设计。必须假设环境是不可信的，随时面临故障重启迁徙等等，须要定义并解决流量平滑迁徙，数据与状态迁徙等的规范。但这依然有一段很长的路要走，也是将来智能化的必经之路。

3. 混合计划

专家教训和正本替换并不是两种水火不容的计划，它们各有长处，因而咱们能够充沛舍短取长，对于已知的问题咱们通过精细化的专家教训形式执行修复，能充沛保留原有节点的状态（长期数据、长连贯等）；当故障领域已超出专家教训库的时候，咱们启动利用驱赶与故障正本替换的形式来尝试兜底修复，从而保证系统的稳定性、业务的连续性。

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

自愈的将来

1. 节点自愈 vs 集群自愈

咱们明天重点探讨的是节点维度的自愈，如果咱们跳出节点维度，在更大的范畴对待这个事件，是否也有同样的成果？比方集群维度（集群自愈）、PaaS 维度（PaaS 自愈）、公共云维度（公共云自愈）。

如果每个维度都是一个无差别化的正本，那么通过正本替换与重置是否能达到最佳的自愈成果？如何解决工夫老本与业务代价？那些咱们已经认为相对不可能的事，是否也会随着技术的提高被一次次冲破？比方 IP 地址数、内存地址。

因而，将来不仅仅是节点的自愈，不仅仅是节点的 Replaceable。

2. 利用标准化

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

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

3. 构建智能化的零碎

智能化是零碎倒退的终态，从工具的倒退能够看尽人类的发展史，咱们的终极目标就是创造一个工具能够为咱们创造工具，这便是智能化。自动化运维让咱们向智能化的方向迈进了一小步，自愈是则是自动化的排头兵。

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

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