大家好，我是猫头虎，一名专注于云原生技术的技术博主。在日常工作中，我们经常需要对K8S中的Pod进行维护和升级操作，这时候优雅关机就显得尤为重要。本文将通过多级标题、引用语法和丰富的代码示例，为大家详细讲解如何在K8S中实现优雅关机，以及如何配置Spring Boot应用的server.shutdown.graceful参数。
一直以来我对优雅地停止 Pod 这件事理解得很单纯：不就利用是 PreStop hook 做优雅退出吗？但最近发现很多场景下 PreStop Hook 并不能很好地完成需求，这篇文章就简单分析一下“优雅地停止 Pod”这回事儿。
K8S自身带有优雅终止Pod容器的机制，发送SIGTERM终止信号，在规定的terminationGracePeriodSeconds优雅时间内完成Pod优雅终止动作。
公司某服务接入效能平台后，发布过程中，页面偶尔会出现5003报错，开始以为是Nacos没有及时的将服务反注册，即POD在已经正常关闭的情况下，注册中心依然有POD信息，请求依然到已经关闭的POD中导致
优雅关闭：在关闭前，执行正常的关闭过程，释放连接和资源，如我们操作系统执行 shutdown。
一直以来我对优雅地停止 Pod 这件事理解得很单纯：不就利用是 PreStop Hook 做优雅退出吗？但最近发现很多场景下 PreStop Hook 并不能很好地完成需求，这篇文章就简单分析一下“优雅地停止 Pod”这回事儿。
优雅停止(Graceful shutdown) 这个说法来自于操作系统，我们执行关机之后都得 OS 先完成一些清理操作，而与之相对的就是硬中止(Hard shutdown)，比如拔电源。
PS：为了掩饰所以提供了挂载方便查看删除后的优雅处理输出了一段话，但是实际的生产中最好的方式就是关闭容器的服务。PostStart 和 PreStop的使用方法其实不难。k8s都是命令的集合用多了自然熟悉。
当涉及到分布式系统,处理故障是关键。Kubernetes通过利用可以监视系统状态并重新启动已停止执行的服务的控制器（controllers）来解决这个问题。另一方面，Kubernetes通常可以强制终止您的应用程序，作为系统正常运行的一部分。
更新部署服务时，旧的 Pod 会终止，新 Pod 上位。如果在这个部署过程中老 Pod 有一个很长的操作，我们想在这个操作成功完成后杀死这个 pod（优雅关闭），如果无法做到的话，被杀死的 pod 可能会丢失一定的流量，或者外界无法感知到该 Pod 被杀死。特别是，如果我们有一个接收大量流量的 API，错误率在部署过程中会显著增加。
「定义」：Pod是Kubernetes中最小的部署单元，是一个或多个紧密关联容器的组合。「调度」：Pod作为一个整体被调度到Kubernetes集群中的节点上。「生命周期」：Pod的生命周期由包含的容器的生命周期决定。
我们在做请求的时候，客户端或者web端发送请求给到后端，具体完整的链路请求是怎么到后端的，以及后端怎么做负载均衡，扩缩容，这里跟大家分析下具体过程。看这篇文章需要有K8S的基础，如果没有，建议可以先去看一下作者的K8S系列相关文章，了解下K8S基本概念。
首先，我将简要说明滚动更新开始后旧 pod 将如何终止。然后，我将展示帮助一个 Go 应用程序实现零停机时间的简单的正常关机实现。
如果读者已经按照前文的内容走下来，那么应该能够对k8s有一个非常基础的了解，即如何搭建环境，如何拉起一个容器，如何访问一个容器，这些操作都是我们想要往k8s部署应用所必须会的基本内容，帮助你快速的上手k8s。
健康检测接口用于检测应用的健康状态，在K8S中，使用Readiness和Liveness分别来探测应用是否就绪和是否存活，如果未就绪或者未存活，K8S会采取相应的措施来确保应用可用。
其实docker之前有自己的一套编排软件：docker swarm 它可以在多台主机中创建一个docker集群，但是也仅限于此了，docker在很早就放弃了这个项目。 docker machine 是配合swarm的一个预处理工具
绝大数事故发生在应用上下线发布阶段，所以要尽可能避免发布过程中由于应用自身代码问题对用户造成的影响。
原文： http://yunke.science/2018/04/15/k8s-hook/
优雅停机，通常是指在设备、系统或应用程序中止运作前，先执行一定的流程或动作，以确保数据的安全、预防错误并保证系统的整体稳定。
每次当我们发布新版本的时候总是慌兮兮，一方面是担心有 bug，另一方面其实重启应用会带来一些抖动，可能有几秒钟或者几个请求的不正常，从而担心用户在这段时间内的操作。那么如何在应用重启的过程中尽可能的保证不会带来抖动，从而平滑又优雅的重启呢？
Kubernetes（K8s）中的 Container Lifecycle Hooks 允许容器管理生命周期事件。这些钩子使得在容器生命周期的特定时刻执行代码成为可能，例如在容器启动或终止时。理解和使用这些 Hooks 可以帮助更好地控制容器的行为和响应。
这是我们实现 Kubernetes 集群零停机时间更新的第二部分。在本系列的第一部分中，我们列举出了简单粗暴地使用kubectl drain 命令清除集群节点上的 Pod 的问题和挑战。在这篇文章中，我们将介绍解决这些问题和挑战的手段之一：优雅地关闭 Pod。
Kubernetes是谷歌以Borg为前身，基于谷歌15年生产环境经验的基础上开源的一个项目，Kubernetes致力于提供跨主机集群的自动部署、扩展、高可用以及运行应用程序容器的平台。
目前很多企业还是采用基于 SDK 的传统微服务框架进行服务治理，而随着 Service Mesh 的普及，越来越多的企业开始布局自己的 Service Mesh 框架体系，但多数企业刚开始不会激进地将所有业务迁移至 Serivice Mesh，像 Java 系应用依然保留原框架，而非 Java 系应用采用 Mesh 框架，不同开发语言可以用不同的技术框架，但业务不能被框架割裂，那在两种架构体系下应用服务如何互联互通？微服务如何统一治理？传统微服务又如何平滑迁移至 Service Mesh 呢？ 腾讯
腾讯为了解决以上的技术问题，自研了 TSF Mesh 微服务框架。也许有人会问，开源 Istio 已经是比较完善的 Service Mesh 方案了，为什么要再造一个 Mesh 微服务框架？和原生 Istio 什么区别呢？
envoy 进程作为 contour 的数据面组件，有时需要被重新部署。可能是由于升级、修改配置、或者节点问题导致的pod漂移。
整个k8s是推荐我们使用资源文件清单的格式编写， 资源清单有5个顶级的字段组成：apiVersion、kind、metadata、spec、status ，status是k8s集群运行的时候需要去关注的，即机器需要去关注的，而前面这四个，不管是开发工程师还是运维工程师都需要做一些基本的了解，以及探讨pod的生命周期。
由于 Pod 所代表的是在集群中节点上运行的进程，当不再需要这些进程时允许其体面地终止。
k8s已经成为了绝对热门的技术，一个上点规模的公司，如果不搞k8s，都不好意思出去见人。安装k8s要突破种种网络阻碍，但更大的阻碍还在后面...
codis集群在接入弹性云测试时发现容器漂移失败，通过集群日志看，提示 调度超时，去界面查看，已经调度成功了（调度成功的标志就是已经有宿主机IP了），状态显示的pending并不一定就是调度失败。但这反应不出来问题出在哪里，接下来就需要到master机器上执行命名，查看日志来分析问题出在哪里
服务的更新、回滚和灰度，是个简单的问题，如果加上一个条件"不中断服务的前提下"，那么就是一个难题，如果再加上"大规模"，那么就是K8S要解决的核心问题之一。坏消息是这个难搞的问题还真是流媒体服务的核心的、关键的、不可忽视的关键能力之一，好消息是K8S和云计算让这个难题稍微好一点点了。
当 Kubernetes 开始终止一个 Pod 时，它首先向该 Pod 中的所有容器发送一个 TERM 信号。当 Linkerd 代理 sidecar 收到此信号时， 它将立即开始正常关闭， 拒绝所有新请求并允许现有请求在关闭之前完成。
是否所有项目都需要优雅关闭？那也不一定，毕竟所谓的优雅关闭，另一面就意味这关闭得慢，因此项目的优雅关闭得看项目的核心程度，换言之就是看该项目处理的数据是不是核心数据，其实项目的最终本质，是对数据的处理。
原文作者：ryan4yin，🔗： https://thiscute.world/posts/kubernetes-best-practices/ 本文主要介绍我个人在使用 Kubernetes 的过程中，总结出的一套「Kubernetes 配置」，是我个人的「最佳实践」。其中大部分内容都经历过线上环境的考验，但是也有少部分还只在我脑子里模拟过，请谨慎参考。 阅读前的几个注意事项： 这份文档比较长，囊括了很多内容，建议当成参考手册使用，先参照目录简单读一读，有需要再细读相关内容。 这份文档需要一定的 Kube
以 12 要素为代表的微服务标准，很好地给微服务的特征做出了指导。然而具体到以容器形式在 Kubernetes 上运行的无状态业务应用上，这个标准是有些高层的——它看重的是方法和架构。如果仅从外在视角来对一个“顺眼”的 Kubernetes 应用进行观察，这个应用应该有什么特征呢？
K8S的集群运行依赖Master节点和Node节点的通信，为了更好的理解第4部分的Pod生命周期，我们这里先给出K8S Master的简单架构图，后续的文章中，我们会分析Master、Node和Pod之间的关系。
大家好，我是 roc，来自腾讯云容器服务(TKE)团队，之前发过一篇干货满满的爆火文章 Kubernetes 网络疑难杂症排查分享，包含多个疑难杂症的排查案例分享，信息量巨大。这次我又带来了续集，只讲
本文主要围绕k8s command展开讨论。(deployment.spec.template.spec.containers[n].command) 主要聊聊平台在接入用户业务时，如何保证满足业务基本需求情况下增强平台易用性。
1、用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer。 2、apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端。 3、apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动。 4、scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer。 5、node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer。 6、apiServer将接收到的pod状态信息存入etcd中。
| 导语 从这篇文章开始，我们将详细介绍K8S的各个组件。学习一项技术，理论先行，只有充分的了解了内在原理才能在日后的维护和调优方面有所思路。
Kubernetes v1.29 是 2023 年的第三个大版本更新，也是今年的最后一个大版本，包含了 49 项主要的更新。 而今年发布的第一个版本 v1.27 有近 60 项，第二个版本 v1.28 有 46 项。尽管 Kubernetes 已经发布快 10 年了，Kubernetes 的生命力仍然很旺盛！
vivo 人工智能计算平台小组从 2018 年底开始建设 AI 计算平台至今，已经在 k8s 集群、以及离线的深度学习模型训练等方面，积累了众多宝贵的开发、运维经验，并逐步打造出稳定的基础容器平台 - AI 容器平台（VContainer）。为了支撑公司 AI 在线业务的发展，满足公司对算力资源的高效调度管控需求，需要将在线业务，主要包括 C 端、推理等业务，由原来的虚拟机或物理机迁移至 AI 容器平台。于是小组从 2020 年初开始，基于在线业务的需求对 AI 容器平台进行进一步建设，并将平台与公司的 CMDB、CICD 等基础模块进行打通，使在线业务能够顺利从虚拟机、物理机迁移至 AI 容器平台。
Kubernetes 集群网络有很多种实现，有很大一部分都用到了 Linux 网桥：每个 Pod 的网卡都是 veth 设备，veth pair 的另一端连上宿主机上的网桥。由于网桥是虚拟的二层设备，同节点的 Pod 之间通信直接走二层转发，跨节点通信才会经过宿主机 eth0。
上一篇 文章我们围绕如何合理利用资源的主题做了一些最佳实践的分享，这一次我们就如何提高服务可用性的主题来展开探讨。
• 我们一般将Pod对象从创建到终止的这段时间范围称为Pod的生命周期，它主要包含下面的过程：
每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效。在设计时可以充分利用这一特性，将一组密切相关的服务进程放入同一个Pod中；同一个Pod里的容器之间仅需通过localhost就能互相通信。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
