在1.25版本的k8s集群中部署gpu-manage時，雖然顯示gpu節(jié)點上gpu-manage的pod實例都是running狀態(tài)，但是給pod申領tencent.com/vcuda-memory資源時，卻始終找不到有資源的節(jié)點。
查看節(jié)點的詳情時，返回的allocatable字段中也沒有相關資源:

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

說明gpu-manager并沒有正確運行。

排查

查看任意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")
...

可以看到是訪問m.config.ContainerRuntimeEndpoint超時，這個變量的默認值定義在cmd/manager/options/options.go

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"
)

可以看到這里用的運行時接口是/var/run/dockershim.sock，但是在k8s1.23版本之后，接口路徑已經(jīng)改為/var/run/cri-dockerd.sock，所以修改默認之后重新編譯即可。

編譯

使用make img既可以用源碼的Makefile自動編譯打包成新的鏡像，但是源碼的/home/zp/work/gpu-manager/build/Dockerfile中的git222不一定能裝上，可以改成git，另外有一些依賴需要國際上的支持。
編譯后的鏡像在1.25版本的k8s中可以正常使用。

到此這篇關于tkestack/gpu-manager在k8s1.23版本之后的使用的文章就介紹到這了,更多相關tkestack/gpu-manager在k8使用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: