一、ContainerCreating
这种报错其实不算报错,容器正在创建中,通常是我们配置问题导致的。
1、docker 服务问题
并且通过 exec 可以登陆的,logs 日志看不了,尝试重启 node 节点上的 kube-proxy、kubelet 后依然是不可用的,重启 docker 服务后创建成功就绪,原因未查明……
2、K8s 挂载远程存储问题
apiVersion:apps/v1kind:Deploymentmetadata:labels:app:nginxname:nginxnamespace:defaultspec:replicas:1selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-image:nginximagePullPolicy:Alwaysname:nginxvolumeMounts:-mountPath:/tmp/name:wwwvolumes:-name:wwwnfs:path:/nfs/web/datereadOnly:trueserver:192.168.1.21
这里 nfs 主机并不存在,如果直接去部署这个 yaml,会一直卡在创建中。
查看报错事件
类似 mount failed: exit status 32 的报错很多,比如:
nfs 挂载报错 mount failed: exit status 32 是存储nfs不存在
nfs 挂载报错 mount failed: exit status 1 记不清了,反正在nfs的问题,试试挂载目录或者权限吧
gfs 挂载报错 mount failed: exit status 32 是指 node节点上没有安装 gfs的客户端
gfs 挂载报错 mount failed: exit status 1 可能是我们没有在gfs服务端创建要挂载的卷
3、configmap 问题
apiVersion:apps/v1kind:Deploymentmetadata:labels:app:nginxname:nginxnamespace:defaultspec:replicas:1selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-image:nginximagePullPolicy:Alwaysname:nginxvolumeMounts:-mountPath:/tmp/name:wwwvolumes:-name:wwwconfigMap:name:nginx-config
返回
Events:TypeReasonAgeFromMessage-------------------------NormalScheduled2m21sdefault-schedulerSuccessfullyassigneddefault/nginx-59d6d76f78-2kh7ntovm-16-16-centosWarningFailedMount18skubeletUnabletoattachormountvolumes:unmountedvolumes=[www],unattachedvolumes=[wwwkube-api-access-hvk9s]:timedoutwaitingfortheconditionWarningFailedMount13s(x9over2m21s)kubeletMountVolume.SetUpfailedforvolume"www":configmap"nginx-config"notfound
解决方法
-
每个人的环境不同,解决方法也不一样,如果是自己写错了名称,改一下就OK -
如果是别人开发的环境,最好找开发来看
二、ErrImagePull 或者 ImagePullBackOff
1、仓库镜像问题
apiVersion:apps/v1kind:Deploymentmetadata:labels:app:nginxname:nginxnamespace:defaultspec:replicas:1selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-image:nginx:1111111111#不存在的镜像imagePullPolicy:Alwaysname:nginxvolumeMounts:-mountPath:/tmp/name:wwwvolumes:-name:wwwconfigMap:name:nginx-config
2、startContainer
三、Pending
pending 状态其实涉及的方向有很多的这里先简单列举一下
1、K8调度组件scheduler组件异常,集群组件挂了2、sa没有权限或者不存在3、用户指定的匹配节点策略有问题(nodeselector容忍、污点等等调度策略)通常是应用用户标签写错了4、节点没有足够的资源满足调度//测试环境通常资源较小,用户软限制太大无法调度5、pv卷问题
四、CrashLoopBackOff 或者 ERROR
1、 容器服务配置有问题,导致容器服务的守护进程启动直接挂掉了,检查配置
2、容器健康检查探针检查端口不正常会杀死容器重启,
3、容器有什么启动后的操作,操作到一般发现跑不下去了,比如容器服务启动脚本里面有
//ftp 链接
//域名无法解析
//远程主机端口无法通讯等等
4、容器资源限制太小,内存软硬限制一般是1:1的 然后内存超出我们的硬限制后oom 导致容器重启报错
五、Terminating或Unknown
六、UnexpectedAdmissionError
kubectlgetpods-A|grepUnexpectedAdmissionError|awk'{print("kubectldeletepod",$2,"-n",$1)}'|/bin/bash
七、一个误以为是 K8s 问题的 linux 问题
还原场景
//部署nfs服务
echo "/home/nfs *(rw,async,no_root_squash)" >> /etc/exports
//启动nfs
systemctl start nfs
//登陆客户端创建目录
mkdir -p /tmp/test1/
//挂载nfs
mount -t nfs 10.0.16.16:/home/nfs /tmp/test1/
//查看
df -h | grep /tmp/test1
这个前提是df -h 能用的情况下,下面演示 df -h 不可用的情况怎么查询
//停止nfs服务
systemctl stop nfs
//查看df命令
df -h
mount-l|grepnfs
通过 mount 命令我们得知 nfs 地址是 10.0.16.16,登陆 nfs 主机重启服务恢复。
来源:https://blog.csdn.net/qq_42883074/article/details/126221693