建立网站ftp是什么,江西建设城乡网站查询,wordpress一登录就错位,做网站能不能放暴露图片简介#xff1a; 目前 KubeNode 已经覆盖了阿里巴巴集团的所有的 ASI 集群#xff0c;接下来#xff0c;将随着阿里巴巴集团“统一资源池”的项目#xff0c;推进 KubeNode 覆盖更大的范围、更多的场景#xff0c;让云原生的容器基础设施运维架构发挥更大的价值。 阿里巴巴… 简介 目前 KubeNode 已经覆盖了阿里巴巴集团的所有的 ASI 集群接下来将随着阿里巴巴集团“统一资源池”的项目推进 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 Operator、Remedy Operator 生成的 CRD 对象实例并执行相应的操作像节点组件的安装、故障自愈任务的执行等。
配合着 KubeNode阿里巴巴还使用 NPD 进行单机的故障检测以及对接 Kube Defender (阿里自研组件) 进行统一风控。当然社区版本的 NPD 提供的故障检测项是比较有限的阿里巴巴在社区的基础上进行了扩展结合阿里巴巴多年节点、容器运维的实践加入了很多节点的故障检测项大大丰富了单机故障检测的能力。
1. KubeNode 和社区项目关系
github.com / kube-node不相关该项目 2018 年初已停止。ClusterAPIKubeNode 可以作为 ClusterAPI 节点终态的补充。
功能对比 这里解释下阿里巴巴自研的 KubeNode 项目跟社区项目的关系。大家看到 kube-node 这个名字的时候可能会觉得有点似曾相识在 github 上是有一个同名的项目 github.com/kube-node但其实这个项目早在 2018 年初的时候就已经停止了所以只是名字相同两者并没有关系。
另外社区的 ClusterAPI 是一个创建并管理 K8s 集群和节点的项目这里对比了两个项目的关系
集群创建ClusterAPI 负责集群的创建KubeNode 不提供此功能。节点创建ClusterAPI 和 KubeNode 都可以创建节点。节点组件管理和终态维持ClusterAPI 没有提供相应的功能KubeNode 可以管理节点组件并保持终态。节点故障自愈ClusterAPI 主要提供基于节点健康状态重建节点的自愈能力KubeNode 提供了更丰富的节点组件自愈功能能对节点上的各种软硬件故障进行自愈修复。
总的来说KubeNode 可以和 ClusterAPI 一起配合工作是对 ClusterAPI 的一个很好补充。
这里提到的节点组件是指运行在节点上的 kubeletDocker 的软件阿里内部使用 Pouch 作为我们的容器运行时。除了 kubeletPouch 这些调度必须的组件外还有用于分布式容器存储、监控采集、安全容器、故障检测等总共十多个组件。
通常安装升级 kubeletDocker 是通过类似 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 资源当发现有新的对象实例时则进行节点组件的安装升级定期检查各个组件是否运行正常并上报组件的运行状态。
1Use 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 是类似的。
节点组件的终态一致主要包含了软件版本、软件配置和运行状态的正确、一致。
2Use 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 上报故障 ConditionRemedy 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 大促实现了交易核心系统的全面云原生化改造。
原文链接
本文为阿里云原创内容未经允许不得转载
