tkestack／gpu-manager在k8s1.23版本之后的使用方法（k8s targetport containerport）满满干货

文章摘要

这篇文章介绍了在Kubernetes 1.23版本后，使用GPU-manage编译时遇到的问题。尽管GPU节点上显示GPU-manage的Pod实例状态为"running"，但无法为Pod获取资源，且查看日志发现容器运行时接口因超时而无法正常通信。文章指出，这与配置中默认使用的Cgroup路径（`DefaultContainerRuntimeEndpoint`）过时有关。解决方案是更新默认路径（例如将`DefaultContainerRuntimeEndpoint`从`/var/run/dockershim.sock`改为`/var/run/docker.sock`），重新编译并测试，最终在Kubernetes 1.25版本中成功解决问题。文章还提供了编译工具的建议，供用户参考。

目录异常排查编译

在1.25版本的k8s集群中部署gpu-manage时，虽然显示gpu节点上gpu-manage的pod实例都是running状态，但是给pod申领资源时，却始终找不到有资源的节点。

查看节点的详情时，返回的字段中也没有相关资源:

Allocatable:
cpu: 48
ephemeral-storage: 48294789041
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 65291520Ki
pods: 110
System Info:
Machine ID: 50ca20960ea94552bd5ef84a20ce7e47

说明并没有正确运行。

查看任意gpu-manager的pod日志，可以看到如下异常信息：

rebuild ldcache

launch gpu manager

E0426 06:17:06.729262 2384 server.go:131] Unable to set Type=notify in systemd service file?

E0426 06:17:11.731947 2384 server.go:152] can’t create container runtime manager: context deadline exceeded

说明gpu-manager和容器运行时接口通信失败了。

查看异常信息指向的代码：

…
containerRuntimeManager, err :=containerRuntime.NewContainerRuntimeManager(
m.config.CgroupDriver, m.config.ContainerRuntimeEndpoint, m.config.RequestTimeout)
if err !=nil {
klog.Errorf(“can’t create container runtime manager: %v”, err)
return err
}
klog.V(2).Infof(“Container runtime manager is running”)
…

可以看到是访问超时，这个变量的默认值定义在

const (
DefaultDriver =”nvidia”
DefaultQueryPort =5678
DefaultSamplePeriod =1
DefaultVirtualManagerPath=”/etc/gpu-manager/vm”
DefaultAllocationCheckPeriod=30
DefaultCheckpointPath =”/etc/gpu-manager/checkpoint”
DefaultContainerRuntimeEndpoint=”/var/run/dockershim.sock”
DefaultCgroupDriver =”cgroupfs”
)

可以看到这里用的运行时接口是，但是在k8s1.23版本之后，接口路径已经改为，所以修改默认之后重新编译即可。

使用既可以用源码的Makefile自动编译打包成新的镜像，但是源码的中的不一定能装上，可以改成，另外有一些依赖需要国际上的支持。

编译后的镜像在1.25版本的k8s中可以正常使用。

到此这篇关于tkestack/gpu-manager在k8s1.23版本之后的使用的文章就介绍到这了,更多相关tkestack/gpu-manager在k8使用内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:Kubernetes(k8s?1.23))安装与卸载详细教程