k8s pod 处于Terminating的原因分析和解决处理——筑梦之路

这篇具有很好参考价值的文章主要介绍了k8s pod 处于Terminating的原因分析和解决处理——筑梦之路。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

之前整理了一下各种资源长时间无法回收,解决处理的命令行

k8s 各种资源Terminationg状态处理 —— 筑梦之路_k8s自定义资源修改状态-CSDN博客

这里具体整理下pod长时间处于Terminating状态的相关知识,主要是对前面的补充和完善,作为笔记记录。

背景说明

当我们要删除一个Pod时,Kubernetes会发送删除命令,并开始删除操作。但是,Pod并不会立即被销毁。它先被放置在Terminating状态下,以便它可以完成正在进行的操作。但有时Pod会长时间停留在Terminating状态下,这可能会影响应用程序的正常运行。

常见原因

  1. Pod中有未处理完的请求或资源占用,如长时间运行的进程。
  2.  Kubelet或Kubernetes控制平面出现故障,导致无法终止Pod。
  3.  Pod中存在未正确关闭的文件描述符或套接字。

解决处理

1. 请求或资源占用

   检查确认Pod中是否有未处理完的请求或资源占用,并终止它们。

  在Pod中可能存在很多进程或服务,我们可以通过查看Pod的日志、进程列表和资源占用情况,来确定哪些进程或服务没有处理完请求或占用资源。

# 查看pod日志

kubectl logs <pod_name>

# 查看pod内进程信息

kubectl exec <pod_name> ps -ef

2. 未正确关闭的文件描述符或套接字

在Pod中可能存在文件描述符或套接字没有正确关闭的情况,这可能会导致Pod不能正常停止或销毁。我们可以通过查看Pod的日志,确认哪些进程或服务存在文件描述符或套接字没有关闭的情况。

这里操作同上,也是查看pod的日志和进程信息,就不再赘述。

3. 强制删除pod

这里就用到了之前那篇里面的命令,需要注意的是强制删除Pod可能会导致数据丢失或数据损坏。因此在进行操作之前,请确保您已经备份了相关数据。 

kubectl delete pods <pod_name> --grace-period=0 --force

    不到万不得已的情况,不建议直接强制删除pod,可以先尝试用其他处理方式来解决,这也是为了避免数据丢失或损坏。文章来源地址https://www.toymoban.com/news/detail-775687.html

到了这里,关于k8s pod 处于Terminating的原因分析和解决处理——筑梦之路的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • k8s集群namespace一直处于Terminating状态不释放解决办法

    Kubernetes中namespace有两种常见的状态,即Active和Terminating状态,其中Terminating状态一般会比较少见,当对应的命名空间下还存在运行的资源,但该命名空间被删除时才会出现所谓的Terminating状态,这种情况下只要等待Kubernetes本身将命名空间下的资源回收后,该命名空间将会被系

    2024年02月11日
    浏览(27)
  • 云原生 | k8s批量删除Evicted/Terminating/Unknown Pods

    宿主机内存被docker占满导致,K8s集群pod处于Evicted 状态,清理内存后处理Evicted和Terminating状态的pod 1、在集群查询pod状态,发现大量pod处于Evicted和Terminating状态 2.使用kubectl中的强制删除命令 3.删除非正常的pod  

    2024年02月08日
    浏览(30)
  • k8s 大量 pod 处于 ContainerStatusUnknown 状态

    如图所示,nexus 正常运行,但产生了大量的状态不明的 pod,原因也无从所知 解决办法,删除多余的 pod,一个一个删除,非常费劲 获取 namespace 中状态为 ContainerStatusUnknown 的 pod,并删除 获取所有非 Running 状态下的 pod,并删除

    2024年02月07日
    浏览(45)
  • K8S集群中Pod资源处于ImagePullBackOff状态排查思路

    ImagePullBackOff状态表示容器的镜像拉取失败,可能存在以下几点原因: 拉取镜像时间较长导致超时,从而导致镜像拉取失败,部署完Docker后,一定要添加上阿里云的镜像加速器,否则拉取镜像是非常慢的,很容易就会导致镜像拉取失败。 镜像配置有误,指定的镜像在公有仓库

    2024年02月14日
    浏览(35)
  • K8S集群中Pod资源处于CrashLoopBackOff状态排查思路

    CrashLoopBackOff状态一般都是Pod资源中的容器出现了问题,可以有以下几点原因: 容器中部署的程序存在Bug,无法正常启动,就会出现此状态,可以查询容器的启动日志,从日志中获取重要线索,逐个进行排查。 定义Pod资源时,对于Pod中的容器进行了资源限额,可能限额的资源

    2024年01月21日
    浏览(35)
  • k8s pod一直处于pending状态一般有哪些情况,怎么排查?

    一个pod一开始创建的时候,它本身就是会处于pending状态,这时可能是正在拉取镜像,正在创建容器的过程。 如果等了一会发现pod一直处于pending状态, 那么我们可以使用kubectl describe命令查看一下pod的Events详细信息。一般可能会有这么几种情况导致pod一直处于pending状态: 1、

    2024年01月17日
    浏览(43)
  • 【k8s问题定位】k8s中的pod不停的重启,定位问题原因与解决方法

    现象: running的pod,短时间内重启次数太多   定位问题方法: 查看pod日志 本次使用以下命令,解决了问题 问题原因: OOM,pod被kill掉,重启了( 内存不够用 )   查看该服务的deployment.yaml文件 发现我们deployment.yaml对服务的内存使用,做了限制 解决方法: 将limit的memory数值提高,然后

    2024年02月09日
    浏览(45)
  • k8s中的pod不停的重启,定位问题原因与解决方法

    现象: running的pod,短时间内重启次数太多   定位问题方法: 查看pod日志 本次使用以下命令,解决了问题 问题原因: OOM,pod被kill掉,重启了( 内存不够用 )   查看该服务的deployment.yaml文件 发现我们deployment.yaml对服务的内存使用,做了限制 解决方法: 将limit的memory数值提高,然后

    2024年02月15日
    浏览(56)
  • k8s主节点部署pod状态一直是pending原因排除,并彻底删除pod技巧

    一般来说,master节点是会产生一个污点,不允许部署pod的。 如果其他原因也可以使用这个命令检查状态原因 当出现类似这样问题 问题描述: Warning FailedScheduling 40s (x28 over 28m) default-scheduler 0/1 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/master: }, that the pod didn’

    2024年01月19日
    浏览(36)
  • 高并发场景下大量TCP链接处于time_wait状态原因及优化思路分析

    对一台服务器进行压测(模拟高并发场景),会发现大量 TIME_WAIT 状态的 TCP连接,连接关闭后,这些TIME_WAIT会被系统回收 一般来讲,在高并发的场景中,出现TIME_WAIT连接是正常现象,一旦四次握手连接关闭之后,这些连接也就随之被系统回收了 但是在实际高并发场景中,很

    2024年02月04日
    浏览(57)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包