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