为什么声明式部署（更新）
声明式部署模式的核心是Kubernetes的部署资源，这个抽象封装了一组容器的升级和回滚过程，且在过程的执行可以重复和自动化。
摘自Kubernetes设计模式 第三章
在版本的升级或回滚过程中很可能需要编写大量重复的脚本，在这个过程中也极易出错。使用声明式部署可以自动化地做这些事情。
声明式部署做些什么
部署的核心是按照预期启动和停止一组Pod的能力。
在部署开始时，会创建一个新的ReplicaSet用于存放更新后的Pod，然后执行更新策略，在旧的ReplicaSet中的所有Pod全部被移除，且新的ReplicaSet中的Pod全部启动成功后，Deployment将会指向新的ReplicaSet，并删除旧的ReplicaSet。
Kubernetes提供了两种更新方式重新创建和滚动更新。
声明式更新的触发方式
以下3种方式可以触发声明式更新：
- kubectl replace命令，使用旧的部署替换掉新的部署
- 打补丁(kubectl patch)或者交互式编辑（kubectl edit）,为容器设置新版本的新容器镜像
- 使用kubectl set image，在部署中设置新镜像
重新创建
此策略会删除所有现有的Pod，然后创建新的Pod
Demo
1 | ... |
格式
- type: 必须准确写为Recreate。
滚动更新
滚动更新（RollingUpdate）是Kubernetes的默认部署方式，它能够保证不会出现停机。
不停机的实现需要就绪探针（readinessProbe），以用于确定容器真的可用。
缺点: 在更新过程中，新旧版本会同时存在，可能会造成程序的不一致。
Demo
1 | ... |
格式
type: 必须准确写为RollingUpdate
roolingUpdate: 滚动更新的描述
maxUnavailable: 最大不可用，一个非负整数或百分比（百分比会被向下取整到整数），用来指定更新过程中不可用的 Pod 的个数上限。如果这个值是0，那么maxSurge不能为0。这个值的默认值为25%。
maxSurge: 最大峰值，一个非负整数或百分比（百分比会被向上取整到整数），用来指定可以创建的超出期望Pod个数的 Pod 数量，如果MaxUnavailable为0，则此值不为0。这个值的默认值为25%。
策略
首先会删除旧的Pod，并启动新的Pod。当一个新的Pod可用时会删除下一个旧的Pod，当一个旧的Pod停止后会启动一个新的Pod，但在这过程中，会满足maxUnavaliable和maxSurge的要求。
蓝绿部署
蓝绿部署是一种发布策略，可以最大限度减少停机风险，缺点是在过程中会需要双倍的资源，且过程中新旧版本同时处于运行状态。
使用蓝绿部署需要服务网格（Service Mesh）或者Knative等扩展，否则就需要自己写脚本。
策略
首先创建新版本的Pods，但不相应任何请求。在新版本的Pods全部成功启动后，将流量从旧版本的Pods迁移至新版本的Pods，当流量完成迁移，即可将旧版本的Pods删除
金丝雀发布
金丝雀发布是一种平滑的发布策略。使用新的实例替换掉一小部分新的实例，这种技术只让一小部分消费者使用更新后的版本，以降低迁移风险。
策略
为新版本的容器（Pod）创建一个副本集，且只包含少量副本，并将一些消费者定向到新的Pod的实例上，如果确信新版本能够符合预期地工作便可对副本集进行拓展，并减少旧的副本集直至0。