Kubernetes Pod Hook

最新推荐文章于 2025-07-24 14:13:24 发布
原创 最新推荐文章于 2025-07-24 14:13:24 发布 · 1.2k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍了Kubernetes Pod的Hook机制，包括PostStart和PreStop钩子，用于实现Pod的优雅停止。PostStart钩子在容器启动后执行，PreStop钩子在容器终止前执行，用于资源部署、环境准备和应用优雅关闭。文中还通过实例演示了如何配置和使用这两个钩子，并讨论了Pod终止过程和可能遇到的问题。

Kubernetes Pod Hook

原文:https://i4t.com/4424.html
image_1dpi1lkurv0t15bq1vnut5h1k1l13.png-8.7kB

首先我们先简单的分析一下"优雅的停止Pod"

优雅停止(Graceful shutdown)这个说法来自于操作系统，比如我们windows关机系统首先会退出软件然后一步步到达关机，而相对的就是硬终止(Hard shutdown)，简单的理解就是直接拔电源

到了微服务中，网关会把流量分配给每个Pod节点上，比如我们上线更新Pod的时候

  • 如果我们直接将Pod杀死，那这部分流量就无法得到正确处理，会影响部分用户，通常来说网关或者注册中心会将我们的服务保持一个心跳，过了心跳超时之后会自动摘除我们的服务，但是有一个问题就是超时时间可能是30秒也可能是60秒，虽然不会影响我们的系统，但是会产生用户轻微抖动。
  • 如果我们在停止前执行一条命令，通知网关或者注册中心这台主机进行下线，那么注册中心就会标记这台主机已经下线，不进行流量转发，用户就不会有任何影响，这就是优雅停止，将滚动更新影响最小化

Pod Hook

Pod Hook是由kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。我们可以同时为Pod中的所有容器都配置hook

在k8s中，理想的状态是pod优雅释放，并产生新的Pod。但是并不是每一个Pod都会这么顺利

  • Pod卡死，处理不了优雅退出的命令或者操作
  • 优雅退出的逻辑有BUG，陷入死循环
  • 代码问题，导致执行的命令没有效果
