金山云-文档中心-GPU节点故障运维自愈

容器服务(KCE)

查看更多结果

未找到含当前关键字的文档标题

页面目录

全部展开全部收起

产品更新动态

未找到含该关键词的产品

文档中心

容器服务(KCE)

容器服务用户指南

组件说明

GPU节点故障运维自愈

最近更新时间：2024-09-10 16:07:52

在Kubernetes集群中节点作为核心资源，其工作状态是否健康尤为重要。在面向AI场景中，由于GPU本身的易故障性，当发生单点故障时会迅速蔓延造成连锁故障反应，影响任务完成效率。KCE-GPU-Error-Rescue是金山云容器服务结合客户实际AI业务云原生化落地经验，推出的针对于GPU Xid Error的故障运维自愈插件。在启用故障运维自愈组件后，支持能力如下：

故障感知及通知：结合云监控能力及时感知GPU节点Xid Error，并通知到相关人；
故障收敛：通过Kubernetes的驱逐、排水等原生能力，制止故障蔓延；
故障自愈：提供节点重启、节点下线等自愈原子对故障的GPU节点进行修复；
算力平衡：如集群内存在GPU热备机，会迅速按照热备机替换规则去替换异常节点，维持集群算力平衡；
自愈记录存储：对接金山云KLog日志，存储集群内GPU节点的自愈行为、触发事件等信息；
对接第三方决策系统：除提前在集群内预置运维自愈策略，组件也支持根据节点上运行任务状态通过API实时下发自愈动作。

使用限制

支持地域：华北专属1区
集群版本：K8s 1.21及以上

前提条件

您已使用金山云容器服务创建一个正常运行的Kubernetes集群，关于如何创建集群，请参见创建集群。
（非必要条件）组件工作负载配置了亲和性策略会优先调度至CPU类型节点上，如只存在GPU类型节点当组件所在GPU节点产生异常会导致组件不可用。

使用说明

自愈流程

组件安装流程

登录容器服务控制台，在左侧导航栏中选择集群；
在集群列表中，单击目标集群名称，进入集群详情页；
选择左侧菜单栏中的组件管理，在组件管理中选择kce-gpu-error-rescue进行安装。

组件安装说明：

参数	说明	使用场景
启用第三方决策系统	在启用第三方决策系统，组件控制器将不会监听命名空间kce-rescuepolicy的Event事件，仅处理通过API传递的自愈动作。	未在集群内预置自愈运维策略，当Xid Error产生时通过API形式下发自愈运维动作；适用于您在KCE之上拥有业务平台，业务平台根据集群内的任务负载实时决策自愈运维动作。
API访问方式	当选择启用第三方决策系统后，将选择API访问方式：集群内访问：集群将创建一个ClusterIP类型的Service，通过ClusterIP:9435访问; VPC内访问：集群将创建一个内网SLB类型的Service，通过SLB IP:9435访问。	集群内访问：适用于集群内其他服务访问自愈组件服务。 VPC内访问：适用于将自愈组件服务暴露到私VPC内部访问。
存储自愈记录	使用前提：需要在容器服务-运维管理-日志管理v1给目标集群开启日志服务；说明：开启功能后，组件会自动创建日志规则，采集rescue-executor、rescue-policy两个Deployment的容器标准输出。	需要对历史自愈记录长时间存储，以便溯源。

参数

说明

使用场景

启用第三方决策系统

在启用第三方决策系统，组件控制器将不会监听命名空间kce-rescuepolicy的Event事件，仅处理通过API传递的自愈动作。

未在集群内预置自愈运维策略，当Xid Error产生时通过API形式下发自愈运维动作；
适用于您在KCE之上拥有业务平台，业务平台根据集群内的任务负载实时决策自愈运维动作。

API访问方式

当选择启用第三方决策系统后，将选择API访问方式：

集群内访问：集群将创建一个ClusterIP类型的Service，通过ClusterIP:9435访问;
VPC内访问：集群将创建一个内网SLB类型的Service，通过SLB IP:9435访问。

集群内访问：适用于集群内其他服务访问自愈组件服务。
VPC内访问：适用于将自愈组件服务暴露到私VPC内部访问。

存储自愈记录

使用前提：

需要在容器服务-运维管理-日志管理v1给目标集群开启日志服务；

说明：

开启功能后，组件会自动创建日志规则，采集rescue-executor、rescue-policy两个Deployment的容器标准输出。

需要对历史自愈记录长时间存储，以便溯源。

自愈运维策略

自愈运维策略类型

全局配置文件：作用于整个K8s集群的GPU Worker的运维自愈规则，默认启用节点封锁
- 在RescuePolicy中「priority: 0」、「errorCode、nodeSelector」不填写，代表全局配置文件
区域级配置文件：对特定的Xid或Node Label生效的运维自愈规则，仅作用于符合匹配项的GPU Worker

自愈原子说明：

