OpenShift 文档正在迁移，很快将只能在 docs.redhat.com（所有 Red Hat 产品文档的中心）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

了解部署

OpenShift Container Platform 中的Deployment 和 DeploymentConfig API 对象提供了两种相似但不同的方法来对常见用户应用程序进行细粒度管理。它们由以下单独的 API 对象组成：

  • 一个Deployment 或 DeploymentConfig 对象，两者都描述了应用程序特定组件作为 Pod 模板的所需状态。

  • Deployment 对象包含一个或多个副本集，其中包含作为 Pod 模板的部署状态的某个时间点的记录。类似地，DeploymentConfig 对象包含一个或多个复制控制器，它们早于副本集。

  • 一个或多个 Pod，它们代表应用程序特定版本的实例。

除非您需要 DeploymentConfig 对象提供的特定功能或行为，否则请使用Deployment 对象。

从 OpenShift Container Platform 4.14 开始，DeploymentConfig 对象已弃用。DeploymentConfig 对象仍然受支持，但不建议用于新安装。只有安全相关和关键问题才会被修复。

请改用Deployment 对象或其他替代方案来为 Pod 提供声明性更新。

部署的构建块

部署和部署配置分别通过使用原生 Kubernetes API 对象ReplicaSet 和 ReplicationController 作为其构建块来启用。

用户无需操作由Deployment 或 DeploymentConfig 对象拥有的副本集、复制控制器或 Pod。部署系统确保更改被适当传播。

如果现有的部署策略不适合您的用例，并且您必须在部署的生命周期中运行手动步骤，那么您应该考虑创建自定义部署策略。

以下部分将提供有关这些对象的更多详细信息。

副本集

ReplicaSet 是一个原生 Kubernetes API 对象，它确保在任何给定时间都运行指定数量的 Pod 副本。

只有在您需要自定义更新编排或根本不需要更新的情况下才使用副本集。否则，请使用部署。副本集可以独立使用，但部署使用它们来编排 Pod 的创建、删除和更新。部署自动管理其副本集，提供 Pod 的声明性更新，并且不必手动管理它们创建的副本集。

以下是一个ReplicaSet 定义示例

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: (1)
    matchLabels: (2)
      tier: frontend
    matchExpressions: (3)
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always
1 对一组资源的标签查询。matchLabels 和 matchExpressions 的结果在逻辑上是连接的。
2 基于相等的筛选器，用于指定标签与筛选器匹配的资源。
3 基于集合的筛选器，用于过滤键。这将选择键等于tier且值等于frontend的所有资源。

复制控制器

与副本集类似，复制控制器确保始终运行指定数量的 Pod 副本。如果 Pod 退出或被删除，复制控制器将实例化更多 Pod 直到达到定义的数量。同样，如果运行的 Pod 超过所需数量，它将删除多余的 Pod 以匹配定义的数量。副本集和复制控制器之间的区别在于，副本集支持基于集合的选择器要求，而复制控制器仅支持基于相等的筛选器要求。

副本控制器配置包含以下内容：

  • 所需副本数量，可在运行时调整。

  • 创建复制 Pod 时使用的Pod 定义。

  • 用于识别托管 Pod 的选择器。

选择器是一组分配给由副本控制器管理的 Pod 的标签。这些标签包含在副本控制器实例化的Pod 定义中。副本控制器使用选择器来确定已经运行了多少个 Pod 实例，以便根据需要进行调整。

副本控制器不根据负载或流量执行自动缩放，因为它不跟踪这两者。相反，这需要由外部自动缩放器调整其副本数量。

使用DeploymentConfig 创建副本控制器，而不是直接创建副本控制器。

如果需要自定义编排或不需要更新，请使用副本集而不是副本控制器。

以下是副本控制器的示例定义：

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1  (1)
  selector:    (2)
    name: frontend
  template:    (3)
    metadata:
      labels:  (4)
        name: frontend (5)
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always
1 要运行的 Pod 的副本数量。
2 要运行的 Pod 的标签选择器。
3 控制器创建的 Pod 模板。
4 Pod 上的标签应包含来自标签选择器的标签。
5 展开任何参数后，最大名称长度为 63 个字符。

部署

Kubernetes 在 OpenShift Container Platform 中提供了一个名为Deployment的一流原生 API 对象类型。Deployment 对象描述应用程序特定组件作为 Pod 模板的期望状态。部署创建副本集，后者编排 Pod 生命周期。

例如，以下部署定义创建一个副本集，以启动一个hello-openshift Pod。

部署定义
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
    spec:
      containers:
      - name: hello-openshift
        image: openshift/hello-openshift:latest
        ports:
        - containerPort: 80

DeploymentConfig 对象

从 OpenShift Container Platform 4.14 开始，DeploymentConfig 对象已弃用。DeploymentConfig 对象仍然受支持，但不建议用于新安装。只有安全相关和关键问题才会被修复。

请改用Deployment 对象或其他替代方案来为 Pod 提供声明性更新。

基于副本控制器，OpenShift Container Platform 通过DeploymentConfig 对象的概念增加了对软件开发和部署生命周期的扩展支持。在最简单的情况下，DeploymentConfig 对象创建一个新的副本控制器并让它启动 Pod。

但是，来自DeploymentConfig 对象的 OpenShift Container Platform 部署还提供了从现有映像部署过渡到新映像的功能，以及定义在创建副本控制器之前或之后运行的挂钩。

