Kubernetes Pod故障归类与排查方法

Pod概念

  • Pod是kubernetes集群中最小的部署和管理的基本单元,协同寻址,协同调度。
  • Pod是一个或多个容器的集合,是一个或一组服务(进程)的抽象集合。
  • Pod中可以共享网络和存储(可以简单理解为一个逻辑上的虚拟机,但并不是虚拟机)。
  • Pod被创建后用一个UID来唯一标识,当Pod生命周期结束,被一个等价Pod替代时UID将重新生成。

Kubernetes Pod中最常用Docker容器运行,当然Pod也能支持其他的容器运行,比如rkt、podman等。

Kubernetes集群中的Pod可被用于以下两个主要用途:

  • 运行单个容器的Pod。“每个Pod 一个容器”模型是最常见的Kubernetes用例;在这种情况下,可以将Pod看作单个容器的包装器,并且Kubernetes直接管理Pod,而不是容器。
  • 运行多个协同工作的容器的Pod。Pod可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。这些位于同一位置的容器可能形成单个内聚的服务单元,一个容器将文件从共享卷提供给公众,而另一个单独的“挂斗”容器则刷新或更新这些文件。Pod将这些容器和存储资源打包为一个可管理的实体。

Pod控制器

控制器可以为您创建和管理多个Pod,管理副本和上线,并在集群范围内提供自修复能力。例如,如果一个节点失败,控制器可以在不同的节点上调度一样的替身来自动替换Pod。

包含一个或多个Pod的控制器一些示例包括:

  • Deployment kubernetes中最常见的控制器。用于运行无状态应用
  • Statefulset 用于运行有状态应用
  • DaemonSet 作用就像是计算机中的守护进程,它能够运行集群存储、日志收集和监控等【守护进程】

控制器通常使用您提供的Pod模块来创建它负责的Pod。

Pod故障归类


  • Pod状态 一直处于Pending
  • Pod状态 一直处于Waiting
  • Pod状态 一直处于ContainerCreating
  • Pod状态 处于ImagePullBackOff
  • Pod状态 处于CrashLoopBackOff
  • Pod状态 处于Error
  • Pod状态 一直处于Terminating
  • Pod状态 处于Unknown

Pod排查故障命令


  • kubectl get pod <pod-name> -o yaml  # 查看Pod配置是否正确
  • kubectl describe pod <pod-name>  # 查看Pod详细事件信息
  • kubectl logs <pod-name> [-c <container-name>] # 查看容器日志

Pod故障问题与排查方法



Pod 一直处于Pending状态

Pending状态意味着Pod的YAML文件已经提交给Kubernetes,API对象已经被创建并保存在Etcd当中。但是,这个Pod里有些容器因为某种原因而不能被顺利创建。比如,调度不成功(可以通过kubectl describe pod 命令查看到当前Pod的事件,进而判断为什么没有调度)。可能原因:资源不足(集群内所有的Node都不满足该Pod请求的CPU、内存、GPU等资源);HostPort已被占用(通常推荐使用Service对外开放服务端口)。

Pod 一直处于WaitingContainerCreating状态

首先还是通过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

# 查看 docker-registry Secret
$ kubectl get secrets my-secret -o yaml | grep ‘dockerconfigjson:‘ | awk ‘{print $NF}‘ | base64 -d

2、创建docker-registry类型的Secret

# 首先创建一个 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: <your-private-image>
  imagePullSecrets:
  - name: my-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 处于TerminatingUnknown状态

从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)间的通信出现了问题。

参考链接


原文地址:https://www.cnblogs.com/winnerREN/p/12131364.html

时间: 2024-10-10 17:15:27

Kubernetes Pod故障归类与排查方法的相关文章

详解 Kubernetes Pod 的实现原理

Pod.Service.Volume 和 Namespace 是 Kubernetes 集群中四大基本对象,它们能够表示系统中部署的应用.工作负载.网络和磁盘资源,共同定义了集群的状态.Kubernetes 中很多其他的资源其实只对这些基本的对象进行了组合. Pod 是 Kubernetes 集群中能够被创建和管理的最小部署单元,想要彻底和完整的了解 Kubernetes 的实现原理,我们必须要清楚 Pod 的实现原理以及最佳实践. 在这里,我们将分两个部分对 Pod 进行解析,第一部分主要会从

Python Django撸个WebSSH操作Kubernetes Pod(下)- 终端窗口自适应Resize

