k8s集群部分使用gpu资源的pod出现UnexpectedAdmissionError问题

最新推荐文章于 2024-04-23 19:15:00 发布
最新推荐文章于 2024-04-23 19:15:00 发布
阅读量1.9k 收藏 24
点赞数 21
文章标签： kubernetes java 容器 gpu
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_42561919/article/details/134850872
版权

记录一次排查UnexpectedAdmissionError问题的过程

1. 问题

环境

3master节点+N个GPU节点

kubelet版本：v1.19.4

kubernetes版本：v1.19.4

生产环境K8S集群，莫名其妙的出现大量UnexpectedAdmissionError状态的Pod，导致部分任务执行异常，出现这种情况时，节点的资源是足以支持运行一个GPU Pod的。

报的错误：

Allocate failed due to requested number of devices unavailable for nvidia.com/gpu. Requested: 1, Available: 0, which is unexpected

因为Pod的调度都是指定了spec.nodeName属性的，所以跳过了Pending状态强制进行调度，在资源不足的情况下，就出现了UnexpectedAdmissionError异常。

image-20231207095349410

2.排查过程

确定节点资源是否正常

 kubectl describe node <node-name>

image-20231207095740526

通过describe命令可以看到节点的GPU卡是正常的，然后可以去节点上通过nvidia-dcgm，确定GPU设备是否健康

nvidia-dcgm：nvidia官网

在确定节点和GPU设备都是没问题的情况下，那么开始排查出现问题的原因

通过查看日志和源码，可以定位到日志是在manager.go#devicesToAllocate方法的698行出现

	// resource=nvidia.com/gpu
	// Gets Devices in use.
	devicesInUse := m.allocatedDevices[resource]
	// Gets Available devices.
	available := m.healthyDevices[resource].Difference(devicesInUse)
	if available.Len() < needed {
		return nil, fmt.Errorf("requested number of devices unavailable for %s. Requested: %d, Available: %d", resource, needed, available.Len())
	}

也就是，从健康的GPU集合中去除了已使用的GPU后，可用GPU数量少于所需要的数量，但是通过上面的排查，在创建的Pod.cm.resource.limit:nvidia.com/gpu=1的情况下，理论上应该是成功的，这里出现了报错，那么肯定是GPU卡被占用了。

查看kubelet日志，定位具体问题，日志位于/var/log/messages文件，由于kubelet默认日志级别为--v=2，这里需要将其更改为--v=4

查看是否有/etc/kubernetes/kubelet.env文件，如果有，直接更改KUBE_LOG_LEVEL配置

KUBE_LOGTOSTDERR="--logtostderr=true"
KUBE_LOG_LEVEL="--v=4"

如果没有，则修改/usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf文件

添加Environment

Environment="KUBE_LOGTOSTDERR=--logtostderr=true"
Environment="KUBE_LOG_LEVEL=--v=4"

修改ExecStart命令，在参数位追加$KUBE_LOGTOSTDERR $KUBE_LOG_LEVEL

ExecStart=/usr/bin/kubelet $KUBE_LOGTOSTDERR $KUBE_LOG_LEVEL $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

修改后需要重启kubelet

systemctl daemon-reload && systemctl restart kubelet

通过grep命令查看关键日志

grep "package-instance-42895-test-4461" messages

从日志中发现，kubelet监听到了两次创建同一个Pod的事件，也就是为一个Job创建了两个Pod

但是Job的配置都是为1

spec:
  completions: 1
  backoffLimit: 0
  parallelism: 1

image-20231207102252049

在这样的配置下，应该只有一次创建Pod的事件才对。

再分别查看两次Pod的资源分配日志

通过less messages命令查看详细的日志过程

image-20231207102820350

从日志中可以看出，第一个Pod分配GPU资源是成功的

而在第二个Pod分配GPU资源时，就提示分配失败

image-20231207102934592

至此问题就定位到了，是因为kubelet本应只创建一个Pod，但是确监听到了多次创建Pod的事件。

从这个情况来看，应当所有的任务都失败才对，但只有小部分任务失败了，继续查看日志

image-20231207103436250

在下面的日志可以看到，kubelet随后就监听到了DELETE事件，删除了一个Pod，虽然在这个日志中删除的是创建失败的Pod

但是多观察几个Pod就会发现，删除完全的随机的，并不是根据状态来的，所以就会出现部分任务失败，但是大部分任务都成功的情况。