最低0.47元/天 解锁文章
k8s Pod 的终止
duolatech
09-12 754
启动 Pod 的体面关闭逻辑的同时，控制平面会评估是否将关闭的 Pod 从对应的 EndpointSlice（和端点）对象中移除，过滤条件是 Pod 被对应的服务以某 选择算符选定。任何正在终止的 Pod 所对应的端点都不会立即从 EndpointSlice 中被删除，EndpointSlice API（以及传统的 Endpoints API）会公开一个状态来指示其处于 终止状态。当你请求删除某个 Pod 时，集群会记录并跟踪 Pod 的体面终止周期， 而不是直接强制地杀死 Pod。会触发强制关闭过程。
九、Kubernetes Pod生命周期 钩子 pod hook
qq_46654855的博客
08-10 588
默认：K8S 通知 node 执行docker stop命令，docker 会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认超时时间（30s），会继续发送SIGKILL的系统信号强行 kill 掉进程。Kubernetes 为我们的容器提供了生命周期钩子，就是我们说的Pod Hook，Pod Hook 是由 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。...
k8s如何优雅地关闭Pod
运维@小兵的博客
07-20 7349
优雅地关闭Pod
k8s中终止某个pod
ajax_beijing_java的博客
08-08 1456
宽限期倒计时结束后，这些进程将收到强制终止的KILL信号，pod对 象随即也将由api server删除，如果在等待进程终止的过程中，kubelet或容器管理器发生了重启，那么 终止操作会重新获得一个满额的删除宽限期并重新执行删除操作。默认情况下，所有删除操作的宽限期都是30s，不过，kubectl delete命令可以使用“--grace-period=”选 项自定义其时长，若使用0值则表示直接强制删除指定的资源，不过此时需要同时使用命令“--forece”选 项。1. 用户发送删除pod对象的命令。
k8s pod的终止过程
学亮编程手记
11-07 986
5、endpoint控制器监控到pod对象的关闭行为时将其从所有匹配到此endpoint的server资源endpoint列表中删除；6、如果当前pod对象定义了preStop钩子处理器，则在其被标记为terminating后会意同步的方式启动执行；2、apiserver中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead；8、宽限期结束后，若pod中还存在运行的进程，那么pod对象会收到立即终止的信息；1、用户向apiserver发送删除pod对象的命令；
K8s中的pod的终止过程
荣山的博客
10-06 4805
K8s中的pod的终止过程
深入理解Kubernetes Pod生命周期：从创建到终止的全过程解析
pengdott的专栏
07-24 737
在Kubernetes中，Pod是最小的可部署计算单元，理解Pod的生命周期对于构建可靠、可维护的Kubernetes应用至关重要。本文将深入探讨Pod从创建到终止的完整生命周期，包括各个阶段的细节、核心机制以及相关的源码分析
【4】Kubernetes pod资源
bbj1030的博客
04-29 413
容器与pod资源对象 为什么Kubernetes要引入pod的概念，而不直接操作Docker容器 首先我们要明确一个概念，Kubernetes并不是只支持Docker这一个容器运行时，通过我的另一篇文章什么是Kubernetes的CRI-容器运行时接口介绍的内容，我们知道Kubernetes通过CRI这个抽象层，支持除Docker之外的其他容器运行时，比如rkt甚至支持客户自定义容器运行时。 第一个原因：借助CRI这个抽象层，使得Kubernetes不依赖于底层某一种具体的容器运行时实现技术，而是直接操作
k8s pod如何停止（不删除）
热门推荐
swindy博客
04-20 1万+
问题描述 用户咨询 k8s上正在运行的pod 如何对它进行停止操作（不删除） 解决方案 将pod进行缩容操作 让其为0 即等同于停止操作 kubectl scale --replicas=0 deployment/<your-deployment>
K8s Pod优雅关闭，没你想象的那么简单！
关注微信公众号【开源Linux】，后台回复『10T』，领取10T学习资源大放送，涵盖Linux、虚拟化、容器、云计算、网络、Python、Go等书籍和视频
09-27 2446
更新部署服务时，旧的 Pod 会终止，新 Pod 上位。如果在这个部署过程中老 Pod 有一个很长的操作，我们想在这个操作成功完成后杀死这个 pod（优雅关闭），如果无法做到的话，被杀死的...
k8s 终止pod
ajax_beijing_java的博客
08-08 635
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod。livenessProbe: #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可。
Kubernetes（K8S）POD如何退出
雪辉博客
05-25 2029
总之，Pod 中的进程必须正确处理接收到的信号，以实现优雅的退出。终止超时：如果在 Termination Grace Period结束之前进程仍然未退出，Kubernetes 将发送 SIGKILL 信号（9号信号）给进程，强制终止进程。信号发送：在 Termination Grace Period 内，Kubernetes 会向 Pod 中的主进程发送 SIGTERM 信号（15号信号），用于请求进程进行优雅的退出。进程处理：进程收到 SIGTERM 信号后，根据进程的信号处理方式进行处理。
k8s 生命周期 优雅关闭pod
从不背锅的运维
03-30 3017
如何利用termination GracePeriodSeconds 优雅地关闭你的服务 当涉及到分布式系统,处理故障是关键。Kubernetes通过利用可以监视系统状态并重新启动已停止执行的服务的控制器（controllers）来解决这个问题。另一方面，Kubernetes通常可以强制终止您的应用程序，作为系统正常运行的一部分。 在容器出现之前，大多数应用运行在虚拟机或者物理机上。如果应用程序崩溃，启动替换程序需要很长时间。如果您只有一台或两台机器来运行应用程序，那么这种恢复时间是不可接受的。 相反，在崩
k8s pod 优雅的删除
qq_36270681的博客
09-10 1398
如果有10个副本，现在业务没那么繁忙，低于我负载的50%了，开始缩容，缩容的过程中，肯定也有业务和请求在这些被缩容的pod上，那现在缩容就可能导致我线上出现问题，调用被强制终止，接口会产生一些404，网关502的问题 还有滚动更新的时候，发布新的版本，老的pod会终止，新的pod 产生，如果在这个过程中，老pod有一个很长的操作，如数据库的，或者定时任务之类的，如果这个时候我们杀死这个pod,就一定会丢失一定的流量 当 Kubernetes 杀死一个 pod 时，会发生以下 5 个步骤： 1、 Pod
k8s优雅终止pod
weixin_45112997的博客
04-25 1801
k8s优雅终止pod
在K8S中，Pod优雅终止过程是什么？
努力变的更强
12-22 661
在K8S中，Pod的优雅终止过程是一个有序的过程，旨在确保Pod中运行的应用程序能够平滑关闭，释放资源，并尽可能减少因突然关闭带来的数据丢失和服务中断。
Kubernetes 中如何保证优雅地停止 Pod丨TiDB 应用实践
weixin_42241611的博客
04-14 1211
一直以来我对优雅地停止 Pod 这件事理解得很单纯：不就利用是做优雅退出吗？但最近发现很多场景下 PreStop Hook 并不能很好地完成需求，这篇文章就简单分析一下“优雅地停止 Pod”这回事儿。
k8s暂时停掉/挂起pod
qq_38359135的博客
12-17 2928
可以在删除pod的时候删掉pod对应的镜像。
kubernetes的pod的所有状态
最新发布
08-20
Kubernetes 中的 Pod 是系统中最小的部署单元，其生命周期会经历多个状态（Phase）和更详细的容器级别状态（Container Status）。以下是对 Kubernetes Pod 所有可能状态的详细说明： ### Pod 的生命周期状态（Phase） Pod 的状态（Phase）描述了其在整个生命周期中的宏观运行情况，主要包括以下几种： - **Pending**：Pod 已被 Kubernetes 系统接受，但其包含的容器尚未全部创建。这通常表示 Pod 正在调度或镜像正在拉取中。 - **Running**：Pod 已被调度到某个节点上，并且所有容器都已被创建。至少有一个容器正在运行或处于重启、启动状态。 - **Succeeded**：Pod 中的所有容器都已成功终止并不会再重启。这通常适用于完成任务后退出的 Job 类型工作负载。 - **Failed**：Pod 中至少有一个容器以非正常状态终止。这可能是因为容器退出码非零或被系统强制终止。 - **Unknown**：由于某些原因（如节点失联），Pod 的状态无法被获取，此时其状态为 Unknown。 ### 容器级别的状态（Container Status） 除了 Pod 的整体 Phase 外，每个容器的状态也提供了更详细的运行信息： - **Waiting**：表示容器尚未准备好启动。可能的原因包括： - `CrashLoopBackOff`：容器退出，kubelet 正在尝试重启。 - `ImagePullBackOff`：正在重试拉取镜像。 - `ErrImagePull`：拉取镜像失败。 - `InvalidImageName`：无法解析镜像名称。 - `ImageInspectError`：无法校验镜像。 - `CreateContainerConfigError`：无法创建 kubelet 使用的容器配置。 - `CreateContainerError`：创建容器失败。 - `RunContainerError`：启动容器失败。 - `PreStartHookError`：执行 preStart hook 报错。 - `PostStartHookError`：执行 postStart hook 报错。 - **Running**：表示容器正在正常运行。 - **Terminated**：表示容器已经终止。可能的原因包括： - `Completed`：容器正常退出，任务完成。 - `Error`：容器因错误退出。 - `OOMKilled`：容器因内存不足被杀死。 - `ContainerCannotRun`：容器无法运行。 ### 特定节点与系统级别的状态 在某些情况下，Pod 的状态可能受到节点或系统层面的影响： - **Evicted**：当节点资源不足（如内存或磁盘压力）时，Kubernetes 可能会驱逐该节点上的部分 Pod。 - **NetworkPluginNotReady**：网络插件未准备好，导致 Pod 无法正常通信。 - **DockerDaemonNotReady**：Docker 守护进程未就绪，导致容器无法启动。 - **Terminating**：Pod 正在被终止，尚未完全停止。 ### 初始化容器状态 对于包含初始化容器（Init Containers）的 Pod，还可能出现以下状态： - **PodInitializing**：Pod 正在初始化阶段。 - **ContainersNotInitialized**：初始化容器尚未完成。 - **ContainersNotReady**：容器尚未准备好（如探针未通过）。 - **ContainerCreating**：容器正在创建中。 这些状态可以帮助运维人员和开发者更好地理解 Pod 的运行状况，并进行故障排查。 ### 示例：查看 Pod 状态 可以通过以下命令查看 Pod 的状态信息： ```bash kubectl describe pod <pod-name> ``` 输出中将包含 Pod 的 Phase 和每个容器的状态信息。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值