8.3. 使用部署策略

选择部署策略时请考虑以下几点：

部署策略使用就绪度检查来确定新 pod 是否准备就绪。如果就绪度检查失败，DeploymentConfig 对象会重新尝试运行 pod，直到超时为止。默认超时为 10m，其值在 dc.spec.strategy.*params 的 TimeoutSeconds 中设置。

滚动部署会逐渐将应用程序旧版本实例替换为应用程序的新版本实例。如果 DeploymentConfig 对象上没有指定任何策略，则滚动策略是默认的部署策略。

在缩减旧组件前，滚动部署通常会 等待新 pod 变为 ready。如果发生严重问题，可以中止 Rolling 部署。

使用滚动部署：

滚动部署意味着您同时运行旧版和新版本的代码。这通常需要您的应用程序可以处理 N-1 兼容性。

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Rolling
    rollingParams:
      updatePeriodSeconds: 1 1
      intervalSeconds: 1 2
      timeoutSeconds: 120 3
      maxSurge: "20%" 4
      maxUnavailable: "10%" 5
      pre: {} 6
     post: {}

滚动策略：

maxUnavailable 参数是在更新过程中不可用的 pod 的最大数量。maxSurge 参数是原始 pod 数量之上最多可以调度的 pod 数量。这两个参数可以设定为百分比（如 10％）或绝对值（如 2）。两者的默认值都是 25％。

这些参数允许对部署的可用性和速度进行调优。例如：

一般而言，如果您想要快速推出部署，请使用 maxSurge。如果您需要考虑资源配额并可以接受资源部分不可用的情况，则可使用 maxUnavailable。

Recreate（重新创建）策略具有基本的推出部署行为，并支持使用生命周期 hook 将代码注入到部署过程中。

kind: Deployment
apiVersion: apps/v1
metadata:
  name: hello-openshift
# ...
spec:
# ...
  strategy:
    type: Recreate
    recreateParams: 1
      pre: {} 2
      mid: {}
      post: {}

recreate 策略：

使用重新创建的部署：

重新创建部署会导致停机，这是因为在短时间内没有运行应用程序实例。然而，旧代码和新代码不会被同时运行。

自定义（Custom）策略允许您提供自己的部署行为。

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Custom
    customParams:
      image: organization/strategy
      command: [ "command", "arg1" ]
      environment:
        - name: ENV_1
          value: VALUE_1

在上例中，organization/strategy 容器镜像提供部署行为。可选的 command 数组覆盖镜像的 Dockerfile 中指定的任何 CMD 指令。提供的可选环境变量添加到策略过程的执行环境中。

另外，OpenShift Container Platform 为部署过程提供以下环境变量：

新部署的副本数最初为零。该策略负责使新部署积极使用最能满足用户需求的逻辑。

另外，也可使用 customParams 对象将自定义部署逻辑注入现有的部署策略中。提供自定义 shell 脚本逻辑并调用 openshift-deploy 二进制文件。用户不必提供自定义的部署器容器镜像；本例中使用默认的 OpenShift Container Platform 部署器镜像：

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Rolling
    customParams:
      command:
      - /bin/sh
      - -c
      - |
        set -e
        openshift-deploy --until=50%
        echo Halfway there
        openshift-deploy
        echo Complete

这会产生以下部署：

Started deployment #2
--> Scaling up custom-deployment-2 from 0 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-2 up to 1
--> Reached 50% (currently 50%)
Halfway there
--> Scaling up custom-deployment-2 from 1 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-1 down to 1
    Scaling custom-deployment-2 up to 2
    Scaling custom-deployment-1 down to 0
--> Success
Complete

如果自定义部署策略过程需要访问 OpenShift Container Platform API 或 Kubernetes API，执行该策略的容器可以使用容器中的服务帐户令牌进行身份验证。

滚动和重新创建策略支持 生命周期 hook 或部署 hook，它允许在策略的预定义点将行为注入到部署过程中：

pre:
  failurePolicy: Abort
  execNewPod: {} 1

每个 hook 都有一个 失败策略，定义在遇到 hook 失败时策略应执行的操作：

Hook 具有特定类型的字段，用于描述如何执行 Hook。目前，基于 pod 的 hook 是唯一受支持的 hook 类型，通过 execNewPod 字段指定。

基于 Pod 的生命周期 hook

基于 Pod 的生命周期 hook 在来自 DeploymentConfig 对象模板的新 pod 中执行 hook 代码。

以下简化的部署示例使用了滚动策略。为简明起见，省略了触发器和其他一些次要的细节：

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: frontend
spec:
  template:
    metadata:
      labels:
        name: frontend
    spec:
      containers:
        - name: helloworld
          image: openshift/origin-ruby-sample
  replicas: 5
  selector:
    name: frontend
  strategy:
    type: Rolling
    rollingParams:
      pre:
        failurePolicy: Abort
        execNewPod:
          containerName: helloworld 1
          command: [ "/usr/bin/command", "arg1", "arg2" ] 2
          env: 3
            - name: CUSTOM_VAR1
              value: custom_value1
          volumes:
            - data 4

在本例中，将使用 helloworld 容器中的 openshift/origin-ruby-sample 镜像在新 pod 中执行 pre hook。hook pod 具有以下属性：