4.2. 管理部署过程

4.2.1. 管理 DeploymentConfig

使用 OpenShift Container Platform Web 控制台的 Workloads 页面或 oc CLI 可以管理 DeploymentConfig。以下流程演示了 CLI 的用法(除非另有说明)。

4.2.1.1. 启动部署

您可以启动一个推出部署来启动应用程序的部署过程。

流程

  1. 要从现有的 DeploymentConfig 启动新的部署过程,请运行以下命令:

    $ oc rollout latest dc/<name>
    注意

    如果部署过程已在进行中,此命令会显示一条消息,不会部署新的 ReplicationController。

4.2.1.2. 查看部署

您可以查看部署来获取应用程序所有可用修订的基本信息。

流程

  1. 要显示所有最近为提供的 DeploymentConfig 创建的 ReplicationController 的详细信息,包括任何当前运行的部署过程,请运行以下命令:

    $ oc rollout history dc/<name>
  2. 要查看修订的相关细节,请使用 --revision 标志:

    $ oc rollout history dc/<name> --revision=1
  3. 如需关于部署配置和最新修订的详细信息,可使用 oc describe 命令:

    $ oc describe dc <name>

4.2.1.3. 重试部署

如果无法部署 DeploymentConfig 的当前修订,您可以重启部署过程。

流程

  1. 重启已经失败的部署过程:

    $ oc rollout retry dc/<name>

    如果成功部署了最新的修订,命令会显示一条消息,而且不重试部署过程。

    注意

    重试部署会重启部署过程,且不创建新的部署修订。重启的 ReplicationController 会拥有与失败时相同的配置。

4.2.1.4. 回滚部署

回滚将应用恢复到上一修订,可通过 REST API、命令行或 Web 控制台进行。

流程

  1. 回滚到配置的最近一次部署成功的修订:

    $ oc rollout undo dc/<name>

    恢复 DeploymentConfig 的模板以匹配 undo 命令中指定的部署修订,并且启动新的 ReplicationController。如果没有通过 --to-revision 指定修订,则使用最近一次成功部署的修订。

  2. 部署过程中会禁用 DeploymentConfig 中的镜像更改触发器,以防止在回滚完成不久后意外启动新的部署过程。

    重新启用镜像更改触发器:

    $ oc set triggers dc/<name> --auto
注意

DeploymentConfig 也支持最新部署过程失败时自动回滚到配置的最近一次成功修订。这时,系统会原样保留部署失败的最新模板,由用户来修复其配置。

4.2.1.5. 在容器内执行命令

您可以为容器添加命令,用来覆盖决镜像的 ENTRYPOINT 设置来改变容器的启动行为。这与生命周期 hook 不同,后者在每个部署的指定时间点上运行一次。

流程

  1. 在 DeploymentConfig 的 spec 字段中添加 command 参数。您也可以添加 args 字段来修改 command(如果 command 不存在,则修改 ENTRYPOINT)。

    spec:
      containers:
        -
        name: <container_name>
        image: 'image'
        command:
          - '<command>'
        args:
          - '<argument_1>'
          - '<argument_2>'
          - '<argument_3>'

    例如,使用 -jar/opt/app-root/springboots2idemo.jar 参数来执行 java 命令:

    spec:
      containers:
        -
        name: example-spring-boot
        image: 'image'
        command:
          - java
        args:
          - '-jar'
          - /opt/app-root/springboots2idemo.jar

4.2.1.6. 查看部署日志

流程

  1. 获得指定 DeploymentConfig 的最新修订的日志:

    $ oc logs -f dc/<name>

    如果最新的修订正在运行或已失败,命令会返回负责部署 Pod 的进程的日志。如果成功,它将从应用程序的 Pod 返回日志。

  2. 您还可以查看来自旧的失败部署进程的日志,只要存在这些进程(旧的 ReplicationController 及其部署器 Pod)并且没有手动清理或删除:

    $ oc logs --version=1 dc/<name>

4.2.1.7. 部署触发器

DeploymentConfig 可以包含触发器,推动创建新部署过程来响应集群内的事件。

警告

如果 DeploymentConfig 上没有定义任何触发器,则默认添加 ConfigChange 触发器。如果触发器定义为空白字段,则必须手动启动部署。

ConfigChange 部署触发器

当 DeploymentConfig 的 Pod 模板中检测到配置更改时,ConfigChange 触发器会产生新的 ReplicationController。

注意

如果 DeploymentConfig 上定义了 ConfigChange 触发器,则在 DeploymentConfig 本身创建后会自动创建第一个 ReplicationController,而且不会暂停。

ConfigChange 部署触发器

triggers:
  - type: "ConfigChange"

imageChange 部署触发器

ImageChange 触发器会在镜像流标签的内容发生改变时(推送镜像的新版本时)产生新的 ReplicationController。

imageChange 部署触发器

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true 1
      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"

1
如果 imageChangeParams.automatic 字段设置为 false,则触发器被禁用。

在上例中,当 origin-ruby-sample 镜像流的 latest 标签值更改并且新镜像值与 DeploymentConfig 的 helloworld 容器中指定的当前镜像不同时,系统会使用新镜像为 helloworld 创建新的 ReplicationController。

