在Kubernetes中，Pod中的preStop和postStart是容器的生命周期钩子，它们可以在容器终止之前或容器启动之后执行特定的操作。
Kubernetes 支持 postStart 和 preStop 事件。 当一个容器启动后，Kubernetes 将立即发送 postStart 事件；在容器被终结之前， Kubernetes 将发送一个 preStop 事件。
这是我们实现 Kubernetes 集群零停机时间更新的第二部分。在本系列的第一部分中，我们列举出了简单粗暴地使用kubectl drain 命令清除集群节点上的 Pod 的问题和挑战。在这篇文章中，我们将介绍解决这些问题和挑战的手段之一：优雅地关闭 Pod。
SIGTERM（信号 15）在基于 Unix 的操作系统（如 Linux）中用于终止进程。SIGTERM 信号提供了一种优雅的方式来终止程序，使其有机会准备关闭并执行清理任务，或者在某些情况下拒绝关闭。Unix/Linux 进程可以以多种方式处理 SIGTERM，包括阻塞和忽略。
优雅停止(Graceful shutdown) 这个说法来自于操作系统，我们执行关机之后都得 OS 先完成一些清理操作，而与之相对的就是硬中止(Hard shutdown)，比如拔电源。
优雅关闭：在关闭前，执行正常的关闭过程，释放连接和资源，如我们操作系统执行 shutdown。
Pod 销毁时，会停止容器内的进程，通常在停止的过程中我们需要执行一些善后逻辑，比如等待存量请求处理完以避免连接中断，或通知相关依赖进行清理等，从而实现优雅终止目的。本文介绍在 Kubernetes 场景下，实现容器优雅终止的最佳实践。
当涉及到分布式系统,处理故障是关键。Kubernetes通过利用可以监视系统状态并重新启动已停止执行的服务的控制器（controllers）来解决这个问题。另一方面，Kubernetes通常可以强制终止您的应用程序，作为系统正常运行的一部分。
原文： http://yunke.science/2018/04/15/k8s-hook/
K8S自身带有优雅终止Pod容器的机制，发送SIGTERM终止信号，在规定的terminationGracePeriodSeconds优雅时间内完成Pod优雅终止动作。
以下为使用 Annotation 标明使用优雅停机示例，完整 Service Annotation 说明可参见 Service Annotation 说明。
一直以来我对优雅地停止 Pod 这件事理解得很单纯：不就利用是 PreStop hook 做优雅退出吗？但最近发现很多场景下 PreStop Hook 并不能很好地完成需求，这篇文章就简单分析一下“优雅地停止 Pod”这回事儿。
公司某服务接入效能平台后，发布过程中，页面偶尔会出现5003报错，开始以为是Nacos没有及时的将服务反注册，即POD在已经正常关闭的情况下，注册中心依然有POD信息，请求依然到已经关闭的POD中导致
这是实现「 Kubernetes 集群零停机时间更新」系列文章的第三部分。在本系列的第二部分中，我们通过利用 Pod 生命周期钩子实现了应用程序Pod的正常终止，从而减轻了由于 Pod 未处理完已存请求而直接关机而导致的停机时间。但是，我们还了解到，在启动关闭序列后，Pod 会拒绝为新到来的流量提供服务，但实际情况是 Pod 仍然可能会继续接收到新流量。这意味着最终客户端可能会收到错误消息，因为它们的请求被路由到了不再能为流量提供服务的Pod。理想情况下，我们希望 Pod 在启动关闭后立即停止接收流量。为了减轻这种情况，我们必须首先了解为什么会发生Pod开始关闭时仍然会接收到新流量这个问题。
PS：为了掩饰所以提供了挂载方便查看删除后的优雅处理输出了一段话，但是实际的生产中最好的方式就是关闭容器的服务。PostStart 和 PreStop的使用方法其实不难。k8s都是命令的集合用多了自然熟悉。
Kubernetes 集群中，业务通常采用 Deployment + LoadBalancer 类型 Service 的方式对外提供服务，其典型部署架构如图 1 所示。这种架构部署和运维都十分简单方便，但是在应用更新或者升级时可能会存在服务中断，引发线上问题。今天我们来详细分析下这种架构为何在更新应用时会发生服务中断以及如何避免服务中断;
envoy 进程作为 contour 的数据面组件，有时需要被重新部署。可能是由于升级、修改配置、或者节点问题导致的pod漂移。
大家好，我是猫头虎，一名专注于云原生技术的技术博主。在日常工作中，我们经常需要对K8S中的Pod进行维护和升级操作，这时候优雅关机就显得尤为重要。本文将通过多级标题、引用语法和丰富的代码示例，为大家详细讲解如何在K8S中实现优雅关机，以及如何配置Spring Boot应用的server.shutdown.graceful参数。
Istio 在 1.1 版本之前有个问题: Pod 销毁时，如果进程在退出过程中继续调用其它服务 (比如通知另外的服务进行清理)，会调用失败。
Kubernetes（K8s）中的 Container Lifecycle Hooks 允许容器管理生命周期事件。这些钩子使得在容器生命周期的特定时刻执行代码成为可能，例如在容器启动或终止时。理解和使用这些 Hooks 可以帮助更好地控制容器的行为和响应。
「定义」：Pod是Kubernetes中最小的部署单元，是一个或多个紧密关联容器的组合。「调度」：Pod作为一个整体被调度到Kubernetes集群中的节点上。「生命周期」：Pod的生命周期由包含的容器的生命周期决定。
更新部署服务时，旧的 Pod 会终止，新 Pod 上位。如果在这个部署过程中老 Pod 有一个很长的操作，我们想在这个操作成功完成后杀死这个 pod（优雅关闭），如果无法做到的话，被杀死的 pod 可能会丢失一定的流量，或者外界无法感知到该 Pod 被杀死。特别是，如果我们有一个接收大量流量的 API，错误率在部署过程中会显著增加。
一直以来我对优雅地停止 Pod 这件事理解得很单纯：不就利用是 PreStop Hook 做优雅退出吗？但最近发现很多场景下 PreStop Hook 并不能很好地完成需求，这篇文章就简单分析一下“优雅地停止 Pod”这回事儿。
Kubernetes 提供了一种 Pod 优雅退出机制，使 Pod 在退出前可以完成一些清理工作。但若执行清理工作时出错了，Pod 能正常退出吗？多久能退出？退出时间可以指定吗？系统有默认参数吗？这其中有若干细节值得我们去注意，本文就从这些细节出发，梳理清楚每种情况下 Kubernetes 的组件的各项行为及其参数设定。
每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效。在设计时可以充分利用这一特性，将一组密切相关的服务进程放入同一个Pod中；同一个Pod里的容器之间仅需通过localhost就能互相通信。
强制停止是一种粗暴的方式，直接终止Pods中正在运行的进程，并且不等待正在处理的请求完成。这种方式可能会导致正在处理的请求失败或数据丢失，因此在生产环境中应该尽量避免使用。相比之下，优雅停止则是一种更加温和的方式，它会给Pods中的进程发送一个信号，告诉它们要停止处理新的请求，并等待已经在处理中的请求完成。
本文介绍在 istio 场景下实现优雅终止时需要重点关注的点，一些容器场景通用的关注点请参考 Kubenretes 最佳实践: 优雅终止 。
由于 Pod 所代表的是在集群中节点上运行的进程，当不再需要这些进程时允许其体面地终止。
codis集群在接入弹性云测试时发现容器漂移失败，通过集群日志看，提示 调度超时，去界面查看，已经调度成功了（调度成功的标志就是已经有宿主机IP了），状态显示的pending并不一定就是调度失败。但这反应不出来问题出在哪里，接下来就需要到master机器上执行命名，查看日志来分析问题出在哪里
业务容器化上云之后，时常会有版本的动态变更，如何无损升级越发重要。结合底层技术原理，本文将对Pod优雅停机展开分析，供业务团队参考。
在节点处于“NotReady”状态时，deployment控制器会迁移节点上的容器实例，并将节点上运行的pod置为“Terminating”状态。待节点恢复后，处于“Terminating”状态的pod会自动删除。偶现部分pod（实例）一直处于“Terminating ”状态，发现这部分的pod没有得到重新调度，不能提供服务。
创建 Pod 时，可以为其下的容器设置环境变量。通过配置文件的 env 或者 envFrom 字段来设置环境变量。
Salesforce 的 Einstein Vision 和语言服务部署在 AWS Elastic Kubernetes Service(EKS) 集群上。其中有一个最主要的安全和合规性需求，就是给集群节点的操作系统打补丁。部署服务的集群节点需要通过打补丁的方式进行系统的定期更新。这些补丁减少了可能让虚拟机暴露于攻击之下的漏洞。
是否所有项目都需要优雅关闭？那也不一定，毕竟所谓的优雅关闭，另一面就意味这关闭得慢，因此项目的优雅关闭得看项目的核心程度，换言之就是看该项目处理的数据是不是核心数据，其实项目的最终本质，是对数据的处理。
Recreate策略是另一种滚动更新策略，它会先删除旧的Pod，然后再创建新的Pod。在进行滚动更新时，所有的Pod都会被同时停止，然后全部替换为新的Pod。Recreate策略的优点是可以避免新旧Pod的共存问题，但会在升级期间中断服务。
平滑关闭和服务摘流是保证部署了多节点的应用能够持续稳定对外提供服务的两个重要手段，平滑关闭保证了应用节点在关闭之前处理完已接收到的请求，以前在文章「学习用Go编写HTTP服务」里给大家介绍过怎么用net/http库提供的 http.ShutDown平滑关停HTTP 服务，今天再给大家介绍一下gRPC分布式服务的平滑关停方法。应用在进入平滑关闭阶段后拒绝为新进来的流量提供服务，如果此时继续有新流量访问而来，势必会让发送请求的客户端感知到服务的断开，所以在平滑关闭应用前我们还要对应用节点做摘流操作，保证网关不会再把新流量分发到要关闭的应用节点上才行。
在应用程序的整个生命周期中，正在运行的 pod 会由于多种原因而终止。在某些情况下，Kubernetes 会因用户输入（例如更新或删除 Deployment 时）而终止 pod。在其他情况下，Kubernetes 需要释放给定节点上的资源时会终止 pod。无论哪种情况，Kubernetes 都允许在 pod 中运行的容器在可配置的时间内正常关闭。
Pod 遵循一个预定义的生命周期，起始于 Pending 阶段，如果至少 其中有一个主要容器正常启动，则进入 Running，之后取决于 Pod
当 Kubernetes 开始终止一个 Pod 时，它首先向该 Pod 中的所有容器发送一个 TERM 信号。当 Linkerd 代理 sidecar 收到此信号时， 它将立即开始正常关闭， 拒绝所有新请求并允许现有请求在关闭之前完成。
首先，我将简要说明滚动更新开始后旧 pod 将如何终止。然后，我将展示帮助一个 Go 应用程序实现零停机时间的简单的正常关机实现。
在 Kubernetes 中，我们一般通过 Deployment、Daemonset 等控制器管理 Pod，并且把他们放到 Service 后面，使用 Service 的虚拟 IP 或者负载均衡器 IP 去访问。在 Pod 配置变更（如更新镜像）时，这些控制器默认就会采用滚动更新的方式逐步用新 Pod 替换已有的 Pod。下图所示就是一个典型的滚动更新[1]过程：
在容器编排领域，Kubernetes 已成为领先的平台，可实现容器化应用程序的高效管理、扩展和部署。当应用程序在容器内运行时，正确终止这些容器对于维持系统的整体健康和可靠性至关重要。在本文中，我们将深入研究 Kubernetes 终止信号的概念，并了解它们如何确保应用程序正常关闭，避免数据丢失或用户体验中断。
其实docker之前有自己的一套编排软件：docker swarm 它可以在多台主机中创建一个docker集群，但是也仅限于此了，docker在很早就放弃了这个项目。 docker machine 是配合swarm的一个预处理工具
绝大数事故发生在应用上下线发布阶段，所以要尽可能避免发布过程中由于应用自身代码问题对用户造成的影响。
流行的成语“除了变化之外，没有什么是不变的”来自一位名叫赫拉克利特的希腊哲学家。尽管赫拉克利特生活在公元前 500 年左右，但这句话仍然有效。多亏了像 Kubernetes 这样超高效的编排工具，对我们的应用程序进行更改变得更加无缝。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
PreStop 允许 Pod 在终止前执行一个命令或者是脚本，使用它就可以在应用退出前释放一些资源，确保应用可以优雅退出。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
