作者 | 周涛  阿里云技术专家
起源 | 阿里巴巴云原生公众号

阿里巴巴节点运维的挑战

在阿里巴巴的场景下，做节点运维面临的挑战次要来自于这几个方面：规模、复杂性、稳定性。

首先是规模大。从 18 年第一个集群的搭建，到当初线上共运行着数百个 ASI 集群、数十万个节点，其中单集群的节点数最多有超过 1 万台。在这之上，运行着阿里巴巴团体数万个不同的利用，比方，大家熟知的淘宝、天猫等，总容器实例数有数百万规模。ASI 是指 Alibaba Serverless  Infrastructure，也就是阿里巴巴 Serverless 基础设施。ASI 的概念同时蕴含集群的管控面和节点两方面。每一个 ASI 集群都是调用 Aliyun 规范的 OpenAPI 创立的 ACK 托管版集群，而后在此之上，咱们自研了调度器、开发部署了很多的 addon，进行性能加强、性能优化，并对接团体的各个系统，并做到节点全托管，不须要利用开发运维人员关怀底层的容器基础设施。

其次是环境非常复杂。目前 IaaS 层运行着很多种异构的机型，有 x86 服务器，也有 ARM 国产化机型，同时为了服务新计算、AI 的业务，也有 GPU、FPGA 的机型。线上的内核版本也十分多，4.19 是去年开始规模上线的内核版本，同时 3.10 / 4.9 内核版本上的节点问题也须要持续撑持，不同的内核版本演进也须要具备规模化轮转的运维能力。目前上万个在线利用蕴含了像淘宝、天猫、菜鸟、高德、饿了么、考拉、盒马 等各种不同的业务，同时跟在线利用一起运行着混部、平安容器的业务，像大数据、离线计算、实时计算、搜寻等这些业务类型也都跟在线业务运行在同一个主机环境中。

最初是对稳定性的高要求。在线业务的特点是对提早和抖动十分敏感，单节点的抖动、夯机、宕机等故障都可能会影响某个用户在淘宝的下单付款，引发用户的吐槽和投诉，所以整体对稳定性的要求十分高，要求对单节点故障的解决有很高的及时性和有效性。

KubeNode：云原生节点运维底座介绍

KubeNode，是阿里巴巴自研的基于云原生形式来治理和运维节点的底座我的项目，相比于传统的过程式的运维伎俩，KubeNode 通过 K8s 扩大 CRD 以及对应的一组 Operator，能提供残缺的节点生命周期和节点组件生命周期治理，通过申明式、面向终态的形式，把节点及节点组件的治理变得跟治理 K8s 中的一个利用一样简略，并实现节点的高度一致性以及自愈修复的能力。

上图右侧是 KubeNode 一个简化的架构，整体是由这几个局部组成的：

核心端有 Machine Operator 负责节点和节点组件治理，Remedy Operator 负责节点的故障自愈修复。节点侧有 Kube Node Agent，这个单机 agent 组件负责 watch 核心 Machine Operator、Remedy Operator 生成的 CRD 对象实例，并执行相应的操作，像节点组件的装置、故障自愈工作的执行等。

配合着 KubeNode，阿里巴巴还应用 NPD 进行单机的故障检测，以及对接 Kube Defender (阿里自研组件)  进行对立风控。当然社区版本的 NPD 提供的故障检测项是比拟无限的，阿里巴巴在社区的根底上进行了扩大，联合阿里巴巴多年节点、容器运维的实际，退出了很多节点的故障检测项，大大丰盛了单机故障检测的能力。

1. KubeNode 和社区我的项目关系

• github.com / kube-node：不相干，该我的项目 2018 年初已进行。
• ClusterAPI：KubeNode 能够作为 ClusterAPI 节点终态的补充。

性能比照：

这里解释下阿里巴巴自研的 KubeNode 我的项目跟社区我的项目的关系。大家看到 kube-node 这个名字的时候，可能会感觉有点似曾相识，在 github 上是有一个同名的我的项目 github.com/kube-node，但其实这个我的项目早在 2018 年初的时候就曾经进行了，所以只是名字雷同，两者并没有关系。

另外社区的 ClusterAPI 是一个创立并治理 K8s 集群和节点的我的项目，这里比照了两个我的项目的关系：