从上面的排查过程来看，kubelete、node、gpu device都是没有问题的，那么，继续往上排查scheduler

同样的，scheduler的日志级别默认也是--v=2，这里也需要改成--v=4，修改kube-scheduler.yaml文件

vim /etc/kubernetes/manifests/kube-scheduler.yaml

在command中追加一行--v=4

spec:
  containers:
  - command:
    - kube-scheduler
    - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
    - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
    - --bind-address=0.0.0.0
    - --kubeconfig=/etc/kubernetes/scheduler.conf
    - --leader-elect=false
    - --leader-elect-lease-duration=15s
    - --leader-elect-renew-deadline=10s
    - --port=0
    - --v=4

更改文件后保存，等待scheduler自动重建。注意重建后日志会清空，所以需要等待下次调度再次重新进行问题排查

然后通过kubectl logs命令，查看三个scheduler的调度日志

kubectl logs -n kube-system kube-scheduler-master-1| grep package-instance-42895-test-4461

kubectl logs -n kube-system kube-scheduler-master-2| grep package-instance-42895-test-4461

kubectl logs -n kube-system kube-scheduler-master-3| grep package-instance-42895-test-4461

[root@master-1 ~]# kubectl logs -n kube-system kube-scheduler-master-1| grep package-instance-42895-test-4461
I1206 03:23:08.641125       1 eventhandlers.go:225] add event for scheduled pod default/package-instance-42895-test-4461-xxp5t
I1206 03:23:08.641463       1 eventhandlers.go:225] add event for scheduled pod default/package-instance-42895-test-4461-72hdl
I1206 03:23:08.866294       1 eventhandlers.go:283] delete event for scheduled pod default/package-instance-42895-test-4461-72hdl

[root@master-1 ~]# kubectl logs -n kube-system kube-scheduler-master-2| grep package-instance-42895-test-4461
I1206 03:23:08.641125       1 eventhandlers.go:225] add event for scheduled pod default/package-instance-42895-test-4461-xxp5t
I1206 03:23:08.641463       1 eventhandlers.go:225] add event for scheduled pod default/package-instance-42895-test-4461-72hdl
I1206 03:23:08.866294       1 eventhandlers.go:283] delete event for scheduled pod default/package-instance-42895-test-4461-72hdl

[root@master-1 ~]# kubectl logs -n kube-system kube-scheduler-master-3| grep package-instance-42895-test-4461

从上面的日志可以看到，Pod确实被调度了两次，但是，schduler只是负责调度Pod，并不会控制Pod创建的数量。

而且，理论上，应该只有一个leader级别的schduler处于工作状态，其他两个schduler，应当是处于睡眠状态，不进行工作才对，也就说，其他的schduler不应该监听到调度事件。

虽然问题不在此，但是从这里可以发现schduler的部署是有问题的，查看schduler配置

spec:
  containers:
  - command:
    - kube-scheduler
    - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
    - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
    - --bind-address=0.0.0.0
    - --kubeconfig=/etc/kubernetes/scheduler.conf
    - --leader-elect=false
    - --leader-elect-lease-duration=15s
    - --leader-elect-renew-deadline=10s
    - --port=0
    - --v=4

在检查了三个节点的schduler配置后，发现有一个节点的schduler配置中，--leader-elect被设置成了fasle

Kubernetes的调度器可以使用leader选举来确保只有一个实例处于活跃状态，负责决策和分配Pod。一旦调度器的活跃实例失效，其他备用实例可以进行leader选举，确保集群的Pod能够被适当地调度到可用的节点上。

同样，如果多个调度器实例都设置为--leader-elect=false，它们将尝试同时管理Pod的调度决策，可能会导致混乱、资源冲突以及不一致的状态。

在这可以确定是--leader-elect=false导致的出现了多个leader级的schduler，将此配置更改为--leader-elect=true。

等待schudler重建，修复了schudler多leader的问题，但是，Pod重复调度的问题依旧没有解决，查看Pod调度调度流程

image-20231207110614916

从流程图上可以看出，创建Pod的请求，是由Job Controller发出的，在kubernetes中有很多的控制器，例如

Job Controller、Deployment Controller，这些控制器由控制平面进行管理kube-controller-manger。

