最近更新时间:2024-07-04 11:30:16
在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传递的自愈动作。 |
|
API访问方式 | 当选择启用第三方决策系统后,将选择API访问方式:
|
|
存储自愈记录 | 使用前提:
说明:
| 需要对历史自愈记录长时间存储,以便溯源。 |
全局配置文件:作用于整个K8s集群的GPU Worker的运维自愈规则,默认启用节点封锁
在RescuePolicy中 「priority: 0」、「errorCode、nodeSelector」不填写,代表全局配置文件
区域级配置文件:对特定的Xid或Node Label生效的运维自愈规则,仅作用于符合匹配项的GPU Worker
操作 | 前置条件 | 说明 |
---|---|---|
节点封锁 | 无 |
|
节点排水 | 开启节点排水,会先执行封锁 | 当节点内节点上的pod存在以下场景,同样进行驱逐:
当节点内存在以下类型pod,仅将node设置为不可调度
|
设定排水时间 | 开启节点排水功能 |
|
排水后重启EPC | 开启节点排水 | 当节点完成排水操作后,重启EPC,并将节点设置为不可调度状态 |
排水后等待重启时间 | 打开重启EPC功能 |
|
重启后节点为可调度状态 | 打开重启EPC功能 | 当重启完成后,设置为可调度状态 |
启用集群内热备机 | 需打开节点封锁、节点排水、重启EPC其中之一 | 开启后当节点产生Xid Error将用热备机替换异常GPU Worker |
优先级 | 无 | 当区域级规则配置匹配目标发生重叠时将会按照优先级高的规则执行,全局级配置文件优先级为0 |
xid error | 无 |
|
node label匹配 | 无 |
|
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"
// 创建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
Xid Error | 异常原因 | 金山云EPC处理方式 |
48 | Double Bit ECC Error(DBE)。 当 GPU 发生不可纠正的错误时,会上报 Xid48 事件。该错误也会同时反馈给用户的应用程序。 | 节点封锁 节点排水(可选) 节点重启 |
62 | Internal micro-controller halt。 GPU 内部引擎停止工作,客户业务已经受到影响。 | 节点封锁 节点排水(可选) 节点重启 |
64 | ECC page retirement or row remapper recording failure。 当应用程序遭遇到 GPU 显存硬件错误时,NVIDIA 自纠错机制会将错误的内存区域retire 或者 remap,retirement 和remapped 信息需要记录到 infoROM 中,且记录失败。 | 节点封锁 节点排水(可选) 节点重启 |
79 | GPU has fallen off the bus。 GPU 硬件检测到掉卡,无法从总线上检测到,收到此事件说明 GPU 已经出现严重硬件故障,需要下线维修。 | 节点封锁 并联系金山云售后人工处理 |
纯净模式