Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停”（pause）或“继续”（resume）更新操作。
借助于最大超出副本数(spec.strategy.rollingUpdate.maxSurg)和最大不可用副本数(spec.strategy.rollingUpdate.maxUnavailable)属性还能实现更为精巧的过程控制。比如，待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一小部分新版本的应用，主体部分还是旧的版本。然后，再根据用户特征精心筛选出一部分用户的请求路由至新版本的Pod应用，并持续观察其是否能稳定地按期望的方式运行。确定没有问题后再继续完成余下Pod资源的滚动更新，否则立即回滚更新操作。这便是所谓的金丝雀发布（Canary Release）
- maxSurge：指定升级期间存在的总Pod对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是一个期望值的百分比。例如，如果期望值为3，当前的属性值为1，则表示Pod对象的总数不能超过4个。
- maxUnavailable：升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望数值的个数，其值可以是0或正整数，也可以是一个期望值的百分比；默认值为1，该值意味着如果期望值是3，则升级期间至少要有两个Pod对象处于正常提供服务的状态。
为了尽可能地降低对现有系统及其容量的影响，金丝雀发布过程通常建议采用“先添加、再删除，且可用Pod资源对象总数不低于期望值”的方式进行。首次添加的Pod对象数量取决于其接入的第一批请求的规则及单个Pod的承载能力，视具体需求而定
将Deployment控制器的maxSurge属性的值设置为1，并将maxUnavailable属性的值设置为0：
比如说原先pod数量为3，设置如上俩参数后，那么最多可用的pod数量是4，最多不可用的pod数量是0。也就是说更新的时候，会新增加一个pod数量，同时不会删除原有的pod，保持四个pod的数量，其中只有一个Pod是新的，剩余三个是旧的。
启动Deployment控制器的更新过程，在修改相应容器的镜像版本后⽴即暂停更新进度，它会在启动第⼀批新版本Pod对象的创建操作之后转为暂停状态。这⾥之所以能够在第⼀批更新启动后就暂停，有赖于此前为maxReadySeconds属性设置的时长，因此⽤户要在更新命令启动后的此时长指定的时间范围内启动暂停操作。
Deplpoyment控制器的spec.minReadySeconds属性用来控制应用升级的速度。新旧更替过程中，新创建的Pod对象一旦成功响应就绪探测即被视作可用，而后即可立即开始下一轮的替换操作。
而spec.minReadySeconds能够定义在新的Pod对象创建后至少要等待多久才会将其视作就绪，在此期间，更新操作会被阻塞。
因此，它可以用来让Kubernetes在每次创建出Pod资源后都要等上一段时长后再开始下一轮的更替，这个时间长度的理想值是等到Pod对象中的应用已经可以接受并处理请求流量。
kubectl set image deployments myapp-deploy myapp=ikubernetes/myapp:v3 && kubectl rollout pause deployments myapp-deploy
此时，通过Service或Ingress资源及相关路由策略等设定，即可将⼀部分⽤户的流量引⼊到这些Pod之上进⾏发布验证。运⾏⼀段时间后，如果确认没有问题，即可使⽤“kubectl rollout resume”命令继续此前的滚动更新过程。
如果“⾦丝雀”遇险甚⾄遭遇不幸，那么回滚操作便成了接下来的当紧任务。如果此前的滚动更新过程处于“暂停”状态，那么回滚操作就需要先将Pod模板的版本改回到之前的版本，然后“继续”更新，否则，其将⼀直处于暂停状态⽽⽆法回滚。
"⾦丝雀"发布需要的操作步骤：
- 设置最小就绪时间minReadySeconds的值，大于pod启动后正常提供时间的数值
- 设置最大超出副本数(spec.strategy.rollingUpdate.maxSurg)和最大不可用副本数(spec.strategy.rollingUpdate.maxUnavailable)，具体根据实际情况来定
- 在更新命令启动后的最小就绪时间minReadySeconds指定的时间范围内启动暂停操作
- Service或Ingress资源及相关路由策略设定，验证⼀部分⽤户的流量引⼊到新Pod之上