• 集群创立：ClusterAPI 负责集群的创立，KubeNode 不提供此性能。
• 节点创立：ClusterAPI 和 KubeNode 都能够创立节点。
• 节点组件治理和终态维持：ClusterAPI 没有提供相应的性能，KubeNode 能够治理节点组件并放弃终态。
• 节点故障自愈：ClusterAPI 次要提供基于节点衰弱状态重建节点的自愈能力；KubeNode 提供了更丰盛的节点组件自愈性能，能对节点上的各种软硬件故障进行自愈修复。

总的来说，KubeNode 能够和 ClusterAPI 一起配合工作，是对 ClusterAPI 的一个很好补充。

这里提到的节点组件，是指运行在节点上的 kubelet，Docker 的软件，阿里外部应用 Pouch 作为咱们的容器运行时。除了 kubelet，Pouch 这些调度必须的组件外，还有用于分布式容器存储、监控采集、平安容器、故障检测等总共十多个组件。

通常装置降级 kubelet，Docker 是通过相似 Ansible 等面向过程的一次性动作来实现的。在长时间运行过程中，软件版本被意外批改或是碰到 bug 不能工作的问题是很常见的，同时这些组件在阿里巴巴的迭代速度十分快，往往一两周就须要公布推平一个版本。为了满足组件疾速迭代又能平安降级、版本统一的需要，阿里巴巴自研了 KubeNode，通过将节点以及节点组件通过 K8s CRD 的形式进行形容，并进行面向终态的治理，从而确保版本一致性，配置一致性以及运行态正确性。

2. KubeNode – Machine Operator

上图是 Machine Operator 的架构，一个规范的 Operator 设计：扩大的一组 CRD 再加上核心的控制器。
CRD 定义包含：跟节点相干的 Machine、MachineSet，以及跟节点组件相干的 MachineComponent、MachineComponentSet。

核心端的控制器包含：Machine Controller、MachineSet Controller、MachineComponentSet Controller，别离用来管制节点的创立、导入，节点组件的装置、降级。

Infra Provider 具备可扩展性，能够对接不同的云厂商，目前只对接了阿里云，然而也可通过实现相应的 Provider 实现对接 AWS、Azure 等不同的云厂商。

单机上的 KubeNode 负责 watch CRD 资源，当发现有新的对象实例时，则进行节点组件的装置降级，定期检查各个组件是否运行失常，并上报组件的运行状态。

1）Use Case：节点导入

上面分享基于 KubeNode 对已有节点的导入过程。

首先用户会在咱们的多集群管理系统中提交一个已有节点的导入操作，接下来零碎先下发证书，并装置 KubeNode Agent，等 agent 失常运行并启动之后，第 3 步会提交 Machine CRD，接下来 Machine Controller 会批改状态为导入 phase，并等 Node ready 之后从 Machine 上同步 label / taint 到 Node。第 5 步是 MachineComponentSet，依据 Machine 的信息确定要装置的节点组件，并同步到 Machine 上。最初 Kube Node Agent 会 watch 到 Machine、MachineComponent 的信息，实现节点组件的装置，并等所有组件运行失常后，节点导入操作实现。整个过程跟用户提交一个 Deployment 并最终启动一个业务 Pod 是相似的。

节点组件的终态统一次要蕴含了软件版本、软件配置和运行状态的正确、统一。

2）Use Case：组件降级

这里介绍下组件的降级过程，次要依赖的是 MachineComponentSet Controller 提供的分批次降级的能力。

首先用户在多集群管理系统下面提交一个组件降级操作，而后就进入一个逐批次循环降级的过程：先更新 MachineComponentSet 一个批次降级的机器数量是多少，之后 MachineComponentSet Controller 会计算并更新相应数量的节点上组件的版本信息。接下来 Kube Node Agent watch 到组件的变动，执行新版本的装置，并查看状态失常后上报组件状态失常。当这个批次所有的组件都降级胜利后，再开始下一个批次的降级操作。

下面形容的单集群单个组件的降级流程是比较简单的，但对于线上十多个组件、上百个集群，要在所有的集群都实现版本推平工作就不那么简略了，咱们通过 ASIOps 集群对立运维平台进行操作。在 ASIOps 零碎中，将上百个集群配置到了无限的几个公布流水线，每条公布流水线都依照：测试 -> 预发 -> 正式 的程序编排。一次失常的公布流程，就是选定一条公布流水线，按其事后设定好的集群程序进行公布，在每个集群外部，又依照 1/5/10/50/100/… 的程序进行主动公布，每一个批次公布实现，会触发衰弱巡检，如果有问题则暂停主动公布，没问题的话等观察期完结，则主动开始下一个批次的公布。通过这样的形式，做到了既平安又高效的实现一个组件新版本公布上线的过程。

