K8s 日常运维故障处理，80% 你可能都遇见过！？

公众号新闻

2023-10-29 00:10

来源：https://blog.csdn.net/qq_42883074/article/details/126221693

一、ContainerCreating

这种报错其实不算报错，容器正在创建中，通常是我们配置问题导致的。

1、docker 服务问题

有一天起来有个应用说容器创建不出来，卡在 ContainerCreateing 状态，按照习惯，我们去 describe 查看事件，并没发现什么报错信息，容器本身还创建出来了。

并且通过 exec 可以登陆的，logs 日志看不了，尝试重启 node 节点上的 kube-proxy、kubelet 后依然是不可用的，重启 docker 服务后创建成功就绪，原因未查明……

2、K8s 挂载远程存储问题

这种情况通常是远程nfs、gfs等存储问题导致的，这个我们可以还原一下

举个例子：


apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: nginx  name: nginx  namespace: defaultspec:  replicas: 1  selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:      - image: nginx        imagePullPolicy: Always        name: nginx        volumeMounts:        - mountPath: /tmp/          name: www      volumes:      - name: www        nfs:          path: /nfs/web/date          readOnly: true          server: 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服务端创建要挂载的卷

上面的不一定全对，提供一个思路，存储之类的报错通常都可以从 pod 的事件信息中得到的。

3、configmap 问题

这个不是很常见，不过也出现过，在开发 PaaS 平台时，我们写应用通常要传入一些 PaaS 的变量，这个通过挂载 configmap 来获取，但因为奇奇怪怪的原因没挂上，就会出现了，或者简单点就是 cm 的名称写错了之类的。


apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: nginx  name: nginx  namespace: defaultspec:  replicas: 1  selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:      - image: nginx        imagePullPolicy: Always        name: nginx        volumeMounts:        - mountPath: /tmp/          name: www      volumes:      - name: www        configMap:           name: nginx-config


Events:  Type     Reason       Age                  From               Message  ----     ------       ----                 ----               -------  Normal   Scheduled    2m21s                default-scheduler  Successfully assigned default/nginx-59d6d76f78-2kh7n to vm-16-16-centos  Warning  FailedMount  18s                  kubelet            Unable to attach or mount volumes: unmounted volumes=[www], unattached volumes=[www kube-api-access-hvk9s]: timed out waiting for the condition  Warning  FailedMount  13s (x9 over 2m21s)  kubelet            MountVolume.SetUp failed for volume "www" : configmap "nginx-config" not found

解决方法

每个人的环境不同，解决方法也不一样，如果是自己写错了名称，改一下就OK
如果是别人开发的环境，最好找开发来看

二、ErrImagePull 或者 ImagePullBackOff

1、仓库镜像问题

这种情况一般是镜像推送流程有问题，我们做了CI/CD，但是在推送镜像时刚好赶上镜像仓库清理镜像，那么就会有部分仓库同步不到镜像，导致拉取镜像失败，简单来说就是仓库没镜像。


apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: nginx  name: nginx  namespace: defaultspec:  replicas: 1  selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:      - image: nginx:1111111111      #不存在的镜像        imagePullPolicy: Always        name: nginx        volumeMounts:        - mountPath: /tmp/          name: www      volumes:      - name: www        configMap:           name: nginx-config

2、startContainer

这个报错好久没看到了，我隐约记得是在更新二进制的docker更新崩了后出现的。

三、Pending

pending 状态其实涉及的方向有很多的这里先简单列举一下


1、 K8调度组件 scheduler 组件异常,  集群组件挂了2、 sa 没有权限或者不存在3、 用户指定的匹配节点策略有问题  (nodeselector  容忍、污点等等调度策略）      通常是应用用户标签写错了4、 节点没有足够的资源满足调度  //测试环境通常资源较小，用户软限制太大无法调度5、pv 卷问题

四、CrashLoopBackOff 或者 ERROR

这种涉及到的方向也不少，这种情况我们大多数的时候都可以通过容器日志、容器服务日志得到答案。


1、 容器服务配置有问题，导致容器服务的守护进程启动直接挂掉了，检查配置
2、容器健康检查探针检查端口不正常会杀死容器重启，
3、容器有什么启动后的操作，操作到一般发现跑不下去了，比如容器服务启动脚本里面有    //ftp 链接    //域名无法解析    //远程主机端口无法通讯等等
4、容器资源限制太小，内存软硬限制一般是1:1的  然后内存超出我们的硬限制后oom 导致容器重启报错

五、Terminating或Unknown

这种资源一般情况下都是大批量 node 节点掉线导致的，比如之前我们集群网络波动，所有 node 需要重启组件，就能看到大量的这种状态的 pod，或者说我们在删除某个 pod 时 node 节点发生了异常导致出现 1/1 Terminating 的情况，这种直接强制删除 pod 就行。

六、UnexpectedAdmissionError

说白了，就是 node 节点上磁盘满了，我们 node 写不进去日志了。

可以发现大量这种的 pod 都是来自于同一台 node 主机，登陆 node 主机将文件系统清理一下，然后批量删除掉这些 pod。


kubectl get pods -A | grep  UnexpectedAdmissionError | awk '{print("kubectl delete pod ", $2, " -n ", $1)}' | /bin/bash

七、一个误以为是 K8s 问题的 linux 问题

K8s 集群环境有一天发现有个节点掉了(notready），登陆主机发现 df -h 命令阻塞无法使用。猜测为远程挂载存储异常，但主机数量非常多，不清楚是那里的存储导致的，下面是解决方法。

还原场景


//部署nfs服务echo "/home/nfs  *(rw,async,no_root_squash)" >> /etc/exports
//启动nfssystemctl start nfs

//登陆客户端创建目录mkdir -p /tmp/test1/

//挂载nfsmount -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

可以看到 nfs 挂掉后 df -h 已经阻塞不可用了，下面我们通过 mount -l 命令去查询挂载信息：


mount -l | grep nfs

通过 mount 命令我们得知 nfs 地址是 10.0.16.16，登陆 nfs 主机重启服务恢复。

END

官方站点：www.linuxprobe.com

Linux命令大全：www.linuxcool.com

刘遄老师QQ：5604215

Linux技术交流群：2636170

（新群，火热加群中……）

想要学习Linux系统的读者可以点击"阅读原文"按钮来了解书籍《Linux就该这么学》，同时也非常适合专业的运维人员阅读，成为辅助您工作的高价值工具书！

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。

来源: qq

点击查看作者最近其他文章