追求完美不服输的我,一直在与各种问题斗争的路上痛并快乐着 上一篇文章Django实现WebSSH操作Kubernetes Pod最后留了个问题没有解决,那就是terminal内容窗口的大小没有办法调整,这会导致的一个问题就是浏览器上可显示内容的区域太小,当查看/编辑文件时非常不便,就像下边这样,红色可视区域并没有被用到 RESIZE_CHANNEL 前文说到kubectl exec有两个参数COLUMNS和LINES可以调整tty内容窗口的大小,命令如下: kubectl exec -i -t

内存泄露从入门到精通三部曲之排查方法篇

内存泄露从入门到精通三部曲之排查方法篇 最原始的内存泄露测试 重复多次操作关键的可疑的路径,从内存监控工具中观察内存曲线,是否存在不断上升的趋势且不会在程序返回时明显回落.这种方式可以发现最基本,也是最明显的内存泄露问题,对用户价值最大,操作难度小,性价比极高. MAT内存分析工具 2.1 MAT分析heap的总内存占用大小来初步判断是否存在泄露 在Devices 中,点击要监控的程序. 点击Devices视图界面中最上方一排图标中的“Update Heap” 点击Heap视图 点击Heap视图

OS X升级到10.10之后使用pod出现问题的解决方法

http://blog.csdn.net/dqjyong/article/details/37958067 OS X升级到10.10之后使用pod出现问题的解决方法 分类: IOS2014-07-19 11:28 3704人阅读 评论(1) 收藏 举报 [ruby] view plaincopy 最新对mac 10.10的强大功能好奇,于是将系统升级到了10.10,结果发现使用pod出现了下面的问题: [ruby] view plaincopy /System/Library/Framework

关于日常使用Azure MySQL中遇到的连接问题以及排查方法分享

由于防火墙问题,TCP keep alive 问题,以及 MySQL 自身的参数问题这三个在使用中比较常见,所以今天就分享下自己找到的排查方法. 今天先聊一聊防火墙问题 大多数人在第一次创建 MySQL database on Azure 实例之后便开始尝试连接.但是往往遇到的结果不是连接成功而是如下图所示的错误信息: 该错误信息表明您的 IP 地址并不在 MySQL on Azure 防火墙的准入范围之内,这种设定可以在某种程度上避免设置了简单密码的生产用户遭到恶意的字典攻击,当然 Azure

zencart 前台或者后台访问空白的排查方法

首先如果后台访问空白了,可以先检查下数据库配置文件,includes/configure.php,看下数据库信息是否正确.如没有问题,看下面的排查方法: zencart v1.3.9 的排错方法 错误记录在 /cache/ 目录下,前台的错误记录文件名为 "myDebug-xxxxxx.log" ,后台的错误记录文件名为 "myDebug-adm-xxxxxxx.log" 如果需要在浏览器中显示出错误信息,执行下面的操作: 如果是前台错误,打开文件 \include

SQL Server同步复制问题排查方法

1.应用复制的命令时在订阅服务器上找不到该行 解决方法:用系统存储过程sp_browsereplcmds(返回分发数据库中存储的可读版本复制命令的结果集,并将其用作诊断工具. 此存储过程在分发服务器上对分发数据库执行) sp_browsereplcmds [ [ @xact_seqno_start = ] 'xact_seqno_start' ] [ , [ @xact_seqno_end = ] 'xact_seqno_end' ] [ , [ @originator_id = ] 'orig

nginx 502 bad故障原因及解决方法收集

如题,最近网站频繁出现502错误,简直无法正常运转,出现这种情况大多是php-cgi超时没有返回信息,或进程僵死等情况造成的.我们的nginx已经配置到极致这些都已经老早做过修改了,但现在又出然出现. 经过分析将nginx的error log打开,发现”pstream sent too big header while reading response header from upstream”这样的错误提示,查阅了一下资料,大意是nginx缓冲区有一个bug造成的,我们网站的页面消耗占用缓冲区

【转载】C++程序崩溃排查方法

windows下C++程序release版本崩溃错误排查方法. 一个你精心设计的24小时不间断运行,多线程的程序,突然运行了几个月后崩了,此问题是非常难以排查的,也是很头疼的问题. 现利用Google开源工具crashrpt与Microsoft windbg工具,解决这个问题,并分享给大家. 使用工具Crashrpt.Windbg.因为windbg这个工具很常见,暂不介绍.其中重点介绍一下crashrpt. 一.crashrpt 简介 crashrpt是一个包含能够在程序出现各种类型未处理异常时