当我们在生产环境发布应用时，必须要考虑到当前系统还有用户正在使用的情况，所以尽量需要做到不停机发版。
所以在发布过程中理论上之前的 v1 版本依然存在，必须得等待 v2 版本启动成功后再删除历史的 v1 版本。
滚动更新
这是我们预期中的发布流程，要在 kubernetes 使用该功能也非常简单，只需要在 spec 下配置相关策略即可：
spec:
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate这个配置的含义是：
这样一旦我们更新了 Pod 的镜像时，kubernetes 就会先创建一个新版本的 Pod 等待他启动成功后再逐步更新剩下的 Pod。
优雅停机
滚动升级过程中不可避免的又会碰到一个优雅停机的问题，毕竟是需要停掉老的 Pod。
这时我们需要注意两种情况：
第一个问题如果我们使用的是 Go，可以使用一个钩子来监听 kubernetes 发出的退出信号：
quit := make(chan os.Signal)
signal.Notify(quit, syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT, syscall.SIGPIPE)
go func() {
<-quit
log.Printf("quit signal received, exit n")
os.Exit(0)
}()server:
shutdown: "graceful"
spring:
lifecycle:
timeout-per-shutdown-phase: "20s"当应用收到退出信号后，spring boot 将不会再接收新的请求，并等待现有的请求处理完毕。
但 kubernetes 也不会无限等待应用将 Pod 将任务执行完毕，我们可以在 Pod 中配置
terminationGracePeriodSeconds: 30来定义需要等待多长时间，这里是超过 30s 之后就会强行 kill Pod。
spec:
containers:
- name: example-container
image: example-image
lifecycle:
preStop:
exec:
command: ["sh", "-c", "sleep 10"]同时我们也可以配置 preStop 做一个 sleep 来确保 kubernetes 将准备删除的 Pod 在 Iptable 中已经更新了之后再删除 Pod。
这样可以避免第二种情况：已经删除的 Pod 依然还有请求路由过来。具体可以参考 spring boot 文档：
https://docs.spring.io/spring-boot/docs/2.4.4/reference/htmlsingle/#cloud–deployment-kubernetes–container-lifecycle
回滚
回滚其实也可以看作是升级的一种，只是升级到了历史版本，在 kubernetes 中回滚应用非常简单。
# 回滚到上一个版本
k rollout undo deployment/abc
# 回滚到指定版本
k rollout undo daemonset/abc --to-revision=3优雅重启
在之前的 如何优雅重启 kubernetes 的 Pod 那篇文章中写过，如果想要优雅重启 Pod 也可以使用 rollout 命令，它也也可以保证是滚动重启。
k rollout restart deployment/nginx使用 kubernetes 的滚动更新确实要比我们以往的传统运维简单许多，就几个命令的事情之前得写一些复杂的运维脚本才能实现。
https://github.com/crossoverJie/k8s-combat
PS：最近也在更新视频号，也会有一些技术干货，动动小手帮主播点播关注
往期推荐
点分享
点收藏
点点赞
点在看
原文地址:https://blog.csdn.net/qq_18661793/article/details/134724719
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_28610.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
