企业查询官方网站,网络营销策略包括哪几大策略,上海装修公司名字,上饶seo博客记录一次排查UnexpectedAdmissionError问题的过程
1. 问题
环境
3master节点N个GPU节点
kubelet版本#xff1a;v1.19.4
kubernetes版本#xff1a;v1.19.4
生产环境K8S集群#xff0c;莫名其妙的出现大量UnexpectedAdmissionError状态的Pod#xff0c;导致部分任务执…记录一次排查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异常。 2.排查过程
确定节点资源是否正常 kubectl describe node node-name通过describe命令可以看到节点的GPU卡是正常的然后可以去节点上通过nvidia-dcgm确定GPU设备是否健康
nvidia-dcgmnvidia官网
在确定节点和GPU设备都是没问题的情况下那么开始排查出现问题的原因
通过查看日志和源码可以定位到日志是在manager.go#devicesToAllocate方法的698行出现 // resourcenvidia.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/gpu1的情况下理论上应该是成功的这里出现了报错那么肯定是GPU卡被占用了。
查看kubelet日志定位具体问题日志位于/var/log/messages文件由于kubelet默认日志级别为--v2这里需要将其更改为--v4
查看是否有/etc/kubernetes/kubelet.env文件如果有直接更改KUBE_LOG_LEVEL配置
KUBE_LOGTOSTDERR--logtostderrtrue
KUBE_LOG_LEVEL--v4如果没有则修改/usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf文件
添加Environment
EnvironmentKUBE_LOGTOSTDERR--logtostderrtrue
EnvironmentKUBE_LOG_LEVEL--v4修改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: 1backoffLimit: 0parallelism: 1在这样的配置下应该只有一次创建Pod的事件才对。
再分别查看两次Pod的资源分配日志
通过less messages命令查看详细的日志过程 从日志中可以看出第一个Pod分配GPU资源是成功的
而在第二个Pod分配GPU资源时就提示分配失败 至此问题就定位到了是因为kubelet本应只创建一个Pod但是确监听到了多次创建Pod的事件。
从这个情况来看应当所有的任务都失败才对但只有小部分任务失败了继续查看日志 在下面的日志可以看到kubelet随后就监听到了DELETE事件删除了一个Pod虽然在这个日志中删除的是创建失败的Pod
但是多观察几个Pod就会发现删除完全的随机的并不是根据状态来的所以就会出现部分任务失败但是大部分任务都成功的情况。
从上面的排查过程来看kubelete、node、gpu device都是没有问题的那么继续往上排查scheduler
同样的scheduler的日志级别默认也是--v2这里也需要改成--v4修改kube-scheduler.yaml文件
vim /etc/kubernetes/manifests/kube-scheduler.yaml
在command中追加一行--v4
spec:containers:- command:- kube-scheduler- --authentication-kubeconfig/etc/kubernetes/scheduler.conf- --authorization-kubeconfig/etc/kubernetes/scheduler.conf- --bind-address0.0.0.0- --kubeconfig/etc/kubernetes/scheduler.conf- --leader-electfalse- --leader-elect-lease-duration15s- --leader-elect-renew-deadline10s- --port0- --v4更改文件后保存等待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
[rootmaster-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[rootmaster-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[rootmaster-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-address0.0.0.0- --kubeconfig/etc/kubernetes/scheduler.conf- --leader-electfalse- --leader-elect-lease-duration15s- --leader-elect-renew-deadline10s- --port0- --v4在检查了三个节点的schduler配置后发现有一个节点的schduler配置中--leader-elect被设置成了fasle
Kubernetes的调度器可以使用leader选举来确保只有一个实例处于活跃状态负责决策和分配Pod。一旦调度器的活跃实例失效其他备用实例可以进行leader选举确保集群的Pod能够被适当地调度到可用的节点上。
同样如果多个调度器实例都设置为--leader-electfalse它们将尝试同时管理Pod的调度决策可能会导致混乱、资源冲突以及不一致的状态。
在这可以确定是--leader-electfalse导致的出现了多个leader级的schduler将此配置更改为--leader-electtrue。
等待schudler重建修复了schudler多leader的问题但是Pod重复调度的问题依旧没有解决查看Pod调度调度流程 从流程图上可以看出创建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-electfalse这个配置也被设置为了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-44613. 解决方案
通过修改/etc/kubernetes/manifests/kube-scheduler.yaml和/etc/kubernetes/manifests/kube-controller-manager.yaml两个YAML文件中的--leader-elect配置将其修改为true即可解决问题。
--leader-electfalse
