为 Metro-DR 扩展集群配置 OpenShift Data Foundation
有关如何在两个不同地理位置配置 OpenShift Data Foundation 的说明,以提供具有灾难恢复功能的存储基础架构。
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈:
关于特定内容的简单评论:
- 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
- 用鼠标指针高亮显示您想评论的文本部分。
- 点在高亮文本上弹出的 Add Feedback。
- 按照显示的步骤操作。
要提交更复杂的反馈,请创建一个 Bugzilla ticket:
- 进入 Bugzilla 网站。
- 在 Component 部分中,选择 文档。
- 在 Description 中输入您要提供的信息。包括文档相关部分的链接。
- 点 Submit Bug。
第 1 章 Metro-DR 扩展集群简介
Red Hat OpenShift Data Foundation 部署可以在两个不同的地理位置扩展,为存储基础架构提供灾难恢复功能。当遇到灾难时,如两个位置中的一个部分或完全不可用,OpenShift Container Platform 部署中的 OpenShift Data FoundationOpenShift 必须能够存活。此解决方案仅适用于在基础架构服务器之间具有特定延迟要求的 edorpolitan 跨数据中心。
目前,您可以使用扩展集群来部署 Metro-DR 解决方案,其中位于不同位置的 OpenShift Container Platform 节点间的延迟不超过 4 毫秒往返用时(RTT)。如果您计划以更高的延迟进行部署,请联系红帽客户支持。
下图显示了扩展了 Metro-DR 集群的最简单部署:
OpenShift 节点和 OpenShift Data Foundation 守护进程
在上图中,Arbiter 区域中部署的 OpenShift Data Foundation 监控 pod 具有 master 节点内置的容错能力。图显示每个 Data Zone 中的 master 节点,它们是高可用性 OpenShift Container Platform control plane 所需要的。另外,重要的一点是,其中一个区的 OpenShift Container Platform 节点与另外两个区的 OpenShift Container Platform 节点需要具有网络连接。
第 2 章 准备部署启用了灾难恢复功能的存储集群
2.1. 启用 Metro-DR 的要求
- 确保您在三个不同的区中至少有三个 OpenShift Container Platform master 节点。三个区域中的每一区域中有一个主节点。
- 确保至少四个 OpenShift Container Platform worker 节点分布在两个数据区中。
- 对于裸机上的扩展集群,请使用 SSD 驱动器作为 OpenShift Container Platform master 节点的根驱动器。
- 确保每个节点已预先标记其 zone 标签。如需更多信息,请参阅将拓扑区标签应用到 OpenShift Container Platform 节点部分。
- Metro-DR 解决方案专为在不同区域之间延迟不超过 2 毫秒的部署而设计,其最长往返用时(RTT)为 4 ms。如果您计划以更高的延迟进行部署,请联系红帽客户支持。
灵活的缩放和仲裁程序不能与缩放逻辑冲突同时启用。通过灵活扩展,您可以一次向 OpenShift Data Foundation 集群添加一个节点。而在 Arbiter 集群中,您需要在每个数据区中添加至少一个节点。
2.2. 将拓扑区标签应用到 OpenShift Container Platform 节点
在一个站点停机时,具有仲裁器功能的区域使用仲裁器标签。这些标签是任意的,对于这三个位置来说必须是唯一的。
例如,您可以按如下方式标记节点:
topology.kubernetes.io/zone=arbiter for Master0 topology.kubernetes.io/zone=datacenter1 for Master1, Worker1, Worker2 topology.kubernetes.io/zone=datacenter2 for Master2, Worker3, Worker4
将标签应用到节点:
$ oc label node <NODENAME> topology.kubernetes.io/zone=<LABEL>
<NODENAME>- 是节点的名称
<LABEL>- 是拓扑区标签
使用三个区的示例标签来验证标签:
$ oc get nodes -l topology.kubernetes.io/zone=<LABEL> -o name<LABEL>是拓扑区标签
或者,您可以运行单个命令来查看带有其区域的所有节点。
$ oc get nodes -L topology.kubernetes.io/zone
现在,Metro DR 扩展集群拓扑区标签应用于适当的 OpenShift Container Platform 节点,以定义三个位置。
2.3. 安装 Local Storage Operator
在本地存储设备上创建 Red Hat OpenShift Data Foundation 集群前,请先从 Operator Hub 安装 Local Storage Operator。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → OperatorHub。
-
在 Filter by keyworr 框中键入
local storage,从操作器列表中搜索 Local Storage operator 并单击它。 在 Install Operator 页面中设置以下选项:
-
更新频道(如
4.9或stable) - 安装模式是 A specific namespace on the cluster。
- Installed Namespace 为 Operator recommended namespace openshift-local-storage。
- 将批准更新为 Automatic。
-
更新频道(如
- 点 Install。
验证步骤
- 验证 Local Storage Operator 是否显示绿色勾号,代表安装成功。
2.4. 安装 Red Hat OpenShift Data Foundation Operator
您可以使用 Red Hat OpenShift Container Platform Operator Hub 安装 Red Hat OpenShift Data Foundation Operator。
先决条件
- 使用具有 cluster-admin 和 Operator 安装权限的账户访问 OpenShift Container Platform 集群。
- 您必须至少在 Red Hat OpenShift Container Platform 集群的两个数据中心中平均分配四个 worker 节点。
- 有关其他资源要求,请参阅规划您的部署。
当您需要覆盖 OpenShift Data Foundation 的集群范围默认节点选择器时,您可以在命令行界面中使用以下命令为
openshift-storage命名空间指定空白节点选择器(在这种情况下创建 openshift-storage 命名空间):$ oc annotate namespace openshift-storage openshift.io/node-selector=
-
将节点作为
infra污点,以确保只在该节点上调度 Red Hat OpenShift Data Foundation 资源。这有助于您节省订阅成本。如需更多信息,请参阅管理和分配存储资源指南中的如何将专用 worker 节点用于 Red Hat OpenShift Data Foundation 章节。
流程
- 登录 OpenShift Web 控制台。
- 点 Operators → OperatorHub。
-
在 Filter by keyword 框中滚动或键入
OpenShift Data Foundation,以查找 OpenShift Data Foundation Operator。 - 点 Install。
在 Install Operator 页面中设置以下选项:
- 更新频道是 stable-4.9。
- 安装模式是 A specific namespace on the cluster。
-
Installed Namespace 为 Operator recommended namespace openshift-storage。如果命名空间
openshift-storage不存在,它会在 Operator 安装过程中创建。 将 Approval Strategy 选为 Automatic 或 Manual。
如果选择 Automatic 更新,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需任何干预。
如果选择了 手动 更新,则 OLM 会创建一个更新请求。作为集群管理员,您必须手动批准该更新请求,才能将 Operator 更新至更新的版本。
- 确保为 Console 插件 选择了 Enable 选项。
- 点 Install。
验证步骤
验证 OpenShift Data Foundation Operator 是否显示绿色勾号(代表安装成功)。
第 3 章 创建 OpenShift Data Foundation 集群
先决条件
- 确定您满足了准备在启用了灾难恢复部分部署存储集群时的所有要求。
流程
在 OpenShift Web 控制台中,点 Operators → Installed Operators 查看所有已安装的 Operator。
确保所选 项目 为
openshift-storage。- 单击 OpenShift Data Foundation 操作器,然后单击 Create StorageSystem。
- 在 Backing storage 页面中,选择 Create a new StorageClass using the local storage devices 选项。
点 Next。
重要如果还没有安装,系统会提示您安装 Local Storage Operator。点 Install 并按照 Installing Local Storage Operator 中所述的步骤进行操作。
在 Create local volume set 页面中,提供以下信息:
为 LocalVolumeSet 和 StorageClass 输入一个名称。
默认情况下,存储类名称会出现本地卷集名称。您可以更改名称。
选择以下任意一项:
所有节点上的磁盘
使用与所有节点上所选过滤器匹配的可用磁盘。
所选节点上的磁盘
仅在所选节点上使用与所选过滤器匹配的可用磁盘。
重要如果选择的节点与 OpenShift Data Foundation 的一个聚合的 30 个 CPU 和 72 GiB RAM 的要求不匹配,则会部署一个最小的集群。
如需最低起始节点要求,请参阅 规划指南中的资源要求部分。
-
选择
SSD或NVMe来构建受支持的配置。您可以为不支持的测试安装选择HDD。 展开 Advanced 部分并设置以下选项:
卷模式
默认会选择块。
设备类型
从下拉列表中选择一个或多个设备类型。
磁盘大小
为设备设置最小 100GB 大小,以及需要包含的设备的最大可用大小。
磁盘限制上限
这表示节点上可以创建的 PV 数量上限。如果此字段留空,则为匹配节点上的所有可用磁盘创建 PV。
点 Next。
此时会显示一个用于确认创建 LocalVolumeSet 的弹出窗口。
- 单击 Yes 以继续。
在 Capacity 和 nodes 页面中,配置以下内容:
如果要使用扩展集群,选择 Enable arbiter 复选框。这个选项只有在满足仲裁程序的所有先决条件并且填充了所选节点时才可用。如需更多信息,请参阅准备在启用了灾难恢复的情况下部署存储集群 [Technology Preview] 中的 Arbiter 扩展集群要求。
从下拉列表中选择 arbiter 区域。
可用的原始容量会根据与存储类关联的所有附加磁盘填充容量值。这将需要一些时间才能出现。
Selected nodes 列表根据存储类显示节点。
- 点 Next。
可选:在 Security and network 页面中,根据您的要求进行配置:
- 选中 启用加密 复选框,以加密块和文件存储。
选择以下一个或两个加密级别 :
集群范围的加密
加密整个集群(块和文件)。
StorageClass 加密
使用启用加密的存储类创建加密的持久性卷(仅块)。
选中连接到外部密钥管理服务复选框。这是集群范围加密的可选选项。
-
默认情况下,Key Management Service Provider 设置为
Vault。 - 输入 Vault Service Name、Vault 服务器的主机地址 ('https://<hostname 或 ip>')、端口号和 Token。
-
默认情况下,Key Management Service Provider 设置为
展开 Advanced Settings,以根据您的 Vault 配置输入额外的设置和证书详情:
- 在后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
- 可选:输入 TLS Server Name 和 Vault Enterprise 命名空间。
- 上传对应的 PEM 编码证书文件,以提供 CA 证书、客户端证书和客户端私钥。
- 点击 Save。
选择以下任意一项:
默认(SDN)
如果您使用的是单个网络。
自定义(Multus)
如果您使用多个网络接口:
- 从下拉菜单中选择公共网络接口。
从下拉菜单中选择集群网络接口。
注意如果您只使用一个额外网络接口,请选择单个
NetworkAttachementDefinition,即ocs-public-cluster用于公共网络接口,并将 Cluster Network Interface 留空。
- 点 Next。
在 Review and create 页面中,检查配置详情。
若要修改任何配置设置,请单击 Back 以返回到上一配置页面。
- 单击 Create StorageSystem。
对于使用密钥管理系统(KMS)的集群范围加密,如果您使用了 Vault Key/Value(KV)机密引擎 API 版本 2,则您需要编辑
configmap。- 在 OpenShift Web 控制台中,导航到 Workloads → ConfigMaps。
- 要查看 KMS 连接详情,点 ocs-kms-connection-details。
编辑 configmap。
- 点 Action menu (⋮) → Edit ConfigMap。
将
VAULT_BACKEND参数设置为v2。kind: ConfigMap apiVersion: v1 metadata: name: ocs-kms-connection-details [...] data: KMS_PROVIDER: vault KMS_SERVICE_NAME: vault [...] VAULT_BACKEND: v2 [...]- 点击 Save。
验证步骤
验证已安装存储集群的最终状态:
- 在 OpenShift Web 控制台中,导航到 Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources。
-
验证
StorageCluster的Status是否为Ready,并且旁边有一个绿色勾号标记。
对于部署的仲裁模式:
- 在 OpenShift Web 控制台中,导航到 Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources → ocs-storagecluster。
在 YAML 选项卡中,在
spec部分搜索arbiter键,并确保enable设置为true。spec: arbiter: enable: true [..] nodeTopologies: arbiterLocation: arbiter #arbiter zone storageDeviceSets: - config: {} count: 1 [..] replica: 4 status: conditions: [..] failureDomain: zone
- 要验证 OpenShift Data Foundation 的所有组件是否已成功安装,请参阅验证您的 OpenShift 数据基础安装。
第 4 章 验证 OpenShift Data Foundation
验证 OpenShift Data Foundation 是否已正确部署:
4.1. 验证 pod 的状态
流程
- 从 OpenShift Web 控制台点 Workloads → Pods。
从 Project 下拉列表中选择
openshift-storage。注意如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。
有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息,请参阅 表 4.1 “对应 OpenShift Data Foundation 集群的 Pod”。
-
点 Running 和 Completed 标签页验证以下 pod 是否处于
Running和Completed状态:
表 4.1. 对应 OpenShift Data Foundation 集群的 Pod
| 组件 | 对应的 pod |
|---|---|
| OpenShift Data Foundation Operator |
|
| Rook-ceph Operator |
(任何 worker 节点上有 1 个 pod) |
| 多云对象网关 |
|
| MON |
(5 个 pod 分布到 3 个区域,每个数据中心区域 2 个,1 个在仲裁区域内) |
| MGR |
(任何存储节点 2 个 pod) |
| MDS |
(2 个 pod 分布到 2 个数据中心区域) |
| RGW |
(2 个 pod 分布到 2 个数据中心区域) |
| CSI |
|
| rook-ceph-crashcollector |
(每个存储节点 1 个 pod,1 个 pod 在仲裁区域上) |
| OSD |
|
4.2. 验证 OpenShift Data Foundation 集群是否健康
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 在 Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
- 在 Block and File 选项卡的 Status 卡中,验证 Storage Cluster 是否具有绿色勾号。
- 在 Details 卡中,验证是否显示集群信息。
如需有关使用 Block and File 仪表板的 OpenShift Data Foundation 集群健康的更多信息,请参阅 监控 OpenShift Data Foundation。
4.3. 验证 Multicloud 对象网关是否健康
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
在 Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
- 在 Object 选项卡的 Status 卡 中,验证 Object Service 和数据弹性 都具有绿色勾号。
- 在 Details 卡中,验证是否显示了 MCG 信息。
如需有关使用对象服务仪表板的 OpenShift Data Foundation 集群健康的更多信息,请参阅监控 OpenShift Data Foundation。
4.4. 验证 OpenShift Data Foundation 特定的存储类是否存在
流程
- 从 OpenShift Web 控制台左侧窗格中,点击 Storage → Storage Classes。
验证是否在创建 OpenShift Data Foundation 集群时创建了以下存储类:
-
ocs-storagecluster-ceph-rbd -
ocs-storagecluster-cephfs -
openshift-storage.noobaa.io -
ocs-storagecluster-ceph-rgw
-
第 5 章 安装区识别示例应用程序
部署区域感知示例应用,以验证 OpenShift Data Foundation Metro-DR 设置是否正确配置。
随着数据区域之间的延迟,可以预期与节点和区域之间具有低延迟的 OpenShift 集群(例如,同一位置的所有节点)相比,可以看到性能下降。性能会下降多少,取决于区域之间的延迟和使用存储(如高写流量)的应用行为。请确保使用 Metro DR 集群配置测试关键应用程序,以确保应用程序性能达到所需的服务水平。
5.1. 安装区示例应用程序
ReadWriteMany(RWX)持久性卷声明(PVC)是使用 ocs-storagecluster-cephfs 存储类创建的。多个 pod 同时使用新创建的 RWX PVC。使用的应用称为文件上传程序。
演示应用程序如何在拓扑区间分布,以便在站点中断时仍然可用:
此演示是可行的,因为此应用共享同一个 RWX 卷来存储文件。这也适用于持久数据访问,因为 Red Hat OpenShift Data Foundation 被配置为具有区感知和高可用性的 Metro DR 扩展集群。
创建新项目。
$ oc new-project my-shared-storage
部署名为 file-uploader 的示例 PHP 应用。
$ oc new-app openshift/php:7.3-ubi8~https://github.com/christianh814/openshift-php-upload-demo --name=file-uploader
输出示例:
Found image 4f2dcc0 (9 days old) in image stream "openshift/php" under tag "7.2-ubi8" for "openshift/php:7.2- ubi8" Apache 2.4 with PHP 7.2 ----------------------- PHP 7.2 available as container is a base platform for building and running various PHP 7.2 applications and frameworks. PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated web pages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common use of PHP coding is probably as a replacement for CGI scripts. Tags: builder, php, php72, php-72 * A source build using source code from https://github.com/christianh814/openshift-php-upload-demo will be cr eated * The resulting image will be pushed to image stream tag "file-uploader:latest" * Use 'oc start-build' to trigger a new build --> Creating resources ... imagestream.image.openshift.io "file-uploader" created buildconfig.build.openshift.io "file-uploader" created deployment.apps "file-uploader" created service "file-uploader" created --> Success Build scheduled, use 'oc logs -f buildconfig/file-uploader' to track its progress. Application is not exposed. You can expose services to the outside world by executing one or more of the commands below: 'oc expose service/file-uploader' Run 'oc status' to view your app.查看构建日志并等待应用部署好。
$ oc logs -f bc/file-uploader -n my-shared-storage
输出示例:
Cloning "https://github.com/christianh814/openshift-php-upload-demo" ... [...] Generating dockerfile with builder image image-registry.openshift-image-regis try.svc:5000/openshift/php@sha256:d97466f33999951739a76bce922ab17088885db610c 0e05b593844b41d5494ea STEP 1: FROM image-registry.openshift-image-registry.svc:5000/openshift/php@s ha256:d97466f33999951739a76bce922ab17088885db610c0e05b593844b41d5494ea STEP 2: LABEL "io.openshift.build.commit.author"="Christian Hernandez <christ ian.hernandez@yahoo.com>" "io.openshift.build.commit.date"="Sun Oct 1 1 7:15:09 2017 -0700" "io.openshift.build.commit.id"="288eda3dff43b02f7f7 b6b6b6f93396ffdf34cb2" "io.openshift.build.commit.ref"="master" " io.openshift.build.commit.message"="trying to modularize" "io.openshift .build.source-location"="https://github.com/christianh814/openshift-php-uploa d-demo" "io.openshift.build.image"="image-registry.openshift-image-regi stry.svc:5000/openshift/php@sha256:d97466f33999951739a76bce922ab17088885db610 c0e05b593844b41d5494ea" STEP 3: ENV OPENSHIFT_BUILD_NAME="file-uploader-1" OPENSHIFT_BUILD_NAMESP ACE="my-shared-storage" OPENSHIFT_BUILD_SOURCE="https://github.com/christ ianh814/openshift-php-upload-demo" OPENSHIFT_BUILD_COMMIT="288eda3dff43b0 2f7f7b6b6b6f93396ffdf34cb2" STEP 4: USER root STEP 5: COPY upload/src /tmp/src STEP 6: RUN chown -R 1001:0 /tmp/src STEP 7: USER 1001 STEP 8: RUN /usr/libexec/s2i/assemble ---> Installing application source... => sourcing 20-copy-config.sh ... ---> 17:24:39 Processing additional arbitrary httpd configuration provide d by s2i ... => sourcing 00-documentroot.conf ... => sourcing 50-mpm-tuning.conf ... => sourcing 40-ssl-certs.sh ... STEP 9: CMD /usr/libexec/s2i/run STEP 10: COMMIT temp.builder.openshift.io/my-shared-storage/file-uploader-1:3 b83e447 Getting image source signatures [...]当您看到
Push successful后,命令提示符会从 tail 模式返回。注意new-app 命令直接从 git 存储库部署应用,而不使用 OpenShift 模板,因此默认情况下不创建 OpenShift 路由资源。您需要手动创建路线。
扩展应用程序
将应用缩放为四个副本,并公开其服务,使应用区域了解和可用。
$ oc expose svc/file-uploader -n my-shared-storage
$ oc scale --replicas=4 deploy/file-uploader -n my-shared-storage
$ oc get pods -o wide -n my-shared-storage
几分钟后,您应该有四个 file-uploader pod。重复上述命令,直到有 4 个文件加载程序容器集处于
Running状态。创建 PVC 并将其附加到应用程序中。
$ oc set volume deploy/file-uploader --add --name=my-shared-storage \ -t pvc --claim-mode=ReadWriteMany --claim-size=10Gi \ --claim-name=my-shared-storage --claim-class=ocs-storagecluster-cephfs \ --mount-path=/opt/app-root/src/uploaded \ -n my-shared-storage
这个命令:
- 创建 PVC。
- 更新应用部署,以包含卷定义。
- 更新应用部署,将卷挂载附加到指定的 mount-path 中。
- 使用四个应用 pod 创建一个新部署。
检查添加卷的结果。
$ oc get pvc -n my-shared-storage
输出示例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-shared-storage Bound pvc-5402cc8a-e874-4d7e-af76-1eb05bd2e7c7 10Gi RWX ocs-storagecluster-cephfs 52s
注意
ACCESS MODE已设置为 RWX。所有四个
file-uploaderpod 都使用相同的 RWX 卷。如果没有这种访问模式,OpenShift 不会尝试可靠地将多个容器集附加到同一持久卷(PV)。如果您试图扩展正在使用 ReadWriteOnce(RWO) PV 的部署,则 pod 可能会在同一节点上在一起。
5.2. 将 Deployment 修改为区域 Aware
目前,file-uploader Deployment 不是区域感知型,它可以调度同一区域中的所有 pod。在这种情况下,如果站点中断,则应用不可用。如需更多信息,请参阅使用 pod 拓扑分布限制控制 pod 放置。
在应用部署配置中添加容器集放置规则,使应用区域感知。
运行以下命令并查看输出:
$ oc get deployment file-uploader -o yaml -n my-shared-storage | less
输出示例:
[...] spec: progressDeadlineSeconds: 600 replicas: 4 revisionHistoryLimit: 10 selector: matchLabels: deployment: file-uploader strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: annotations: openshift.io/generated-by: OpenShiftNewApp creationTimestamp: null labels: deployment: file-uploader spec: # <-- Start inserted lines after here containers: # <-- End inserted lines before here - image: image-registry.openshift-image-registry.svc:5000/my-shared-storage/file-uploader@sha256:a458ea62f990e431ad7d5f84c89e2fa27bdebdd5e29c5418c70c56eb81f0a26b imagePullPolicy: IfNotPresent name: file-uploader [...]编辑部署以使用拓扑区标签。
$ oc edit deployment file-uploader -n my-shared-storage
在
Start和End(上一步中的输出中显示)之间添加以下新行:[...] spec: topologySpreadConstraints: - labelSelector: matchLabels: deployment: file-uploader maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule - labelSelector: matchLabels: deployment: file-uploader maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: ScheduleAnyway nodeSelector: node-role.kubernetes.io/worker: "" containers: [...]输出示例:
deployment.apps/file-uploader edited
将部署缩减为零个容器集,然后重新扩展到四个容器集。这是必要的,因为部署在 pod 的放置方面发生了变化。
- 缩减至零个 pod
$ oc scale deployment file-uploader --replicas=0 -n my-shared-storage
输出示例:
deployment.apps/file-uploader scaled
- 扩展到四个 pod
$ oc scale deployment file-uploader --replicas=4 -n my-shared-storage
输出示例:
deployment.apps/file-uploader scaled
验证这四个容器集分散到 datacenter1 和 datacenter2 区域中的四个节点上。
$ oc get pods -o wide -n my-shared-storage | egrep '^file-uploader'| grep -v build | awk '{print $7}' | sort | uniq -c输出示例:
1 perf1-mz8bt-worker-d2hdm 1 perf1-mz8bt-worker-k68rv 1 perf1-mz8bt-worker-ntkp8 1 perf1-mz8bt-worker-qpwsr
搜索所用的区域标签。
$ oc get nodes -L topology.kubernetes.io/zone | grep datacenter | grep -v master
输出示例:
perf1-mz8bt-worker-d2hdm Ready worker 35d v1.20.0+5fbfd19 datacenter1 perf1-mz8bt-worker-k68rv Ready worker 35d v1.20.0+5fbfd19 datacenter1 perf1-mz8bt-worker-ntkp8 Ready worker 35d v1.20.0+5fbfd19 datacenter2 perf1-mz8bt-worker-qpwsr Ready worker 35d v1.20.0+5fbfd19 datacenter2
使用浏览器中的 file-uploader Web 应用上传新文件。
查找创建的路由。
$ oc get route file-uploader -n my-shared-storage -o jsonpath --template="http://{.spec.host}{'\n'}"输出示例:
http://file-uploader-my-shared-storage.apps.cluster-ocs4-abdf.ocs4-abdf.sandbox744.opentlc.com
使用上一步中的路由将浏览器指向 Web 应用。
Web 应用会列出所有上传的文件,并可以上传新文件并下载现有数据。现在,并没有任何内容。
从本地计算机中选择一个任意文件,并将它上传到应用程序。
- 单击 Choose file 以选择任意文件。
点 Upload。
图 5.1. 基于 PHP 的简单文件上传工具

- 单击 已上传文件列表,以查看所有当前上传的文件的列表。
OpenShift Container Platform 镜像 registry、入口路由和监控服务不被区识别