Kubernetes Pod故障归类与排查方法
2021-05-01 08:27
标签:llb man 异常 单元 过程 打包 etcd 用途 bash Kubernetes Pod中最常用Docker容器运行,当然Pod也能支持其他的容器运行,比如rkt、podman等。 Kubernetes集群中的Pod可被用于以下两个主要用途: 控制器可以为您创建和管理多个Pod,管理副本和上线,并在集群范围内提供自修复能力。例如,如果一个节点失败,控制器可以在不同的节点上调度一样的替身来自动替换Pod。 包含一个或多个Pod的控制器一些示例包括: 控制器通常使用您提供的Pod模块来创建它负责的Pod。 Pod 一直处于Pending状态 Pending状态意味着Pod的YAML文件已经提交给Kubernetes,API对象已经被创建并保存在Etcd当中。但是,这个Pod里有些容器因为某种原因而不能被顺利创建。比如,调度不成功(可以通过kubectl describe pod 命令查看到当前Pod的事件,进而判断为什么没有调度)。可能原因:资源不足(集群内所有的Node都不满足该Pod请求的CPU、内存、GPU等资源);HostPort已被占用(通常推荐使用Service对外开放服务端口)。 Pod 一直处于Waiting或ContainerCreating状态 首先还是通过kubectl describe pod 命令查看当前Pod的事件。可能的原因有: 1、镜像拉取失败,比如镜像地址配置错误、拉取不了国外镜像源(gcr.io)、私有镜像密钥配置错误、镜像太大导致拉取超时(可以适当调整kubelet的-image-pull-progress-deadline和-runtime-request-timeout选项)等。 2、CNI网络错误,一般需要检查CNI网络插件的配置,比如:无法配置Pod网络、无法分配IP地址。 3、容器无法启动,需要检查是否打包了正确的镜像或者是否配置了正确的容器参数 4、Failed create pod sandbox,查看kubelet日志,原因可能是磁盘坏道(input/output error)。 Pod 一直处于ImagePullBackOff状态 通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。这种情况可以使用docker pull来验证镜像是否可以正常拉取。 如果私有镜像密钥配置错误或没有配置,按下面检查: 1、查询docker-registry类型的Secret 2、创建docker-registry类型的Secret Pod 一直处于CrashLoopBackOff状态 此状态说明容器曾经启动了,但又异常退出。这时可以先查看一下容器的日志。 通过命令 kubectl logs 和 kubectl logs --previous 可以发下一些容器退出的原因,比如:容器进程退出、健康检查失败退出;此时如果还未发现线索,还而已到容器内执行命令(kubectl exec cassandra - cat /var.log/cassandra/system.log)来进一步查看退出原因;如果还是没有线索,那就需要SSH登录该Pod所在的Node上,查看Kubelet或者Docker的日志进一步排查。 Pod 处于 Error 状态 通常处于Error状态说明Pod启动过程中发生了错误。常见的原因:依赖的ConfigMap、Secret或PV等不存在;请求的资源超过了管理员设置的限制,比如超过了LimitRange等;违反集群的安全策略,比如违反了PodSecurityPolicy等;容器无法操作集群内的资源,比如开启RDAC后,需要为ServiceAccount配置角色绑定。 Pod 处于Terminating或Unknown状态 从v1.5开始,Kubernetes不会因为Node失联而删除其上正在运行的Pod,而是将其标记为Terminating 或 Unknown 状态。想要删除这些状态的Pod有三种方法: 1、从集群中删除Node。使用公有云时,kube-controller-manager会在VM删除后自动删除对应的Node。而在物理机部署的集群中,需要管理员手动删除Node(kubectl delete node)。 2、Node恢复正常。kubelet会重新跟kube-apiserver通信确认这些Pod的期待状态,进而再决定删除或者继续运行这些Pod。用户强制删除,用户可以执行(kubectl delete pods pod-name --grace-period=0 --force)强制删除Pod。除非明确知道Pod的确处于停止状态(比如Node所在VM或物理机已经关机),否则不建议使用该方法。特别是StatefulSet 管理的Pod,强制删除容易导致脑裂或数据丢失等问题。 3、Pod行为异常,这里所说的行为异常是指Pod没有按预期的行为执行,比如没有运行podSpec 里面设置的命令行参数。这一般是podSpec yaml文件内容有误,可以尝试使用 --validate 参数重建容器,比如(kubectl delete pod mypod 和 kubectl create --validate -f mypod.yaml);也可以查看创建后的podSpec是否是对的,比如(kubectl get pod mypod -o yaml);修改静态Pod的Manifest后未自动重建,kubelet 使用inotify 机制检测 /etc/kubernetes/manifests 目录(可通过 kubelet 的 -pod-manifest-path 选项指定)中静态Pod的变化,并在文件发生变化后重新创建相应的 Pod。但有时也会发现修改静态Pod的 Manifest后未自动创建新 Pod的情景,此时已过简单的修复方法是重启 Kubelet。 Unknown 这个异常状态意味着Pod的状态不能持续地被 kubelet汇报给 kube-apiserver,这很有可能是主从节点(Master 和 Kubelet)间的通信出现了问题。 Kubernetes Pod故障归类与排查方法 标签:llb man 异常 单元 过程 打包 etcd 用途 bash 原文地址:https://www.cnblogs.com/winnerREN/p/12131364.htmlPod概念
Pod控制器
Pod故障归类
Pod排查故障命令
Pod故障问题与排查方法
# 查看 docker-registry Secret
$ kubectl get secrets my-secret -o yaml | grep ‘dockerconfigjson:‘ | awk ‘{print $NF}‘ | base64 -d
# 首先创建一个 docker-registry 类型的 Secret
$ kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
# 然后在 Deployment 中引用这个 Secret
spec:
containers:
- name: private-reg-container
image:
参考链接
上一篇:代码解读 Aittala_ECCV18_Burst Image Deblurring Using Permutation Invariant Convolutional Neural Networks
下一篇:PHP静态化
文章标题:Kubernetes Pod故障归类与排查方法
文章链接:http://soscw.com/index.php/essay/80780.html