操作	前置条件	说明
节点封锁	无	通过污点使节点不可调度在全局级配置文件中，默认启用节点封锁
节点排水	开启节点排水，会先执行封锁	当节点内节点上的pod存在以下场景，同样进行驱逐： pod使用本地存储存在daemonset类型pod 节点上存在静态pod 当节点内存在以下类型pod，仅将node设置为不可调度节点上存在ingress-controller pod 副本数为1的pod
设定排水时间	开启节点排水功能	即将节点设置为不可调度到开始排水时间，时间单位为s、min、h、day 0代表立即执行
排水后重启EPC	开启节点排水	当节点完成排水操作后，重启EPC，并将节点设置为不可调度状态
排水后等待重启时间	打开重启EPC功能	支持时间粒度：立即执行、s、min、h、day 0代表立即执行
重启后节点为可调度状态	打开重启EPC功能	当重启完成后，设置为可调度状态
启用集群内热备机	需打开节点封锁、节点排水、重启EPC其中之一	开启后当节点产生Xid Error将用热备机替换异常GPU Worker
优先级	无	当区域级规则配置匹配目标发生重叠时将会按照优先级高的规则执行，全局级配置文件优先级为0
xid error	无	匹配集群中返回xid信息的GPU节点同一份配置文件xid error是"或"的关系
node label匹配	无	根据Node上的Label完成匹配 nodeSelector之间的由用户定义的operator 选择是“或”还是“与”

Yaml示例：

apiVersion: rescue.ksyun.com/v1
kind: RescuePolicy
metadata:
  name: test-1
spec:
  rules:
  - priority: 10
    errorCode: ["62"]
    nodeSelector: 
      operator: "any" # 有效值any / all，表示节点需要匹配所有的labels还是任意的labels
      labels:
        app: demo
        env: test
    actions:
      - name: cordon
      - name: drain
        attribute: 
          waittime: "20min"
      - name: reboot
        attribute: 
          waittime: "20min"    
          unCordon: "true"  
  - priority: 10
    errorCode: ["63","64"]
    nodeSelector:
      operator: "any" # any / all
      labels:
        app: demo
        env: test
    actions:
      - name: cordon
      - name: drain
        attribute: 
          waittime: "20min"

启用第三方决策系统后，API传参样例：

// 创建rescue Action
请求参数：
{
  nodeName  string,
  xid  int32,
  escalateTime string,
  actions[
    {name:"cordon", waittime:"", maps[{},{},{}...]},  // 封锁操作
    {name:"drain", waittime:"10min", maps[{},{},{}...]},  // 排水操作
    {name:"reboot", waittime:"1day3h5min", maps[{},{},{}...]} // 重启操作
    ... 
    ],
}
```
有效的actions有：cordon(封锁)、drain（排水）、reboot（重启）、
enableWarmStandby（启用热备机）、unCordon（重启后取消封锁）
只有drain和reboot对应的waittime为有效设置
```

成功返回结果：
{
    "code": "Success",
    "message": "Success"
}

失败返回结果：
{
    "code": "Error",
    "message": "Exceed the maximum plans limit {%d}"
}

失败返回结果：
{
    "code": "Error",
    "message": "Failures to meet preconditions %s" // 返回详细的具体不满足哪些前置条件
}

失败返回结果：
{
    "code": "Error",
    "message": "Parameter error:%v" // 参数错误,比如nodeName不存在，WaitRestartEPCTime格式错误
}

热备机说明

规则说明

当在区域级配置文件中声明启用热备机后，会根据热备机配置规则进行热备机替换
当热备机命中热备规则，则在命中的热备机中随机选择1台进行替换
当热备机未命中热备规则，在所有热备机中随机选择1台进行替换

Yaml示例

apiVersion: rescue.ksyun.com/v1
kind: WarmStandbyPolicy
metadata:
  name: cluster-warm-standby
spec:
  matches:
    - originNode:
        env: dev
        app: demo
      targetNode:
        env: dev
        app: demo

举例验证

集群中有两个Worker节点，一台GPU裸金属服务器（10.0.2.193），一台CPU云服务器（10.0.1.226）；本次将模拟10.137.4.120产生Xid 62，自愈运维组件将对其执行封锁；

集群中存在一份仅开启封锁的区域级运维策略文件

apiVersion: rescue.ksyun.com/v1
kind: RescuePolicy
metadata:
  name: test-1
spec:
  rules:
  - priority: 10
    errorCode: ["62"]
    actions:
      - name: cordon

登录GPU节点，模拟Xid Error

[root@10-0-2-193 ~]# for i in `seq 1`; do echo "NVRM: Xid (0000:03:00): 62, Channel 00000001" >> /dev/kmsg ;done;
[root@10-0-2-193 ~]# dmesg -T | grep Xid
[四 7月  4 11:09:40 2024] NVRM: Xid (0000:03:00): 62, Channel 00000001

查看kce-rescue-system命名空间下，查看events的生成状态

root@vm10-0-1-226:~# kubectl get event -n kce-rescue-system
LAST SEEN   TYPE      REASON     OBJECT            MESSAGE
2m42s       Warning   XidError   node/10.0.2.193   当前实例发生GPU Xid错误,pci:0000:03:00,xid:62,日志: Channel 00000001

查看Node 10.0.2.193状态

root@vm10-0-1-226:~# kubectl get no
NAME       STATUS                     ROLES    AGE   VERSION
10.0.1.159   Ready                      master   33d   v1.21.3
10.0.1.226   Ready                      node     20d   v1.21.3
10.0.1.39    Ready                      master   33d   v1.21.3
10.0.1.92    Ready                      master   33d   v1.21.3
10.0.2.193   Ready,SchedulingDisabled   node     33d   v1.21.3