简介：目前KubeNode已经覆盖了阿里巴巴集团的所有的ASI集群，接下来，将随着阿里巴巴集团“统一资源池”的项目，推进KubeNode覆盖更大的范围、更多的场景，让云原生的容器基础设施运维架构发挥更大的价值。
阿里巴巴节点运维的挑战
在阿里巴巴的场景下，做节点运维面临的挑战主要来自于这几个方面：规模、复杂性、稳定性。
首先是规模大。从18年第一个集群的搭建，到现在线上共运行着数百个ASI集群、数十万个节点，其中单集群的节点数最多有超过1万台。在这之上，运行着阿里巴巴集团数万个不同的应用，比如，大家熟知的淘宝、天猫等，总容器实例数有数百万规模。ASI是指AlibabaServerlessInfrastructure，也就是阿里巴巴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一个简化的架构，整体是由这几个部分组成的：
中心端有MachineOperator负责节点和节点组件管理，RemedyOperator负责节点的故障自愈修复。节点侧有KubeNodeAgent，这个单机agent组件负责watch中心MachineOperator、RemedyOperator生成的CRD对象实例，并执行相应的操作，像节点组件的安装、故障自愈任务的执行等。
配合着KubeNode，阿里巴巴还使用NPD进行单机的故障检测，以及对接KubeDefender(阿里自研组件)进行统一风控。当然社区版本的NPD提供的故障检测项是比较有限的，阿里巴巴在社区的基础上进行了扩展，结合阿里巴巴多年节点、容器运维的实践，加入了很多节点的故障检测项，大大丰富了单机故障检测的能力。
1.KubeNode和社区项目关系
github.
