4.3. 使用部署策略
部署策略是更改或升级应用程序的一种方法。其目的是在无需停机的前提下进行修改，从而使用户几乎不会注意到这些变化。
因为最终用户通常通过由路由器控制的路由访问应用程序，所以部署策略侧重于 DeploymentConfig 对象功能或路由功能。注重部署的策略会影响所有使用该应用程序的路由。侧重于路由功能的策略则会影响到单个的路由。
许多部署策略通过 DeploymentConfig 对象支持，一些额外的策略则通过路由器功能支持。本节将讨论部署策略。
选择部署策略
选择部署策略时请考虑以下几点：
- 长时间运行的连接必须被恰当处理。
- 数据库转换可能比较复杂，且必须和应用程序一同执行并回滚。
- 如果应用程序由微服务和传统组件构成，则可能需要停机才能完成转换。
- 您必须拥有进行此操作的基础架构。
- 如果您的测试环境没有被隔离，则可能会破坏到新版本和旧版本。
部署策略使用就绪度检查来确定新 pod 是否准备就绪。如果就绪度检查失败，DeploymentConfig 对象会重新尝试运行 pod，直到超时为止。默认超时为 10m，其值在 dc.spec.strategy.*params 的 TimeoutSeconds 中设置。
4.3.1. Rolling 策略
滚动部署会逐渐将应用程序旧版本实例替换为应用程序的新版本实例。如果 DeploymentConfig 对象上没有指定任何策略，则滚动策略是默认的部署策略。
在缩减旧组件前，滚动部署通常会 等待新 pod 变为 ready。如果发生严重问题，可以中止 Rolling 部署。
使用滚动部署：
- 希望在应用程序更新过程中不需要停机时。
- 应用程序同时支持运行旧代码和新代码时。
滚动部署意味着您同时运行旧版和新版本的代码。这通常需要您的应用程序可以处理 N-1 兼容性。
滚动策略定义示例
strategy:
type: Rolling
rollingParams:
updatePeriodSeconds: 1 1
intervalSeconds: 1 2
timeoutSeconds: 120 3
maxSurge: "20%" 4
maxUnavailable: "10%" 5
pre: {} 6
post: {}
滚动策略：
-
执行任何
pre生命周期 hook。 - 根据数量扩展新的复制控制器。
- 根据最大不可用数，缩减旧的复制控制器。
- 重复这个扩展，直到新的复制控制器达到所需的副本数，并且旧的复制控制器已缩减为零。
-
执行任何
post生命周期 hook。
在缩减时，滚动策略会等待 pod 准备就绪，以便它能决定进一步缩放是否会影响到可用性。如果扩展 pod 永不就绪，部署过程将最终超时并导致部署失败。
maxUnavailable 参数是在更新过程中不可用的 pod 的最大数量。maxSurge 参数是原始 pod 数量之上最多可以调度的 pod 数量。这两个参数可以设定为百分比（如 10％）或绝对值（如 2）。两者的默认值都是 25％。
这些参数允许对部署的可用性和速度进行调优。例如：
-
maxUnavailable*=0和maxSurge*=20%可确保在更新和快速扩展过程中保持全部容量。 -
maxUnavailable*=10％和maxSurge*=0在执行更新时不使用额外容量（原位更新）。 -
maxUnavailable*=10％和maxSurge*=10％可以快速缩放，可能会有一些容量损失。
一般而言，如果您想要快速推出部署，请使用 maxSurge。如果您需要考虑资源配额并可以接受资源部分不可用的情况，则可使用 maxUnavailable。
4.3.1.1. Canary 部署
OpenShift Container Platform 中的所有滚动部署都属于 Canary 部署；在替换所有旧实例前测试新的版本（Canary）。如果就绪度检查永不成功，则移除 Canary 实例，并且自动回滚 DeploymentConfig 对象。
就绪度检查是应用程序代码的一部分，并且可以尽可能的精密，确保新实例就绪可用。如果您必须对应用程序进行更复杂的检查（比如向新实例发送真实用户负载），请考虑实施自定义部署或使用蓝绿部署策略。
4.3.1.2. 创建滚动部署
在 OpenShift Container Platform 中，Rolling 部署是默认类型。您可以使用 CLI 创建滚动部署。
流程
$ oc new-app quay.io/openshifttest/deployment-example:latest
如果您安装了路由器，请通过路由（或直接使用服务 IP）提供应用程序。
$ oc expose svc/deployment-example
-
通过
deployment-example.<project>.<router_domain>访问应用程序，验证您能否看到v1镜像。 将
DeploymentConfig对象扩展至三个副本：$ oc scale dc/deployment-example --replicas=3
通过为示例的新版本标上
latest标签（tag），自动触发新部署：$ oc tag deployment-example:v2 deployment-example:latest
-
在浏览器中刷新页面，直到您看到
v2镜像。 在使用 CLI 时，以下命令显示版本 1 上的 pod 数以及版本 2 上的数量。在 Web 控制台中，pod 逐渐添加到 v2 中并从 v1 中移除：
$ oc describe dc deployment-example
在部署过程中，新复制控制器以递增方式扩展。新 pod 标记为 ready（通过就绪度检查）后，部署过程将继续。
如果 pod 尚未就绪，该过程会中止，部署回滚到之前的版本。
4.3.1.3. 使用 Developer 视角启动滚动部署
先决条件
- 确认您使用 web 控制台的 Developer 视角。
- 确保您已使用 Add 视图创建了一个应用程序，并可以在 Topology 视图中查看它。
流程
要启动滚动部署来升级应用程序：
- 在 Developer 视角的 Topology 视图中，点应用程序节点，查看侧面面板中的 Overview 选项卡。请注意，Update Strategy 被设置为默认的 Rolling 策略 。
在 Actions 下拉菜单中，选择 Start Rollout 来启动滚动更新。滚动部署将应用程序更新到新版本，然后终止旧版本。
图 4.1. 滚动更新
