常见部署问题

部署Kubernetes集群

1.子节点加入集群失败

1.1. 子节点加入集群超时

子节点加入集群时提示超时:

[kubelet-check] Initial timeout of 40s passed.

然后报错:

timed out waiting for the condition

解决方案:执行以下命令后重新加入节点

kubeadm reset
systemctl daemon-reload
systemctl restart kubelet
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

如果还是不行,可以执行以下命令查看kubelet的日志定位问题来解决:

journalctl -xefu kubelet

1.2. 10250或其他端口占用

解决方案: 查看端口占用,然后kill相应进程

sudo netstat -ntpl | grep 10250

1.3. ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables

解决方案: 执行以下命令

echo "1" >/proc/sys/net/bridge/bridge-nf-call-iptables

1.4. token过期

解决方案: 在master节点执行:

kubeadm token create
#以上命令创建的token有效期一天,也可执行 kubeadm token create --ttl 0 创建永不失效token

在master节点执行以下命令获取ca证书sha256编码hash值:

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

然后在需要加入的子节点执行:

kubeadm -reset

最后通过新获取的token和ca证书hash值重新加入节点:

kubeadm join [master 节点 IP] --token [新的token值] --discovery-token-ca-cert-hash sha256:[新hash值]
#示例kubeadm join 10.5.26.88:6443 --token 1yuxwl.s5u8hdkun81ba3p0 --discovery-token-ca-cert-hash sha256:ef5fb3006d1764c7a018dbfbdde886d6c9322171f7d841f3d7f5434e1b12588f

2.网络插件Calico运行失败

在Kubernetes master节点完成部署后,执行

kubectl get pod -n kube-system

结果如下所示,网络插件Calico未能成功运行

NAME READY STATUS RESTARTS AGE
calico-kube-controllers-6895d4984b-dd845 0/1 ContainerCreating 0 21m
calico-node-lb7wj 0/1 Error 9 21m
coredns-5644d7b6d9-d7cs6 0/1 ContainerCreating 0 21m
coredns-5644d7b6d9-hjh4v 0/1 ContainerCreating 0 21m
etcd-umaster 1/1 Running 0 20m
kube-apiserver-umaster 1/1 Running 0 20m
kube-controller-manager-umaster 1/1 Running 0 20m
kube-proxy-jl5mw 1/1 Running 0 20m
kube-scheduler-umaster 1/1 Running 0 19m

解决方案: 执行以下命令查看网卡名称

ifconfig

然后打开dubheDeployScriptfile/k8s1.16.2-ubuntu/calico.yml文件,添加612行与网卡名称对应的值(如网卡名称为eth0,则添加eth.*)

608 # Auto-detect the BGP IP address.
609 - name: IP
610 value: "autodetect"
611 - name: IP_AUTODETECTION_METHOD
612 value: "interface=ens.*|eth.*|bond.*"

修改完成后执行该文件

kubectl apply -f calico.yml

再次执行查看Kubernetes核心组件命令,查看Calico以及其他组件是否正常运行:

kubectl get pod -n kube-system

3.coredns运行失败

当成功解决上述Calico运行失败问题后执行:

kubectl get pod -n kube-system

结果如下所示,coredns未能成功运行:

NAME READY STATUS RESTARTS AGE
calico-kube-controllers-6895d4984b-dd845 1/1 Running 0 58s
calico-node-lb7wj 1/1 Running 0 50s
coredns-5644d7b6d9-d7cs6 0/1 CrashLoopBackOff 0 23m
coredns-5644d7b6d9-hjh4v 0/1 CrashLoopBackOff 0 23m
etcd-umaster 1/1 Running 0 22m
kube-apiserver-umaster 1/1 Running 0 22m
kube-controller-manager-umaster 1/1 Running 0 22m
kube-proxy-jl5mw 1/1 Running 0 22m
kube-scheduler-umaster 1/1 Running 0 21m

执行以下命令查看coredns日志:

kubectl logs [coredns pod name] -n kube-system

报错如下:

[FATAL] plugin/loop: Loop(127.0.0.1:45282 -> :53) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting. Query: "HINFO 5436695787135005992.711726978389534035."

解决方案:将以下三个文件中的127.0.0.1主机ip循环地址删除:

/etc/resolv.conf
/run/systemd/resolve/resolv.conf
/etc/systemd/resolved.conf

