服务器之家:专注于服务器技术及软件下载分享
分类导航

服务器资讯|IT/互联网|云计算|区块链|软件资讯|操作系统|手机数码|百科知识|免费资源|头条新闻|

服务器之家 - 新闻资讯 - 云计算 - K8s 日常运维故障处理,80%你可能都遇见过?

K8s 日常运维故障处理,80%你可能都遇见过?

2023-10-12 12:00未知服务器之家 云计算

一、ContainerCreating 这种报错其实不算报错,容器正在创建中,通常是我们配置问题导致的。 1、docker 服务问题 有一天起来有个应用说容器创建不出来,卡在 ContainerCreateing 状态, 按照习惯,我们去 describe 查看事件,并没发现什么

一、ContainerCreating

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

1、docker 服务问题

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

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

2、K8s 挂载远程存储问题

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

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,会一直卡在创建中。

K8s 日常运维故障处理,80%你可能都遇见过?

查看报错事件

类似 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: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

    K8s 日常运维故障处理,80%你可能都遇见过?

    返回

    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、仓库镜像问题

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

    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

    K8s 日常运维故障处理,80%你可能都遇见过?

    K8s 日常运维故障处理,80%你可能都遇见过?

    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。

      kubectlgetpods-A|grepUnexpectedAdmissionError|awk'{print("kubectldeletepod",$2,"-n",$1)}'|/bin/bash

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

      K8s 集群环境有一天发现有个节点掉了(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

        K8s 日常运维故障处理,80%你可能都遇见过?

        这个前提是df -h 能用的情况下,下面演示 df -h 不可用的情况怎么查询

          
          //停止nfs服务
          
          systemctl stop nfs
          
          
          
          //查看df命令 df -h

          K8s 日常运维故障处理,80%你可能都遇见过?

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

          mount-l|grepnfs

          K8s 日常运维故障处理,80%你可能都遇见过?

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

          K8s 日常运维故障处理,80%你可能都遇见过?


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


          延伸 · 阅读

          精彩推荐