4.3. 使用 DeploymentConfig 策略

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

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

何时使用 Rolling 部署：

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: {}

Rolling 策略：

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

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

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

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

strategy:
  type: Recreate
  recreateParams: 1
    pre: {} 2
    mid: {}
    post: {}

Recreate 策略：

何时使用 Recreate 部署：

Recreate 部署会出现停机的情况，这是因为在短时间内会出现没有运行您的应用程序实例的情况。然而，旧代码和新代码不会被同时运行。

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

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 部署器镜像：

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，执行该策略的容器可以使用容器中的服务帐户令牌进行身份验证。

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

pre:
  failurePolicy: Abort
  execNewPod: {} 1

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

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

基于 Pod 的生命周期 hook

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

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

kind: DeploymentConfig
apiVersion: 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 具有以下属性：