然后删除旧的coredns pod:

kubectl delete pod [coredns pod name] -n kube-system

4.kube-proxy运行失败

在Kubernetes master节点,执行:

kubectl get pod -n kube-system

kube-proxy状态(STATUS)异常,即不为Running状态,如CrashLoopBackOff、Error、ImagePullBackOff等。

解决方案: 可以执行以下命令查看原因:

kubectl describe pod [kube-proxy pod名称] -n kube-system

一般常见原因为服务器存储资源不足以及存储资源不足导致的kube-proxy镜像被清理(ImagePullBackOff),请清理或扩容服务器存储, 若是镜像已被清理,可以执行以下命令重新获取镜像:

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy:v1.16.2
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy:v1.16.2 k8s.gcr.io/kube-proxy:v1.16.2

5.nvidia-device-plugin 安装后 GPU 节点没有生成对应的 Pod

解决方案: 可以执行以下命令查看原因:

kubectl describe node [节点名称] -n kube-system

找到Taints信息,显示如下:

Taints: node-role.kubernetes.io/master:NoSchedule

这情况说明该GPU节点为master节点,因为master节点默认不可调度,所以默认会打上这个污点,需要在这个节点开启调度,请执行:

kubectl taint node [节点名称] node-role.kubernetes.io/master-

6.nvidia-device-plugin Pod 运行后 GPU 节点不识别 GPU

通过以下命令查看节点信息:

kubectl describe node [节点名称] -n kube-system

找到Capacity,如下,发现没有nvidia.com/gpu信息:

Capacity:
cpu: 24
ephemeral-storage: 99688900Ki
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 65805344Ki
pods: 110

解决方案: 请检查/etc/docker/daemon.json文件配置是否正确,正确如下:

{
"registry-mirrors": ["https://6kx4zyno.mirror.aliyuncs.com"],
"exec-opts": ["native.cgroupdriver=systemd"],
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}

在Kubernetes部署脚本中,已经默认如上修改该文件,如果该文件被修改,有可能是被Harbor安装脚本覆盖所致, 你或许在该GPU节点执行了安装Harbor的脚本。如果是,那么该文件会被覆盖为如下:

{
"registry-mirrors": ["https://6kx4zyno.mirror.aliyuncs.com"],
"insecure-registries": ["https://harbor.dubhe.cn"]
}

请正确修改daemon.json文件并保留insecure-registries配置,如下所示:

{
"registry-mirrors": ["https://6kx4zyno.mirror.aliyuncs.com"],
"insecure-registries": ["https://harbor.dubhe.cn"],
"exec-opts": ["native.cgroupdriver=systemd"],
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}

然后重启Docker:

systemctl restart docker

7.nvidia-device-plugin重启后GPU节点不识别GPU

在Kubernetes master节点,执行:

kubectl describe node [GPU 节点名称]

有关GPU信息显示:nvidia.com/gpu:0

执行以下命令查看nvidia-device-plugin日志:

kubectl logs [nvidia-device-plugin pod 名称] -n kube-system

出现如下报错信息:

Could not start device plugin for 'nvidia.com/gpu' :listen unix /var/lib/kubelet/device-plugins/nvidia.sock:bind: address already in use
Could not contact Kubelet, retrying. Did you enable the device plugin feature gate?

解决方案: 该问题一般出现于nvidia-device-plugin因为意外崩溃而重启的情况(一般是由于kube-proxy运行失败导致的)。原因是 /var/lib/kubelet/device-plugins/nvidia.sock文件随着device-plugins创建(删除) 而创建(删除),如果服务意外挂掉,这个文件没有删除,然后重新再启动服务就会报错,手动删除该文件即可解决。


note

注意,以下这个问题出现于未经我们验证的部署环境中(Ubuntu18.04),仅做分享,为保证部署过程顺利进行, 请按照各部署文档要求的系统环境安装指定版本的组件!

8.无法定位包 kubelet kubeadm kubectl

在执行一键式部署脚本过程中,出现以下报错导致部署失败:

E: Unable to locate package kubelet
E: Unable to locate package kubeadm
E: Unable to locate package kubectl

解决方案:添加key:

cat https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

然后执行清理脚本后,再执行安装脚本:

bash del_kube.sh
bash k8s1.16.3.sh

部署NFS

查看 NFS 服务器上的共享目录报错

执行以下命令查看 NFS 服务器上的共享目录:

