滚动发布基于Kubernetes原生的Deployment具备的滚动更新、多版本管理和API网关负载均衡能力实现。滚动更新的好处是显而易见的，比如，在升级刚开始的时候，集群里只有1个新版本的容器。如果这时，新版本容器有问题(环境或者程序本身有bug)启动不起来，那么“滚动更新”就会停止。而在这个过程中，由于应用本身还有两个旧版本的容器在线，所以服务并不会受到太大的影响。新版本部署好，测试验证如果不成功，通过回滚机制，可以快速滚动回退到最新的历史版本。

API网关不支持流量转移，所以发布过程中，是存在两个版本同时在线提供服务的情况，如果发现问题，比较难以确认是新版本还是旧版本造成的。因此需要考虑API版本、接口兼容性、发布时长这些因素，是否采用滚动发布。

从某种意义上讲，除了部署中的“滚动更新”过程，滚动发布可以认为是蓝绿发布的一种实现，而且解决了蓝绿发布资源加倍的问题。

本文一起看下 Deployment API 对象，该对象的作用是保证POD的高可用，即保证POD的可用数量一直维持在某个期望状态中，比如期望状态是有3个POD，当有一个POD意外终止时，则会自动再启动一个新POD，所以 Deployment 和POD之间是一种松散的引用关系，另外被引用的POD也可能被负载均衡组件引用，所以并非专属于 Deployment ，这点不同于Job和CronJob，Job和CronJob同POD是一种强绑定的关系，POD只为Job或CronJob所用。下面我们一起来看下。 前面写过一篇文章， kubernetes ( k8s ) 滚动 发布 ，不宕机实战已经 实现 了 滚动 发布 ，不过还得手工输命令，本篇呢想通过Jenkins 实现 一键操作。使 发布 应用效率提高。其实像KubeSphere这类的工具也是集成了Jenkins的，之所以直接使用Jenkins，是因为那种大而全的工具必然会损耗资源，而我又用不上那么多的功能。............... CNCF 对云原生的定义中提到了几个关键的点：1、强调应用环境的动态性，像公有云、私有云、混合云等新型的动态环境已成为大多数应用的首选；2、强调在跨多云部署应用时具备非云平台绑定的属性；3、还强调了弹性扩展、基于自动化手段快速部署和拉起等方面的重要性。 Kubernetes 及其强大的特点之一就是超大规模集群应用的自动化部署，这其中包括了应用的扩容、缩容及其自适应扩缩容（HPA、VPA）。本文详尽的介绍了 K8S 中 滚动 发布 的概念，并附带了丰富的命令实操截图。 滚动 更新是一种自动化程度较高的 发布 方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流 发布 方式，一次 滚动 发布 一般由若干个批次组成，每批的数量一般是可以配置的（通过 发布 模板定义）。批次间可留观察间隔，通过手工验证或监控反馈确保没有问题再继续下一批次，所以总体上 滚动 式 发布 过程是比较缓慢的。paused：暂停，当我们更新的时候创建pod先暂停，不是立即更新（ps.金丝雀 发布 会使用到）strategy：更新策略，支持的 滚动 更新策略。 上篇笔记我们学习了管理有状态应用的对象 StatefulSet，再加上管理无状态应用的 Deployment 和 DaemonSet，我们就能在 Kubernetes 里部署任意形式的应用了。只是把应用 发布 到集群里是远远不够的，要让应用稳定可靠地运行，还需要有持续的运维工作。在【 k8s 】 Deployment 让应用永不宕机(八)里，我们学过 Deployment 的应用伸缩功能就是一种常见的运维操作，在 Kubernetes 里，使用命令。 deploy用于部署无状态的服务，这个是最常用的控制器。一般用于管理维护企业内部无状态的微服务。它基于RS，可以管理多个副本的Pod， 实现 无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。 保存上面的模板为deploy-nginx.yaml 稍等两分钟，可以看到容器都起来了 也可以看到rs 查看更多信息： NAME： Deployment 名称 READY：Pod的状态，已经Ready的个数 UP-TO-DATE：已经达到期望状态的被更新的副本数 AVAILABLE：已经