Pod一直处于Pending状态怎么办
Pod处于Pending状态, 一般来讲意味着它尚未被调度至适宜的节点之上 , 较为常见的缘由为节点资源匮乏 , 像是CPU或者内存不太够用, 你能够使用kubectl describe pod。就去查看Events字段, 在那里面会确切地告知你究竟是不是"Insufficient cpu"或者"Insufficient memory"这种情况。要是资源真的是不够这样子, 那么要么去进行扩容节点的操作, 要么也可以去调整Pod的资源请求量。
还有一个常被忽略掉的因由便是PVC并非处于绑定状态, 也就是持久卷声明未绑定。要是Pod挂载着存储卷, 然而PVC却始终长期处于Pending状态, 即便如此Pod也还是会被卡住。要检测审核PVC状态可以借助kubectl get pvc这一指令去作查看确认, 以此来判断究竟是不是StorageClass已然不存在或者PV数量缺少不足了。千万要记得去确认核查存储类是不是配置无误正确正常化的, 有的时候仅仅只是拼写出现错误失误偏差一下也都有可能会致使绑定遭遇失败状况境地的。
另外存在这样一类状况, 即节点亲和性或者污点容忍度安排得并不妥善。举例来说, 倘若你为节点添加了污点, 然而Pod却未增添与之相应的容忍度, 那么调度器便会直接跨越该节点。在进行排查之时, 首先要查看节点是否存在污点, 可通过kubectl describe node来操作。进而再去检查Pod的spec当中是否设定了tolerations。
ImagePullBackOff怎么解决
存在这样一个错误, 它意味着K8s在进行镜像拉取操作的时候失败了。首先去确认一下镜像名是不是准确书写的, 有时候是有少写一个冒号的情况, 又或者tag被写成了latest , 然而实际上并不存在这样的tag。使用kubectl describe pod去查看Events , 要是出现了"manifest not found"或者"not found"这样的报错, 大概就是镜像名又或者版本号出差错了?
倘若镜像处于私有仓库之中的话, 那就还需要一并检查ImagePullSecrets是不是配置得准确无误。通常的做法是, 首先去创建一个属于docker-registry类型的Secret , 接着在Pod的spec里借助imagePullSecrets对其加以引用。可千万不要忘记去确认Secret所处的命名空间与Pod保持一致, 不然在拉取的时候就会给出"authentication required"这样的提示。
经常因网络问题致使拉取失败, 要是集群节点不能够访问外网, 或者registry域名解析不成功, Pod会反复进行重试直至超时, 可尝试在节点上手动实施docker pull看能否拉取下来, 倘若不行, 那就得检查节点的DNS配置、代理设置, 或是改用内网镜像仓库。
CrashLoopBackOff如何排查
Pod反复重新启动进入到CrashLoopBackOff状态, 一般是由于容器内部的进程开启之后又立刻退出。首先查看日志: kubectl logs。之前的那个, 借助它能够获取到上一回退出时所产生的日志，在诸多情形之下, 错误信息恰恰隐匿于其内。