sudo showmount -e [NFS服务器IP]

报错:

clnt_create: RPC: Unknow host

解决方案: 条件允许的话直接关闭NFS服务器的防火墙:

sudo ufw disable

或者在防火墙上打开如下端口:

  • portmap 端口 111 udp/tcp;
  • nfsd 端口 2049 udp/tcp;
  • mountd 端口 "xxx" udp/tcp

其中mountd 端口为系统 RPC服务在 nfs服务启动时动态选取一个随机端口(32768--65535),可以编辑/etc/services文件在末尾添加:

mountd 1011/udp
mountd 1011/tcp

保存后执行以下命令完成手动指定固定端口:

stopsrc -s rpc.mountd
startsrc -s rpc.mountd
exportfs -a
rpcinfo -p Hostname

部署Harbor

1.执行一键式部署脚本 minio_harbor.sh 失败

如果执行过程中报错(出现于脚本执行至最后时):

Fail to generate key file: ./common/config/ui/private_key.pem, cert file: ./common/config/registry/root.crt

请修改/usr/local/harbor/prepare文件第490行:

empty_subj = "/C=/ST=/L=/O=/CN=/"
#请将其修改为
empty_subj = "/"

修改完后执行:

/usr/local/harbor/install.sh

如果因为其他原因导致安装失败,需要重新安装,请先执行del_harbor_minio.sh脚本后再执行安装脚本:

#在dubheDeployScriptfile/harbor_minio/路径下执行
chmod a+x del_harbor_minio.sh
./del_harbor_minio.sh
./minio_harbor.sh

2.部署完成后登陆失败

解决方案: 执行以下命令查看Harbor各组件运行状态是否正常:

docker ps -a | grep harbor

如果Harbor各服务状态如下,则Harbor服务已正常启动,可以执行登录:

vmware/harbor-jobservice:v1.5.0 "/harbor/start.sh" 4 weeks ago Up 11 days harbor-jobservice
vmware/harbor-ui:v1.5.0 "/harbor/start.sh" 4 weeks ago Up 2 weeks (healthy) harbor-ui
vmware/harbor-db:v1.5.0 "/usr/local/bin/dock…" 4 weeks ago Up 2 weeks (healthy) 3306/tcp harbor-db
vmware/harbor-adminserver:v1.5.0 "/harbor/start.sh" 4 weeks ago Up 2 weeks (healthy) harbor-adminserver
vmware/harbor-log:v1.5.0 "/bin/sh -c /usr/loc…" 4 weeks ago Up 2 weeks (healthy) 127.0.0.1:1514->10514/tcp harbor-log

Harbor部署完成后各组件启动需要一定的时间,一般等待一分钟左右Harbor各组件就能启动完成并就绪。


3.Harbor垃圾回收

通过web界面删除镜像只是软删除,虽然界面查询不到,但是实际上还保留在物理磁盘,此时需要到Harbor服务器执行以下命令

docker run -it --name gc --rm --volumes-from registry vmware/registry:2.6.2-photon garbage-collect /etc/registry/config.yml

部署MinIO

部署完成后MinIO容器运行失败

解决方案: 执行以下命令查看MinIo容器状态:

docker ps -a | grep minio

然后查询MinIO运行日志定位问题:

docker logs [minio容器id或名称]

MinIO运行失败原因一般为accessKey(登录名,至少4位)和secretKey(密码,至少8位)长度不符合要求,请自检。


管理集群日志

前端页面无训练日志输出

解决方案: 训练日志是由组件Fluent-bit采集输出到Elasticsearch进行存储,所以首先检查这两个组件对应的Pod是否为Running状态:

kubectl get pod -n kube-system

如果不为Running,则可以通过describe命令查看pod运行详情,定位解决问题:

kubectl describe pod [pod 名称] -n kube-system

如果这两个组件状态都为Running状态,那可以看一下Fluent-bit组件的日志:

kubectl logs [fluent-bit pod 名称] -n kube-system

报错如下:

net_tcp_fd_connect: getaddrinfo(host='elasticsearch-logging'): Temporary failure in name resolution

根据报错是Fluent-bit无法通过'elasticsearch-logging'这个服务名解析到对应服务地址,我们可以将其修改为具体IP:

