为 Metro-DR 扩展集群配置 OpenShift Data Foundation

Red Hat OpenShift Data Foundation 4.9

有关如何在两个不同地理位置配置 OpenShift Data Foundation 的说明,以提供具有灾难恢复功能的存储基础架构。

摘要

本指南旨在详细介绍部署 OpenShift Data Foundation 所需的步骤和命令以及 Kubernetes 区域拓扑标签,以实现高度可用的存储基础架构。
重要
Configuring OpenShift Data Foundation for Metro-DR is a technology preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈:

  • 关于特定内容的简单评论:

    1. 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
    2. 用鼠标指针高亮显示您想评论的文本部分。
    3. 点在高亮文本上弹出的 Add Feedback
    4. 按照显示的步骤操作。
  • 要提交更复杂的反馈,请创建一个 Bugzilla ticket:

    1. 进入 Bugzilla 网站。
    2. Component 部分中,选择 文档
    3. Description 中输入您要提供的信息。包括文档相关部分的链接。
    4. 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 守护进程

OpenShift nodes and OpenShift Data Foundation daemons

在上图中,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。

流程

  1. 登录 OpenShift Web 控制台。
  2. Operators → OperatorHub
  3. Filter by keyworr 框中键入 local storage,从操作器列表中搜索 Local Storage operator 并单击它。
  4. Install Operator 页面中设置以下选项:

    1. 更新频道(如 4.9stable
    2. 安装模式是 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-local-storage
    4. 将批准更新为 Automatic
  5. 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 章节。

流程

  1. 登录 OpenShift Web 控制台。
  2. Operators → OperatorHub
  3. Filter by keyword 框中滚动或键入 OpenShift Data Foundation,以查找 OpenShift Data Foundation Operator。
  4. Install
  5. Install Operator 页面中设置以下选项:

    1. 更新频道是 stable-4.9
    2. 安装模式是 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-storage。如果命名空间 openshift-storage 不存在,它会在 Operator 安装过程中创建。
    4. Approval Strategy 选为 AutomaticManual

      如果选择 Automatic 更新,Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例,而无需任何干预。

      如果选择了 手动 更新,则 OLM 会创建一个更新请求。作为集群管理员,您必须手动批准该更新请求,才能将 Operator 更新至更新的版本。

  6. 确保为 Console 插件 选择了 Enable 选项。
  7. Install

验证步骤

验证 OpenShift Data Foundation Operator 是否显示绿色勾号(代表安装成功)。

第 3 章 创建 OpenShift Data Foundation 集群

先决条件

流程

  1. 在 OpenShift Web 控制台中,点 Operators → Installed Operators 查看所有已安装的 Operator。

    确保所选 项目openshift-storage

  2. 单击 OpenShift Data Foundation 操作器,然后单击 Create StorageSystem
  3. 在 Backing storage 页面中,选择 Create a new StorageClass using the local storage devices 选项。
  4. Next

    重要

    如果还没有安装,系统会提示您安装 Local Storage Operator。点 Install 并按照 Installing Local Storage Operator 中所述的步骤进行操作。

  5. Create local volume set 页面中,提供以下信息:

    1. LocalVolumeSetStorageClass 输入一个名称。

      默认情况下,存储类名称会出现本地卷集名称。您可以更改名称。

    2. 选择以下任意一项:

      • 所有节点上的磁盘

        使用与所有节点上所选过滤器匹配的可用磁盘。

      • 所选节点上的磁盘

        仅在所选节点上使用与所选过滤器匹配的可用磁盘。

        重要

        如果选择的节点与 OpenShift Data Foundation 的一个聚合的 30 个 CPU 和 72 GiB RAM 的要求不匹配,则会部署一个最小的集群。

        如需最低起始节点要求,请参阅 规划指南中的资源要求部分。

    3. 选择 SSDNVMe 来构建受支持的配置。您可以为不支持的测试安装选择 HDD
    4. 展开 Advanced 部分并设置以下选项:

      卷模式

      默认会选择块。

      设备类型

      从下拉列表中选择一个或多个设备类型。

      磁盘大小

      为设备设置最小 100GB 大小,以及需要包含的设备的最大可用大小。

      磁盘限制上限

      这表示节点上可以创建的 PV 数量上限。如果此字段留空,则为匹配节点上的所有可用磁盘创建 PV。

    5. Next

      此时会显示一个用于确认创建 LocalVolumeSet 的弹出窗口。

    6. 单击 Yes 以继续。
  6. Capacity 和 nodes 页面中,配置以下内容:

    1. 如果要使用扩展集群,选择 Enable arbiter 复选框。这个选项只有在满足仲裁程序的所有先决条件并且填充了所选节点时才可用。如需更多信息,请参阅准备在启用了灾难恢复的情况下部署存储集群 [Technology Preview] 中的 Arbiter 扩展集群要求。

      从下拉列表中选择 arbiter 区域

    2. 可用的原始容量会根据与存储类关联的所有附加磁盘填充容量值。这将需要一些时间才能出现。

      Selected nodes 列表根据存储类显示节点。

    3. Next
  7. 可选:在 Security and network 页面中,根据您的要求进行配置:

    1. 选中 启用加密 复选框,以加密块和文件存储。
    2. 选择以下一个或两个加密级别

      • 集群范围的加密

        加密整个集群(块和文件)。

      • StorageClass 加密

        使用启用加密的存储类创建加密的持久性卷(仅块)。

    3. 选中连接到外部密钥管理服务复选框。这是集群范围加密的可选选项。

      1. 默认情况下,Key Management Service Provider 设置为 Vault
      2. 输入 Vault Service Name、Vault 服务器的主机地址 ('https://<hostname 或 ip>')、端口号和 Token
    4. 展开 Advanced Settings,以根据您的 Vault 配置输入额外的设置和证书详情:

      1. 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
      2. 可选:输入 TLS Server NameVault Enterprise 命名空间
      3. 上传对应的 PEM 编码证书文件,以提供 CA 证书客户端证书客户端私钥
    5. 点击 Save
    6. 选择以下任意一项:

      • 默认(SDN)

        如果您使用的是单个网络。

      • 自定义(Multus)

        如果您使用多个网络接口:

        1. 从下拉菜单中选择公共网络接口
        2. 从下拉菜单中选择集群网络接口

          注意

          如果您只使用一个额外网络接口,请选择单个 NetworkAttachementDefinition,即ocs-public-cluster 用于公共网络接口,并将 Cluster Network Interface 留空。

    7. Next
  8. Review and create 页面中,检查配置详情。

    若要修改任何配置设置,请单击 Back 以返回到上一配置页面。

  9. 单击 Create StorageSystem
  10. 对于使用密钥管理系统(KMS)的集群范围加密,如果您使用了 Vault Key/Value(KV)机密引擎 API 版本 2,则您需要编辑 configmap

    1. 在 OpenShift Web 控制台中,导航到 Workloads → ConfigMaps
    2. 要查看 KMS 连接详情,点 ocs-kms-connection-details
    3. 编辑 configmap。

      1. Action menu (⋮) → Edit ConfigMap
      2. VAULT_BACKEND 参数设置为 v2

        kind: ConfigMap
        apiVersion: v1
        metadata:
          name: ocs-kms-connection-details
        [...]
        data:
          KMS_PROVIDER: vault
          KMS_SERVICE_NAME: vault
        [...]
          VAULT_BACKEND: v2
        [...]
      3. 点击 Save

验证步骤

  • 验证已安装存储集群的最终状态:

    1. 在 OpenShift Web 控制台中,导航到 Installed OperatorsOpenShift Data FoundationStorage Systemocs-storagecluster-storagesystemResources
    2. 验证 StorageClusterStatus 是否为 Ready,并且旁边有一个绿色勾号标记。
  • 对于部署的仲裁模式:

    1. 在 OpenShift Web 控制台中,导航到 Installed OperatorsOpenShift Data FoundationStorage Systemocs-storagecluster-storagesystemResourcesocs-storagecluster
    2. 在 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 的状态

流程

  1. 从 OpenShift Web 控制台点 Workloads → Pods
  2. Project 下拉列表中选择 openshift-storage

    注意

    如果禁用 Show default projects 选项,请使用切换按钮列出所有默认项目。

    有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息,请参阅 表 4.1 “对应 OpenShift Data Foundation 集群的 Pod”

  3. RunningCompleted 标签页验证以下 pod 是否处于 RunningCompleted 状态:

表 4.1. 对应 OpenShift Data Foundation 集群的 Pod

组件对应的 pod

OpenShift Data Foundation Operator

  • OCS-operator-*(在任何 worker 节点上有 1 个 pod)
  • ocS-metrics-exporter-*(任何 worker 节点上 1 个 pod)
  • odF-operator-controller-manager-*(任何 worker 节点上 1 个 pod)
  • odf-console-* (任何 worker 节点上 1 个 pod)

Rook-ceph Operator

rook-ceph-operator-*

(任何 worker 节点上有 1 个 pod)

多云对象网关

  • noobaa-operator-* (任何 worker 节点上 1 个 pod)
  • noobaa-core-* (任何存储节点上 1 个 pod)
  • nooba-db-*(任何存储节点上 1 个 pod)
  • noobaa-endpoint-* (任何存储节点上 1 个 pod)

MON

rook-ceph-mon-*

(5 个 pod 分布到 3 个区域,每个数据中心区域 2 个,1 个在仲裁区域内)

MGR

rook-ceph-mgr-*

(任何存储节点 2 个 pod)

MDS

rook-ceph-mds-ocs-storagecluster-cephfilesystem-*

(2 个 pod 分布到 2 个数据中心区域)

RGW

rook-ceph-rgw-ocs-storagecluster-cephobjectstore-*

(2 个 pod 分布到 2 个数据中心区域)

CSI

  • cephfs

    • csi-cephfsplugin-* (每个 worker 节点上 1 个 pod)
    • csi-cephfsplugin-provisioner-* (2 个 pod 在不同的 worker 节点上分布)
  • rbd

    • csi-rbdplugin-* (每个 worker 节点上 1 个 pod)
    • csi-rbdplugin-provisioner-* (2 个 pod 在不同的 worker 节点上分步)

rook-ceph-crashcollector

rook-ceph-crashcollector-*

(每个存储节点 1 个 pod,1 个 pod 在仲裁区域上)

OSD

  • rook-ceph-osd-* (每个设备 1 个 pod)
  • rook-ceph-osd-prepare-ocs-deviceset-* (每个设备 1 个 pod)

4.2. 验证 OpenShift Data Foundation 集群是否健康

流程

  1. 在 OpenShift Web 控制台中,点 StorageOpenShift Data Foundation
  2. Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
  3. Block and File 选项卡的 Status 卡中,验证 Storage Cluster 是否具有绿色勾号。
  4. Details 卡中,验证是否显示集群信息。

如需有关使用 Block and File 仪表板的 OpenShift Data Foundation 集群健康的更多信息,请参阅 监控 OpenShift Data Foundation

4.3. 验证 Multicloud 对象网关是否健康

流程

  1. 在 OpenShift Web 控制台中,点 StorageOpenShift Data Foundation
  2. Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。

    1. Object 选项卡的 Status 卡 中,验证 Object Service数据弹性 都具有绿色勾号。
    2. Details 卡中,验证是否显示了 MCG 信息。

如需有关使用对象服务仪表板的 OpenShift Data Foundation 集群健康的更多信息,请参阅监控 OpenShift Data Foundation

4.4. 验证 OpenShift Data Foundation 特定的存储类是否存在

流程

  1. 从 OpenShift Web 控制台左侧窗格中,点击 Storage → Storage Classes
  2. 验证是否在创建 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 扩展集群。

  1. 创建新项目。

    $ oc new-project my-shared-storage
  2. 部署名为 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.
  3. 查看构建日志并等待应用部署好。

    $ 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 路由资源。您需要手动创建路线。

扩展应用程序

  1. 将应用缩放为四个副本,并公开其服务,使应用区域了解和可用。

    $ 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 状态。

  2. 创建 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 创建一个新部署。
  3. 检查添加卷的结果。

    $ 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-uploader pod 都使用相同的 RWX 卷。如果没有这种访问模式,OpenShift 不会尝试可靠地将多个容器集附加到同一持久卷(PV)。如果您试图扩展正在使用 ReadWriteOnce(RWO) PV 的部署,则 pod 可能会在同一节点上在一起。

5.2. 将 Deployment 修改为区域 Aware

目前,file-uploader Deployment 不是区域感知型,它可以调度同一区域中的所有 pod。在这种情况下,如果站点中断,则应用不可用。如需更多信息,请参阅使用 pod 拓扑分布限制控制 pod 放置

  1. 在应用部署配置中添加容器集放置规则,使应用区域感知。

    1. 运行以下命令并查看输出:

      $ 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
      [...]
    2. 编辑部署以使用拓扑区标签。

      $ oc edit deployment file-uploader -n my-shared-storage

      StartEnd (上一步中的输出中显示)之间添加以下新行:

      [...]
          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
  2. 将部署缩减为个容器集,然后重新扩展到四个容器集。这是必要的,因为部署在 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
  3. 验证这四个容器集分散到 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
  4. 使用浏览器中的 file-uploader Web 应用上传新文件。

    1. 查找创建的路由。

      $ 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
    2. 使用上一步中的路由将浏览器指向 Web 应用。

      Web 应用会列出所有上传的文件,并可以上传新文件并下载现有数据。现在,并没有任何内容。

    3. 从本地计算机中选择一个任意文件,并将它上传到应用程序。

      1. 单击 Choose file 以选择任意文件。
      2. Upload

        图 5.1. 基于 PHP 的简单文件上传工具

        Uploader 屏幕上传
    4. 单击 已上传文件列表,以查看所有当前上传的文件的列表。
注意

OpenShift Container Platform 镜像 registry、入口路由和监控服务不被区识别