KubeNode：阿里巴巴云原生 容器基础设施运维实践

阿里巴巴节点运维的挑战

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

首先是规模大。从 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 Op