k8s中pod滚动更新如何减少流量丢失
有一个大前提,在旧pod状态更新为Terminating并且SIGTERM后,容器仍然会将已经接收到的流量正常完成后才会销毁。
1.流量上线时的有损情况,添加健康检测,防止新pod还没准备好就分配流量
2.流量下线时的有损情况,添加preStop
生命周期挂钩, 在容器终止之前调用此钩子防止在新pod还没分配流量前,将流量分给已经SIGTERM的容器。
一旦新的Pod处于活动状态并准备就绪,Kubernetes将使旧的Pod停止服务,从而将Pod的状态更新为Terminating
,将其从端点对象中删除,然后发送SIGTERM
。 SIGTERM
使容器以(希望)正常的方式关闭,并且不接受任何新连接。 在将Pod从端点对象中逐出后,负载均衡器会将流量路由到其余(新的)流量。 这就是造成我们部署中的可用性差距的原因。 在负载均衡器注意到更改并可以更新其配置之前或之时,通过终止信号停用Pod。 这种重新配置是异步发生的,可能先发送SIGTERM信号后才摘除旧pod的Endpoints,此时可能导致很少的不幸请求被路由到终止Pod。此时应该配置preStop
生命周期挂钩
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: default
spec:
containers:
- name: nginx
image: nginx
#优雅退出 lifecycle: preStop: exec: command: ["/bin/bash", "-c", "sleep 30"] terminationGracePeriodSeconds: 60
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?