DeploymentConfig 部署系统提供以下功能：

  • 一个DeploymentConfig 对象，它是运行应用程序的模板。

  • 响应事件驱动自动部署的触发器。

  • 用户可自定义的部署策略，用于从先前版本过渡到新版本。策略在通常称为部署过程的 Pod 内运行。

  • 一组挂钩（生命周期挂钩），用于在部署生命周期的不同点执行自定义行为。

  • 应用程序的版本控制，以支持在部署失败时手动或自动回滚。

  • 手动副本缩放和自动缩放。

创建DeploymentConfig 对象时，会创建一个表示DeploymentConfig 对象 Pod 模板的副本控制器。如果部署发生更改，则会创建一个具有最新 Pod 模板的新副本控制器，并且会运行一个部署过程以缩减旧副本控制器并扩展新副本控制器。

随着应用程序实例的创建，它们会自动从服务负载均衡器和路由器中添加和删除。只要您的应用程序在收到TERM 信号时支持优雅关闭，您就可以确保正在运行的用户连接有机会正常完成。

OpenShift Container Platform DeploymentConfig 对象定义以下详细信息：

  1. ReplicationController 定义的元素。

  2. 自动创建新部署的触发器。

  3. 部署之间过渡的策略。

  4. 生命周期挂钩。

每次手动或自动触发部署时，部署程序 Pod 都会管理部署（包括缩减旧副本控制器、扩展新副本控制器和运行挂钩）。部署 Pod 在完成部署后会无限期地保留，以保留其部署日志。当部署被另一个部署取代时，会保留以前的副本控制器，以便在需要时轻松回滚。

DeploymentConfig 定义示例
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange (1)
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  (2)
  strategy:
    type: Rolling      (3)
1 配置更改触发器会在检测到部署配置的 Pod 模板中的更改时生成新的副本控制器。
2 映像更改触发器会在命名映像流中出现新版本的备份映像时创建新的部署。
3 默认的Rolling 策略可在部署之间实现无停机过渡。

比较 Deployment 和 DeploymentConfig 对象

OpenShift Container Platform 支持 Kubernetes Deployment 对象和 OpenShift Container Platform 提供的DeploymentConfig 对象；但是，建议使用Deployment 对象，除非您需要DeploymentConfig 对象提供的特定功能或行为。

以下部分将更详细地介绍这两种对象类型的区别，以进一步帮助您确定使用哪种类型。

从 OpenShift Container Platform 4.14 开始，DeploymentConfig 对象已弃用。DeploymentConfig 对象仍然受支持，但不建议用于新安装。只有安全相关和关键问题才会被修复。

请改用Deployment 对象或其他替代方案来为 Pod 提供声明性更新。

设计

Deployment 和DeploymentConfig 对象之间的一个重要区别在于，每种设计为推出过程选择的CAP 定理的属性。DeploymentConfig 对象更偏向一致性，而Deployments 对象更偏向可用性而非一致性。

对于DeploymentConfig 对象，如果运行部署程序 Pod 的节点出现故障，它将不会被替换。该过程将等待节点重新上线或手动删除。手动删除节点也会删除相应的 Pod。这意味着您无法删除 Pod 来解除推出的阻塞，因为 kubelet 负责删除关联的 Pod。

但是，部署推出由控制器管理器驱动。控制器管理器在主节点上以高可用性模式运行，并使用领导者选举算法将可用性置于一致性之上。在故障期间，其他主节点可能同时对同一部署进行操作，但此问题将在故障发生后不久得到解决。

特定于部署的功能

滚动更新

与使用部署器 Pod 来进行每次新版本发布的 DeploymentConfig 对象不同，Deployment 对象的部署流程由控制器循环驱动。这意味着 Deployment 对象可以拥有尽可能多的活动副本集，最终部署控制器会缩减所有旧的副本集并扩展最新的副本集。

DeploymentConfig 对象最多只能运行一个部署器 Pod，否则多个部署器在尝试扩展它们认为应该是最新复制控制器的过程中可能会发生冲突。因此，任何时候最多只能有两个复制控制器处于活动状态。最终，这导致 Deployment 对象的快速发布速度更快。

比例缩放

由于部署控制器是 Deployment 对象拥有的新旧副本集大小的唯一真相来源，因此它可以扩展正在进行的发布。根据每个副本集的大小，会按比例分配额外的副本。

在进行发布时，无法缩放 DeploymentConfig 对象，因为控制器在关于新复制控制器大小的部署器进程中会出现问题。

暂停中途发布

可以在任何时候暂停部署，这意味着您也可以暂停正在进行的发布。但是，您目前无法暂停部署器 Pod；如果您尝试在发布中途暂停部署，部署器进程不会受到影响，并会继续直到完成。

DeploymentConfig 对象特定功能

自动回滚

目前，部署不支持在发生故障时自动回滚到上次成功部署的副本集。

触发器

部署有一个隐式配置更改触发器，即部署的 Pod 模板中的每次更改都会自动触发新的发布。如果您不希望在 Pod 模板更改时进行新的发布，请暂停部署。

$ oc rollout pause deployments/<name>
生命周期钩子

部署尚不支持任何生命周期钩子。

自定义策略

部署不支持用户指定的自定义部署策略。