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
×
了解部署
OpenShift Dedicated 中的Deployment 和 DeploymentConfig API 对象提供了两种相似但不同的方法来对常见用户应用程序进行细粒度管理。它们由以下单独的 API 对象组成：
-
一个
Deployment或DeploymentConfig对象，两者都描述了应用程序特定组件作为 Pod 模板的所需状态。 -
Deployment对象包含一个或多个副本集，其中包含作为 Pod 模板的部署状态的某个时间点的记录。类似地，DeploymentConfig对象包含一个或多个复制控制器，它们早于副本集。 -
一个或多个 Pod，它们表示应用程序特定版本的实例。
除非您需要 DeploymentConfig 对象提供的特定功能或行为，否则请使用 Deployment 对象。
|
从 OpenShift Dedicated 4.14 开始， 请改用 |
部署的构建块
部署和部署配置分别通过使用原生 Kubernetes API 对象ReplicaSet 和 ReplicationController 作为其构建块来启用。
用户不必操作由Deployment 或 DeploymentConfig 对象拥有的副本集、复制控制器或 Pod。部署系统确保更改被适当地传播。
|
如果现有部署策略不适合您的用例，并且您必须在部署的生命周期中运行手动步骤，那么您应该考虑创建自定义部署策略。 |
以下部分将提供有关这些对象的更多详细信息。
副本集
ReplicaSet 是 Kubernetes 原生的 API 对象，它确保在任何给定时间都运行指定数量的 Pod 副本。
|
只有在需要自定义更新编排或根本不需要更新时才使用副本集。否则，请使用 Deployment。副本集可以独立使用，但 Deployment 使用它们来编排 Pod 的创建、删除和更新。Deployment 自动管理其副本集，提供 Pod 的声明式更新，无需手动管理其创建的副本集。 |
以下是 ReplicaSet 定义示例
| 1 | 对一组资源进行标签查询。matchLabels 和 matchExpressions 的结果在逻辑上是连接的。 |
| 2 | 基于相等的选取器，用于指定其标签与选取器匹配的资源。 |
| 3 | 基于集合的选取器，用于筛选键。这将选择所有键等于 tier 且值等于 frontend 的资源。 |
复制控制器
与副本集类似，复制控制器确保始终运行指定数量的 Pod 副本。如果 Pod 退出或被删除，复制控制器将实例化更多 Pod，直到达到定义的数量。同样，如果运行的 Pod 多于所需数量，它将删除多余的 Pod，以匹配定义的数量。副本集和复制控制器之间的区别在于，副本集支持基于集合的选取器要求，而复制控制器仅支持基于相等的选取器要求。
复制控制器配置包括：
-
所需的副本数量，可以在运行时调整。
-
创建复制 Pod 时使用的
Pod定义。 -
用于识别受管 Pod 的选取器。
选取器是一组分配给由复制控制器管理的 Pod 的标签。这些标签包含在复制控制器实例化的 Pod 定义中。复制控制器使用选取器来确定已经运行了多少个 Pod 实例，以便根据需要进行调整。
复制控制器不根据负载或流量执行自动缩放，因为它不跟踪两者。这需要由外部自动缩放器调整其副本数量。
|
使用 如果您需要自定义编排或不需要更新，请使用副本集而不是复制控制器。 |
以下是复制控制器定义示例
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 个字符。 |
Deployment
Kubernetes 在 OpenShift Dedicated 中提供了一个一流的原生 API 对象类型，称为 Deployment。Deployment 对象描述应用程序特定组件作为 Pod 模板的所需状态。Deployment 创建副本集，这些副本集编排 Pod 生命周期。
例如，以下 Deployment 定义创建一个副本集，以启动一个 hello-openshift Pod
Deployment 定义
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: 80DeploymentConfig 对象
|
从 OpenShift Dedicated 4.14 开始， 请改用 |
在复制控制器的基础上，OpenShift Dedicated 通过 DeploymentConfig 对象的概念，增加了对软件开发和部署生命周期的扩展支持。在最简单的情况下，DeploymentConfig 对象创建一个新的复制控制器并让它启动 Pod。
但是，来自 DeploymentConfig 对象的 OpenShift Dedicated Deployment 也提供了从现有镜像部署过渡到新镜像的能力，并且还定义了在创建复制控制器之前或之后运行的钩子。
DeploymentConfig 部署系统提供以下功能：
-
一个
DeploymentConfig对象，它是运行应用程序的模板。 -
响应事件驱动自动部署的触发器。
-
用户可自定义的部署策略，用于从先前版本过渡到新版本。策略在一个通常被称为部署进程的 Pod 内运行。
-
一组钩子（生命周期钩子），用于在部署生命周期的不同点执行自定义行为。
-
应用程序的版本控制，以便在部署失败的情况下手动或自动回滚。
-
手动复制缩放和自动缩放。
创建 DeploymentConfig 对象时，会创建一个表示 DeploymentConfig 对象 Pod 模板的复制控制器。如果部署发生更改，则会创建一个具有最新 Pod 模板的新复制控制器，并且会运行一个部署过程来缩减旧复制控制器并扩展新复制控制器。
随着应用程序实例的创建，它们会自动从服务负载均衡器和路由器中添加和删除。只要您的应用程序在收到 TERM 信号时支持优雅关闭，您就可以确保正在运行的用户连接有机会正常完成。
OpenShift Dedicated DeploymentConfig 对象定义以下细节：
-
ReplicationController定义的元素。 -
自动创建新部署的触发器。
-
部署之间过渡的策略。
-
生命周期钩子。
每次触发部署（无论是手动还是自动），一个部署 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 Dedicated 支持 Kubernetes Deployment 对象和 OpenShift Dedicated 提供的 DeploymentConfig 对象；但是，建议使用 Deployment 对象，除非您需要 DeploymentConfig 对象提供的特定功能或行为。
以下部分将更详细地介绍这两种对象类型之间的区别，以进一步帮助您决定使用哪种类型。
|
从 OpenShift Dedicated 4.14 开始， 请改用 |
设计
Deployment 对象和 DeploymentConfig 对象之间的一个重要区别在于，每种设计为推出过程选择的 CAP 定理 属性。DeploymentConfig 对象更注重一致性，而 Deployment 对象更注重可用性而不是一致性。
对于 DeploymentConfig 对象，如果运行部署 Pod 的节点宕机，它将不会被替换。该过程将等待节点重新上线或手动删除。手动删除节点也会删除相应的 Pod。这意味着您不能删除 Pod 来解除推出的阻塞，因为 kubelet 负责删除相关的 Pod。
然而，部署 rollout 由控制器管理器驱动。控制器管理器在主节点上以高可用性模式运行，并使用 leader election 算法优先保证可用性而非一致性。在发生故障期间，其他主节点可能同时对同一部署进行操作，但此问题将在故障发生后不久得到解决。
Deployment 特有特性
滚动更新
与使用部署器 Pod 进行每次新 rollout 的 DeploymentConfig 对象不同，Deployment 对象的部署过程由控制器循环驱动。这意味着 Deployment 对象可以拥有尽可能多的活动副本集，最终部署控制器将缩减所有旧副本集并扩展最新的副本集。
DeploymentConfig 对象最多只能运行一个部署器 Pod，否则多个部署器在尝试扩展它们认为应该是最新复制控制器的过程中可能会发生冲突。因此，任何时候最多只能有两个复制控制器处于活动状态。最终，这导致 Deployment 对象的快速 rollout 更快。
比例缩放
由于部署控制器是 Deployment 对象拥有的新旧副本集大小的唯一真相来源，因此它可以扩展正在进行的 rollout。附加副本将根据每个副本集的大小按比例分配。
当 rollout 正在进行时，DeploymentConfig 对象无法进行缩放，因为控制器在关于新复制控制器大小的部署器进程中会出现问题。
暂停中期 rollout
部署可以在任何时间点暂停，这意味着您也可以暂停正在进行的 rollout。但是，您目前无法暂停部署器 Pod；如果您尝试在 rollout 中间暂停部署，则部署器进程不会受到影响，并将继续运行直到完成。