结合上面schduler的可以得出结论。是在Job Controller中，发出了两次创建Pod的请求，而kube-controller-manger集群跟schduler集群一样，理论上应该只有一个leader级别的处于工作中的状态，其他两个都应该处于休眠状态。但是这里发起了两次创建请求，显然是有一个以上的leader级的kube-controller-manger，通过查看配置文件，问题跟schduler是一样的

YAML文件路径/etc/kubernetes/manifests/kube-controller-manager.yaml

有一个节点的YAML文件中--leader-elect=false，这个配置也被设置为了false，导致的出现了多个ledaer级的控制平面，从而导致Pod被多次创建。

验证方式也是同样的，通过kubectl logs命令，查看三个kube-controller-manager的监听日志，发现有两个控制平面监听到了Create Job事件，从而导致的这次问题。

kubectl logs -n kube-system  kube-controller-manager-master-1 |grep package-instance-42895-test-4461

3. 解决方案

通过修改/etc/kubernetes/manifests/kube-scheduler.yaml和/etc/kubernetes/manifests/kube-controller-manager.yaml两个YAML文件中的--leader-elect配置，将其修改为true，即可解决问题。

--leader-elect=false
有错误先debug
关注
  • 21
    点赞
  • 踩
  • 24
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
k8s集群pod经常重启问题排查总结.doc
10-29
k8s集群pod经常重启问题排查总结
Pod 的状态出现 UnexpectedAdmissionError 是什么鬼?
云原生实验室
02-08 4914
今天在排查集群一个问题时，发现相关的 pod 的状态为UnexpectedAdmissionError,在这之前从未没遇到过 pod 还有这种状态的，一脸好奇，在解决问题的过程中，发现越挖...
Spark内容分享(二十一)：字节跳动 Spark 支持万卡模型推理实践
之乎者也·的博客
01-02 1032
另一部分就是在线到离线的潮汐资源，这部分就需要将在线集群空闲的资源出借到离线集群，我们整体是基于 Virtual-Kubelet 来实现的，这部分也都是整卡资源，它的供给是随着业务高低峰起伏有一个明显的规律，在线业务低峰的时候就通过自动缩容把资源空出来，然后出借到离线集群，等到高峰时又会扩容，集群把离线 Pod 给驱逐掉，它是一个中等的隔离级别，在离线的 Pod 是要跑在同一台机器上，但是卡还是可隔离开的。另外因为这些本身就是碎片资源，需要任务的大小尺寸相对适中，不能是特别大的任务。
使用kubeadm快速部署一个K8s集群
10-26
使用kubeadm快速部署一个K8s集群，MARKDOWN格式，请使用浏览器打开，内容丰富，步骤非常详细，清晰明了，没有多少废话，都是实战总结，一步一步教您部署K8S集群。
k8s集群环境搭建资源
10-27
k8s集群环境搭建资源
bash script 脚本 awk使用print printf构建多个参数执行指令，kubectl删除所有UnexpectedAdmissionError状态pod
hknaruto的专栏
12-18 2818
基本原理，采用printf函数，格式化输入，可以取任意一个参数，取值方式$1....$n 参考1 echo abc def | awk '{printf("111 %s 222 %s", $1, $2)}' 111 abc 222 def 参考2 echo abc def | awk '{print("111", $2, "222", $2)}' 111 def 222 def 删除所有UnexpectedAdmissionError状态pod 写法1 kubectl get pods
K8S 报错笔记--持续更新
默子昂
08-08 4312
代码】K8S 报错笔记--持续更新。
最近k8s遇到的一些问题
weixin_60092693的博客
07-16 1424
仅自己学习笔记
k8s问题汇总
08-16 2460
本文章为记录使用k8s遇到的问题和解决方法，文章持续更新中…
K8S1.20.6集群监控资源镜像清单及镜像合集
01-11
原文链接：https://blog.csdn.net/m0_37814112/article/details/122170537 说明：资源列表如下 drwxr-xr-x. 7 root root 83 12月 30 11:33 alertmanager drwxr-xr-x. 3 root root 99 1月 11 14:19 grafana drwxr-xr-x 2 root root 216 1月 14 11:06 grafana-dashborard drwxr-xr-x. 5 root root 93 12月 27 17:59 kube-state-metrics drwxr-xr-x. 4 root root 90 1月 11 15:32 nfs drwxr-xr-x. 2 root root 78 1月 12 13:55 node-exporter drwxr-xr-x. 3 root root 121 1月 12 13:49 prometheus-kubernetes drwxr-xr-x. 3 root root 121 1月 12 14:18 prometheus-kube-state-metrics drwxr-xr-x. 3 root root 121 1月 12 16:01 prometheus-node-exporter drwxr-xr-x. 3 root root 121 1月 14 11:00 prometheus-ssl-exporter -rw-r--r--. 1 root root 2230 12月 27 16:51 README.txt drwxr-xr-x 4 root root 93 1月 14 09:47 ssl-exporter -rw-r--r-- 1 root root 123 1月 11 15:31 version drwxr-xr-x. 5 root root 116 1月 11 15:52 webhook-dingtalk
使用Prometheus全方位监控K8s集群
02-07
使用Prometheus全方位监控K8s集群
深入分析Kubernetes Critical Pod（三）
weixin_34194087的博客
07-01 837
本文介绍了Kubelet在Predicate Admit准入检查时对CriticalPod的资源抢占的原理，以及Priority Admission Controller对CriticalPod的PriorityClassName特殊处理。 深入分析Kubernetes Critical Pod系列：深入分析Kubernetes Critical Pod...
K8S使用GPU
不忘初心，方得始终
03-05 2925
多个pod共享一张GPU 不行。pod在创建的时候请求gpu最低是卡级别，一张显卡只能分配给一个pod。但是一个pod是由多个容器组成的，所以同一个pod的容器可以共享分配给当前pod的所有GPU。 多个docker容器共享一张GPU 可以。通过nvidia-docker启动的容器可以共享一张GPU。因为容器是进程级的程序所以分配GPU可以达到显存级。 K8S对于GPU的资源分配有两个问题 GP...
Kubernetes 集成 Nvidia GPU （详细攻略）
u013149714的博客
11-09 5645
Kubernetes 中已经实验性地支持管理多个节点上的 AMD / NVIDIA GPU (显卡)。 本文重点介绍在k8s集群中，集成Nvidia显卡容器资源调度。
Docker基础知识及坑
NeverSayNever
03-17 1949
1.实用docker工具 https://www.oschina.net/translate/50-useful-docker-tools?lang=chs&p=2
【云原生】k8s集群命令行工具kubectl之故障排除和调试命令
Lion_Long的博客
03-24 1854
所有传入数据都通过一个端口进入并转发到远程Kubernetes API服务器端口，但与静态内容路径匹配的路径除外。如果有多个pod符合条件，将自动选择一个pod。当所选pod终止时，转发会话结束，需要重新运行该命令才能恢复转发。通过访问/proc/{PID}/root 可访问到其他容器的文件系统，PID为主进程ID。调试容器内，执行ps ax可以看到包括被调试容器在内的所有进程。其他，需要为集群开启临时容器等特性功能，否则无法使用以下操作。输出 pod 中某容器的日志。连接到一个正在运行的容器。
K8S：K8S部署常见错误及解决方法
云计算之路
05-11 4423
本文主要讲解K8S在二进制部署和kubeadm部署时常见的错误以及排查思路
K8s: 控制器之ReplicaSet对象
最新发布
Wang的专栏
04-23 809
pod 是一个无状态的，并且可以被任意的按需的调度，在各个work node上运行的组件。谁来控制这类调度就变得非常复杂，不可能去手工的去维护某一个pod的一个运行实例。K8s中提供了 controller 这个概念，对于副本管理来说，有两种。如果那样的话呢，它就失去了容器的概念，就会像一个虚拟机一样去运行。RS 可以独立使用，但是也可以被 Deployment 用来协调。这个说明副本控制器就是一直在工作来维持副本运行的稳定性。新建 rep-nginx.yaml。我们可以在A窗口这个监控窗口中看到。
k8s集群断掉后会出现什么问题
06-12
当 Kubernetes 集群出现故障时，可能会出现以下问题： 1. 服务不可用：如果 Kubernetes 控制平面故障或节点故障，则可能导致服务不可用。 2. 资源不足：如果集群中的节点数量不足以容纳所有的 Pod，则可能会出现资源不足的问题。 3. 安全问题：如果 Kubernetes 集群被攻击或未得到充分保护，则可能会出现安全问题。 4. 数据丢失：如果在集群故障期间没有进行备份或恢复，则可能会导致数据丢失。 5. 系统性能下降：当 Kubernetes 集群出现故障时，可能会导致系统性能下降，例如响应时间变慢、延迟增加等问题。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值