注意

如果 DeploymentConfig 上定义了 ImageChange 触发器(带有 ConfigChange 触发器且 automatic=false,或者 automatic=true)并且 ImageChange 触发器指向的 ImageStreamTag 尚不存在,则初始部署过程将在镜像导入时或镜像由构建推送到 ImageStreamTag 时立即自动启动。

4.2.1.7.1. 设置部署触发器

流程

  1. 您可以使用 oc set triggers 命令为 DeploymentConfig 设置部署触发器。例如,若要设置 ImageChangeTrigger,请使用以下命令:

    $ oc set triggers dc/<dc_name> \
        --from-image=<project>/<image>:<tag> -c <container_name>

4.2.1.8. 设置部署资源

注意

只有在集群管理员启用了临时存储技术预览功能时,这个资源才可用。此功能默认为禁用。

部署由在节点上消耗资源(内存、CPU 和临时存储)的 Pod 完成。默认情况下,Pod 消耗无限的节点资源。但是,如果某个项目指定了默认容器限值,则 Pod 消耗的资源会被限制在这些限值范围内。

您还可以在部署策略中指定资源限值来限制资源使用。部署资源可以用在 Recreate 、Rolling 或 Custom 部署策略中。

流程

  1. 在以下示例中,resourcescpumemoryephemeral-storage 中每一个都是可选的:

    type: "Recreate"
    resources:
      limits:
        cpu: "100m" 1
        memory: "256Mi" 2
        ephemeral-storage: "1Gi" 3
    1
    cpu 以 CPU 单元数为单位:100m 表示 0.1 个 CPU 单元(100 * 1e-3)。
    2
    memory 以字节为单位:256Mi 表示 268435456 字节 (256 * 2 ^ 20)。
    3
    ephemeral-storage 以字节为单位:1Gi 表示 1073741824 字节 (2 ^ 30)。只有集群管理员启用了临时存储技术预览功能时才适用。

    不过,如果您的项目定义了配额,则需要以下两项之一:

    • 设定了显式 requestsresources 部分:

        type: "Recreate"
        resources:
          requests: 1
            cpu: "100m"
            memory: "256Mi"
            ephemeral-storage: "1Gi"
      1
      requests 对象包含与配额中资源列表对应的资源列表。
    • 您项目中定义的限值范围,其中 LimitRange 对象中的默认值应用到部署过程中创建的 Pod。

    要设置部署资源,请选择以上选项之一。否则,部署 Pod 创建失败,显示无法满足配额要求。

4.2.1.9. 手动扩展

除了回滚外,您还可以通过手动缩放来对副本数量进行细致的控制。

注意

也可以使用 oc autoscale 命令自动扩展 Pod。

流程

  1. 要手动扩展 DeploymentConfig,请使用 oc scale 命令。例如,以下命令将 frontend DeploymentConfig 中的副本数设置为 3

    $ oc scale dc frontend --replicas=3

    副本数量最终会传播到 DeploymentConfig frontend 配置的部署的预期和当前状态。

4.2.1.10. 从 DeploymentConfig 访问私有存储库

您可以在 DeploymentConfig 中添加 secret,让它能够访问私有存储库中的镜像。此流程演示了 OpenShift Container Platform Web 控制台方法。

流程

  1. 创建新项目。
  2. Workloads 页面中,创建一个含有用于访问私有镜像存储库的凭证的 secret。
  3. 创建 DeploymentConfig。
  4. 在 DeploymentConfig 编辑器页面中,设置 Pull Secret 并保存您的更改。

4.2.1.11. 将 Pod 分配给特定的节点

您可以结合使用节点选择器和带标签的节点来控制 Pod 的放置。

集群管理员可为项目设置默认的节点选择器,以便将 Pod 放置限制到特定的节点。作为开发人员,您可以设置 Pod 配置的节点选择器来进一步限制节点。

流程

  1. 要在创建 Pod 时添加节点选择器,请编辑 Pod 配置并添加 nodeSelector 值。这可添加到单个 Pod 配置中,也可以添加到 Pod 模板中:

    apiVersion: v1
    kind: Pod
    spec:
      nodeSelector:
        disktype: ssd
    ...

    具有节点选择器时创建的 Pod 会分配给带有指定标签的节点。这里指定的标签将与集群管理员添加的标签结合使用。

    例如,如果项目中包含由集群管理员添加的 type=user-noderegion=east 标签,并且您将上述 disktype: ssd 标签添加到某一 Pod,那么该 Pod 仅会调度到具有所有这三个标签的节点上。

    注意

    标签只能设置为一个值;因此,如果在具有管理员设置的默认值 region=east 的 Pod 配置中设置节点选择器 region=west,这会导致 Pod 永不会被调度。

4.2.1.12. 使用其他服务帐户运行 Pod

您可以使用非默认服务帐户运行 Pod。

流程

  1. 编辑 DeploymentConfig:

    $ oc edit dc/<deployment_config>
  2. serviceAccountserviceAccountName 参数添加到 spec 字段,再指定您要使用的服务帐户:

    spec:
      securityContext: {}
      serviceAccount: <service_account>
      serviceAccountName: <service_account>