3. KubeNode – Remedy Operator

接下来分享 KubeNode 外面的 Remedy Operator，也是一个规范的 Operator，用来做故障自愈修复。

Remedy Operator 也是由一组 CRD 以及对应的控制器组成。CRD 定义包含：NodeRemedier 和 RemedyOperationJob，控制器包含：Remedy Controller、RemedyJob Controller，同时也有故障自愈规定的注册核心，在单机侧有 NPD 和 Kube Node Agent。

Host Doctor 是在核心侧的一个独立的故障诊断零碎，对接云厂商获取被动运维事件并转换为节点上的故障 Condition。在阿里云私有云上，ECS 所在的物理机产生的硬件类的故障或是打算中的运维操作，都会通过规范 OpenAPI 的模式获取，对接后就能够提前感知节点的问题，并提前主动迁徙节点上的业务来防止故障。

Use Case：夯机自愈

这里以夯机自愈的案例来介绍一个典型的自愈流程。

首先咱们会在多集群管理系统 ASI Captain 上配置下发 CRD 形容的自愈规定，并且这些规定是能够灵便动静减少的，针对每一种 Node Condition 都能够配置一条对应的修复操作。

接下来节点上的 NPD 会周期性的查看是否有产生各种类型的故障，当发现内核日志中有呈现 “task xxx blocked for more than 120 seconds” 的异样日志之后，断定节点夯机，并给 Node 上报故障 Condition，Remedy Controller watch 到变动后，就触发自愈修复流程：首先会调用 Kube Defender 风控核心接口判断以后自愈操作是否容许执行，通过后就生成 RemedyOperationJob 自愈工作，Kube Node Agent watch 到 job 后执行自愈操作。

能够看到整个自愈流程不依赖于内部第三方零碎，通过 NPD 做故障检测，Remedy Operator 执行自愈修复，以云原生的形式实现了整个的自愈修复流程，最快能够做到分钟级的故障发现并修复。同时，通过对 NPD 检测规定的加强，解决的故障范畴笼罩了从硬件故障、OS 内核故障、到组件故障的全链路修复。值得强调的是，所有的自愈操作都会对接 Kube Defender 对立风控核心，进行分钟级、小时级、天级别的自愈修复流控，避免当呈现 Region / Zone 级别断网、大规模 io hang、或是其余大面积软件 bug 的状况下，触发对整个 Region 所有节点的故障自愈，引发更重大的二次故障。

KubeNode 数据体系

KubeNode 数据体系建设的好坏对整体度量并晋升 SLO 起着十分重要的作用。

在节点侧，NPD 会检测故障并上报事件核心，同时 walle 是单机侧的指标采集组件，会采集节点以及容器的各种指标项信息，包含像 CPU / Memory / IO / Network 等常见的指标，以及很多其余的像内核、平安容器等的指标项。核心侧 Promethes (阿里云私有云上的 ARMS 产品) 会采集所有节点的指标并进行存储，同时也采集扩大过的 Kube State Metrics 的数据，获取 Machine Operator 和 Remedy Operator 的要害指标信息。在获取到这些数据的根底之上，再在下层面向用户，配置监控大盘、故障报警、以及全链路诊断的能力。

通过数据体系的建设，咱们就能够用来做资源利用率的剖析统计，能够提供实时的监控报警，进行故障剖析统计，也能够剖析整体 KubeNode 中的节点以及节点组件的覆盖率、统一率、节点自愈的效率，并提供针对节点的全链路诊断性能，当排查节点问题时，能够查看该节点上历史产生过的所有的事件，从而帮忙用户疾速定位起因。

将来瞻望

目前 KubeNode 曾经笼罩了阿里巴巴团体的所有的 ASI 集群，接下来，将随着阿里巴巴团体“对立资源池”的我的项目，推动 KubeNode 笼罩更大的范畴、更多的场景，让云原生的容器基础设施运维架构施展更大的价值。

作者简介

周涛  阿里云技术专家，2017 年退出的阿里，过来几年始终负责阿里巴巴数十万规模集群节点管控零碎的研发工作，参加了历年的双十一大促。随着 2018 年底开始的团体上云我的项目，治理的节点从云下的物理机笼罩到了阿里云私有云上的神龙裸金属服务器，并撑持 双 11 大促实现了交易外围零碎的全面云原生化革新。