#查看Elasticsearch的IP:
kubectl get svc -n kube-system
#结果如下:
#NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
#elasticsearch-logging NodePort 10.110.110.73 <none> 9200:32321/TCP 2d
#接着修改Fluent-bit相关配置:
kubectl edit daemonset fluent-bit -n kube-system
#将 FLUENT_ELASTICSEARCH_HOST 对应的 value 修改为上述步骤查询到的IP地址:
# spec:
# containers:
# - env:
# - name: TZ
# value: Asia/Shanghai
# - name: FLUENT_ELASTICSEARCH_HOST
# value: 10.110.110.73

部署分布式训练 operator

部署完成后operator组件为Pendding状态

解决方案: 执行以下命令查看Operator Pod状态详情:

kubectl describe pod [oprator pod名称] -n kube-system

如果看到以下信息:

scheduler 0/3 nodes are available: 3 node(s) didn't match node selector.

请检查主机名是否包含大写字母,如果主机名包含大写字母,请执行:

kubectl edit deployment distribute-train-operator -n kube-system

找到kubernetes.io/hostname,将值改为小写保存即可:

spec:
nodeSelector:
#<your-k8s-host-name>是部署operator的Kubernetes节点hostname
kubernetes.io/hostname: <your-k8s-host-name>

部署数据处理算法(基于Kubernetes)

1.部署完成后部分算法Pod为ContainerCreating状态

解决方案: 一般都是集群GPU显存资源不足造成的,可以查看一下机器显存占用情况:

nvidia-smi

如果显存资源紧张,请不要同时启用imagenet和annotation算法。

若要停用某一算法,可以进入/dubheDeployScriptfile/init-algorithm/目录,

目录下有各个算法对应的yaml文件,比如要停用annotation目标检测算法,则执行

kubectl delete -f algorithm-annotation.yaml
kubectl delete -f algorithm-annotation-hpa.yaml

其他算法停用同理,执行对应的yaml文件即可

如果要启用某一算法,比如现在要启用imageNet图像分类算法,则执行

kubectl apply -f algorithm-imagenet.yaml
kubectl apply -f algorithm-imagenet-hpa.yaml

note

注意,以下两个问题出现于未经我们验证的部署环境中(如不同版本的Linux系统环境,Kubernetes版本等),仅做分享,为保证部署过程顺利进行, 请按照各部署文档要求的系统环境安装指定版本的组件!

2.Ubuntu20.04算法Pod启动失败

查看日志:

kubectl logs [算法Pod名称]

出现如下报错:

Resolving tianshu.org.cn (tianshu.org.cn)... failed: Tempory failure in name resolution

因为算法容器在启动时需要下载算法包,根据报错信息显示无法解析域名,考虑是Kubernetes网络环境问题。 同时通过docker容器直接启动算法容器能够正常运行,于是执行以下命令查看网络插件Calico日志:

kubectl logs [calico pod 名称] -n kube-system

报错如下:

int_dataplane.go 1035: Kernel's RPF check is set to 'loose'. \
This would allow endpoints to spoof their IP address. \
Calico requires net.ipv4.conf.all.rp_filter to be set to 0 or 1. \
If you require loose RPF and you are not concerned about spoofing, \
this check can be disabled by setting the IgnoreLooseRPF configuration parameter to 'true'.

解决方案: Calico需要rp_filter这个内核参数的值是0或者1,但是Ubuntu20.04上默认是2,这样就会导致calico插件报上面的错误。 因此执行以下命令修改这个参数的值:

vim /etc/sysctl.d/10-network-security.conf
#将下面两个参数的值从2修改为1
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1
#然后使之生效
sudo sysctl --system

3.Kubernetes 1.20.2 环境下无法获取GPU指标

安装完成custom-metrics-apiserver后,执行一下命令无输出结果:

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq . | grep accelerator_duty_cycle

登录Prometheus也无法查询到container_accelerator_duty_cycle指标

解决方案(未验证): 原因在于Kubernetes在1.19引入并且在1.20启用了DisableAcceleratorMetrics,kubelet不再报告accelerator_duty_cycle指标,取而代 之的是需要安装NVIDIA GPU dcgm-exporter插件来采集DCGM_FI_DEV_GPU_UTIL指标。

因此,除了安装NVIDIA GPU dcgm-exporter插件外,各个算法对应的hpa.yml文件也应当更改GPU指标配置,将accelerator_duty_cycle 替换为DCGM_FI_DEV_GPU_UTIL。

Last updated on