K8S 报错笔记--持续更新

一、ContainerCreating

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

1、docker服务问题

有一天起来有个应用说容器创建不出来,卡在ContainerCreateing状态

按照习惯,我们去describe去看事件,但并没发现有什么报错信息,容器本身还创建出来了

并且通过exec 是可以登陆的,当然logs日志看不了,尝试重启node节点上的kube-proxy、kubelet后

依然是不可用的,重启docker服务后创建成功就绪, 原因未查明( ̄﹃ ̄)

2、 K8挂载远程存储问题

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

举个栗子

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  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的报错很多,比如

1、nfs  挂载报错mount failed: exit status 32 是存储nfs不存在

2、 nfs 挂载报错mount failed: exit status 1   记不清了,反正在nfs的问题,试试挂载目录或者权限吧

3、 gfs  挂载报错mount failed: exit status 32  是指 node节点上没有安装 gfs的客户端

4、 gfs 挂载报错mount failed: exit status 1  可能是我们没有在gfs服务端创建要挂载的卷

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

3、configmap 问题

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

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  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/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  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更新崩了后出现的

 解决方法

把docker和container 的文件清理掉重新安装即可
rm -rf /var/run/containerd/*
rm -rf /var/lib/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

七,一个误以为是K8问题的linux问题

 我们K8集群环境有一天发现有个节点掉了(notready)登陆主机发现df -h命令阻塞无法使用

猜测为远程挂载存储异常,但主机数量非常多,不清楚是那里的存储导致的下面是解决方法

 还原场景

//部署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

 

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

mount -l | grep nfs

 

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

 

  • 2
    点赞
  • 2
    收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:Age of Ai 设计师:meimeiellie 返回首页
评论

打赏作者

默子昂

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值