背景
今天服务器重启失败,于是去检查k8s状态,发现pod一直处于terminating状态。
多次尝试删除pod但是失败了,于是想到可能是k8s node卡住了导致接收不到kill命令。
解决方式
所以reboot k8s node,问题得到解决。
个人思考
在之前发表过了文章 http://t.csdn.cn/jyYvp 中也有相关描述,在重启Linux机器之后问题得到解决,所以我认为应该是节点故障。于是对terminating状态进行了深入的学习:
当一个 Kubernetes(k8s)Pod 处于 “Terminating”(终止)状态时,意味着该 Pod 正在被优雅地终止或删除。终止过程通常包括多个步骤,以确保 Pod 的容器正确停止并清理任何关联资源。
在终止过程中,Kubernetes 遵循一个优雅的关闭流程。Pod 终止的步骤如下:
-
终止前宽限期:当 Pod 收到终止请求时,Kubernetes 启动一个终止前的宽限期。在此期间,Pod 继续接收流量并正常运行。默认的宽限期为 30 秒,但可以进行配置。
-
终止状态:在宽限期结束后,Kubernetes 将 Pod 的状态设置为 “Terminating”(终止中)。此时,Kubernetes 向 Pod 中的每个容器发送一个终止信号(SIGTERM),指示它们开始关闭。
-
容器关闭:Pod 中的容器应该优雅地处理终止信号。在容器中运行的应用程序应该清理任何正在进行的操作,释放资源并优雅地终止。
-
终止后宽限期:一旦容器收到终止信号并开始关闭过程,Kubernetes 等待一个终止后宽限期。在此期间,Pod 仍然在集群中可见,但不会被调度进行新的工作。默认的终止后宽限期设置为五分钟。
-
Pod 删除:在终止后宽限期结束后,Kubernetes 从集群中删除该 Pod,并将其状态更改为 “Terminated”(终止)。此时,Pod 及其关联的资源(如卷)会被清理。
值得注意的是,如果容器在特定的超时时间内没有响应终止信号(默认为 30 秒),Kubernetes 将通过发送 kill 信号(SIGKILL)强制终止容器。这确保了容器在无法正常关闭时不会无限期地持续存在。
总结起来,“Terminating”(终止)状态表示一个 Pod 正在被 Kubernetes 优雅地终止和清理。