为 Metro-DR 扩展集群配置 OpenShift Container Storage

Red Hat OpenShift Container Storage 4.8

集群和存储管理员的灾难恢复任务

摘要

本指南旨在详细介绍部署 OpenShift Container Storage 所需的步骤和命令以及 Kubernetes 区域拓扑标签,以实现高度可用的存储基础架构。
重要
This is a technology preview feature and is available only for deployment using local storage devices. 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.

使开源包含更多

红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。如需了解更多详细信息,请参阅 CTO Chris Wright 信息

对红帽文档提供反馈

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

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

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

    1. 进入 Bugzilla 网站。
    2. 在 Component 中选择 Documentation
    3. Description 中输入您要提供的信息。包括文档相关部分的链接。
    4. Submit Bug

第 1 章 使用 stretch 集群进行灾难恢复简介

Red Hat OpenShift Container Storage 部署可以在两个不同的地理位置扩展,以便为存储基础架构提供灾难恢复功能。当处于灾难时(如存在的两个位置中的一个部分不可用或完全不可用),部署在 OpenShift Container Platform 部署中的 OpenShift Container Storage 需要能够存活。此解决方案仅适用于在基础架构服务器之间具有特定延迟要求的 edorpolitan 跨数据中心。

注意

目前,使用扩展集群的 Metro-DR 解决方案可以部署在不同位置的 OpenShift Container Platform 节点之间,且节点间的往返时间(RTT)不能超过 4 毫秒。如果您计划以更高的延迟进行部署,请联系红帽客户支持。

下图显示了 Metro-DR 集群的最简单部署:

OpenShift 节点和 OpenShift Container Storage 守护进程

OpenShift nodes and OpenShift Container Storage daemons

在此图中,Arbiter 区域中部署的 OpenShift Container Storage 监控 pod 具有 master 节点内置的容错能力。高度可用的 OpenShift Container Platform control plane 需要 master 节点。另外,一个区的 OpenShift Container Platform 节点与其他两个区域中的 OpenShift Container Platform 节点具有网络连接非常重要。

第 2 章 准备部署启用了灾难恢复功能的存储集群

2.1. 启用 Metro-DR 的要求

  • 确保您在三个不同的区中至少有三个 OpenShift Container Platform master 节点。三个区域中的每一区域中有一个主节点。
  • 确保至少四个 OpenShift Container Platform worker 节点分布在两个数据区中。
  • 要在裸机上扩展集群,您必须使用 SSD 驱动器作为 OpenShift Container Platform master 节点的 root 驱动器。
  • 确保每个节点已预先标记其 zone 标签。如需更多信息,请参阅 将拓扑区标签应用到 OpenShift Container Platform 节点 部分。
  • Metro-DR 解决方案设计为在区域之间的延迟不超过 2 毫秒时部署(最大的 RTT 为 4毫秒)。如果您计划以更高的延迟进行部署,请联系红帽客户支持
注意

因为有冲突的扩展逻辑,您无法同时启用灵活的扩展和仲裁程序。通过灵活的扩展,您可以一次向 OpenShift Container Storage 集群添加一个节点。但是,在仲裁集群中,您需要在每个 2 个数据区中添加一个节点。

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 CLI 将标签应用到节点,请执行以下操作:

    $ oc label node <NODENAME> topology.kubernetes.io/zone=<LABEL>
  • 要验证标签,请使用 3 区域的示例标签运行以下命令:

    $ oc get nodes -l topology.kubernetes.io/zone=<LABEL> -o name

    或者,您可以运行单个命令来查看带有其区域的所有节点。

    $ oc get nodes -L topology.kubernetes.io/zone

现在,Metro DR 扩展集群拓扑区标签应用于适当的 OpenShift Container Platform 节点,以定义三个位置。

后续步骤

  • 从 OpenShift Container Platform OperatorHub 安装存储操作器。

2.3. 安装 Local Storage Operator

您可以使用 Red Hat OpenShift Container Platform Operator Hub 安装 Local Storage Operator。

前提条件

  • 使用具有 cluster-admin 和 Operator 安装权限的账户访问 OpenShift Container Platform 集群。

流程

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

    1. 频道为 stable-4.8
    2. 安装模式是 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-local-storage
    4. 批准策略为 Automatic
  6. 点击 Install

验证步骤

  • 验证 Local Storage Operator 是否显示 StatusSucceeded

2.4. 安装 Red Hat OpenShift Container Storage Operator

您可以使用 Red Hat OpenShift Container Platform Operator Hub 安装 Red Hat OpenShift Container Storage Operator。

先决条件

  • 使用具有 cluster-admin 和 Operator 安装权限的账户访问 OpenShift Container Platform 集群。
  • 您至少有四(4)个 worker 节点,分布在 Red Hat OpenShift Container Platform 集群中的两个(2)数据中心。
  • 如需额外的资源要求,请参阅规划部署
注意
  • 当您需要覆盖 OpenShift Container Storage 的集群范围默认节点选择器时,您可以在命令行界面中使用以下命令为 openshift-storage 命名空间指定空白节点选择器(在这种情况下创建 openshift-storage 命名空间):

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  • 将节点作为 infra 污点,以确保只在该节点上调度 Red Hat OpenShift Container Storage 资源。这有助于您节省订阅成本。如需更多信息,请参阅管理和分配存储资源指南中的如何将专用 worker 节点用于 Red Hat OpenShift Container Storage 一章。

流程

  1. 在 Web 控制台中,点 Operators → OperatorHub
  2. 在 Filter by keyword 框中滚动或输入关键字以搜索 OpenShift Container Storage Operator。
  3. 在 OpenShift Container Storage operator 页中点 Install
  4. Install Operator 页面中,默认选择以下所需选项:

    1. 将 Channel 更新为 stable-4.8
    2. 安装模式是 A specific namespace on the cluster
    3. Installed Namespace 为 Operator recommended namespace openshift-storage。如果 Namespace openshift-storage 不存在,它会在 Operator 安装过程中创建。
    4. Approval Strategy 选为 AutomaticManual
    5. 点击 Install

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

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

验证步骤

验证 OpenShift Container Storage Operator 是否显示绿色勾号,指示安装成功。

后续步骤

第 3 章 创建 OpenShift Container Storage 集群

在安装 OpenShift Container Storage operator 后,使用此流程创建 OpenShift Container Storage 集群。

先决条件

流程

  1. 登录 OpenShift Web 控制台。
  2. Operators → Installed Operators 查看所有已安装的 Operator。

    确保所选 项目openshift-storage

  3. 点 Storage Cluster 的 OpenShift Container StorageCreate Instance 链接。
  4. 模式为 Internal-Attached devices

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

    您可以通过过滤一组存储卷来创建专用的存储类来消耗存储。

  5. 发现磁盘

    1. 选择 Select nodes 选项,从数据中心区域中选择附加存储设备的带标记的节点。

      如果要选择的节点有污点且没有在向导中发现,请按照红帽知识库解决方案 中提供的步骤作为为 Local Storage Operator 资源添加容忍度的临时解决方案。

      如果选择的节点与一个聚合的 30 个 CPU 和 72 GiB RAM 的要求不匹配,则会部署一个最小的集群。如需最低起始节点要求,请参阅规划指南中的资源要求部分。

    2. Next
  6. 创建存储类

    1. 输入 本地卷集名称
    2. 输入 Storage Class Name。默认情况下,存储类名称会出现卷集名称。您还可以更改名称。
    3. 在上一步中为磁盘发现选择的节点显示在 Filter Disks By 部分。

      选择以下任意一项:

      • Disks on all nodes 以选择所有节点来发现设备。
      • Disks on selected nodes 以选择所有节点中的一部分节点来发现设备。将 worker 节点分布到三个不同的物理节点、机架或故障域以实现高可用性。
    4. 选择 SSD 或 NVMe 来构建受支持的配置。可以为不支持的测试安装选择 HDD
    5. 展开 Advanced 部分并设置以下选项:

      卷模式

      默认会选择块。

      设备类型

      选择磁盘类型。默认情况下,选择 Disk 和 Part。

      磁盘大小

      需要包含的设备的最小和最大可用大小。

      注意

      您必须为该设备设置最小 100GB。

      最大磁盘限制

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

    6. Next。此时会显示一个用于确认创建新存储类的弹出窗口。
    7. 单击 Yes 以继续。
  7. 设置 容量和节点

    1. 如果要使用扩展集群,选择 Enable arbiter 复选框。

      • 从可用的下拉列表中,选择 arbiter 区域
    2. 选择 Storage Class。默认情况下,会选择上一步中创建的新存储类。
    3. 所选节点 显示上一步中选择的节点。此列表需要几分钟时间来显示上一步中发现的磁盘。

      注意

      检查所选节点部分中显示的各个节点的 zone 标签,以验证它们是否已正确标记。

    4. Next
  8. (可选) 设置安全性和网络配置

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

      • Cluster-wide encryption 来加密整个集群(块存储和文件存储)。
      • Storage class encryption 以使用加密启用的存储类创建加密的持久性卷(仅限块)。
    3. 选择 Connect to an external key management service 复选框。这是集群范围加密的可选选项。

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

        1. 后端路径中输入为 OpenShift Container Storage 专用且唯一的 Key Value secret 路径。
        2. (可选)输入 TLS 服务器名称Vault Enterprise 命名空间
        3. 通过上传相应的 PEM 编码证书文件提供 CA 证书客户端证书客户端私钥
        4. Save
    4. 如果使用一个单一网络,选择 Default (SDN);如果使用多个网络借口,选择 Custom (Multus) Network。

      1. 从下拉菜单中选择公共网络接口
      2. 从下拉菜单中选择 Cluster Network Interface
    5. Next
  9. 检查配置详情。若要修改任何配置设置,请单击 Back 以返回到上一配置页面。
  10. 点击 Create

验证步骤

  1. 验证已安装存储集群的最后一个 Status 显示为 Phase: Ready,并带有绿色勾号标记。

    1. OperatorsInstalled OperatorsStorage Cluster 链接来查看存储集群安装状态。
    2. 另外,当使用 Operator Details 选项卡时,您可以点击 Storage Cluster 选项卡查看状态。
  2. Storage Cluster 标签页中点 ocs-storagecluster

    1. 在 YAML 选项卡中,在 spec 部分搜索 arbiter 键并检查以下内容:

      • 'enable' 设置为 true
      • "arbiterLocation"设定了 仲裁程序
      • 'replica' 设置为 4
      • 'failureDomain' 设置为 zone

        spec:
            arbiter:
              enable: true
            [..]
            nodeTopologies:
              arbiterLocation: arbiter
                [..]
              replica: 4
        status:
            conditions:
            [..]
            failureDomain: zone
            [..]
  3. 要验证 OpenShift Container Storage 的所有组件是否已成功安装,请参阅验证 OpenShift Container Storage 安装

第 4 章 验证 OpenShift Container Storage 部署

使用本节验证 OpenShift Container Storage 是否已正确部署。

4.1. 验证 pod 的状态

要验证 OpenShift Container Storage 的 pod 是否正在运行,请按照以下步骤操作:

流程

  1. 登录 OpenShift Web 控制台。
  2. 从 OpenShift Web 控制台左侧窗格中,点击 Workloads → Pods
  3. Project 下拉列表中,选择 openshift-storage

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

  4. 单击 RunningCompleted 选项卡,以验证 pod 正在运行并处于已完成状态。

    表 4.1. 对应 OpenShift Container 存储集群的 Pod

    组件对应的 pod

    OpenShift Container Storage Operator

    • OCS-operator-*(在任何 worker 节点上有 1 个 pod)
    • ocs-metrics-exporter-*

    Rook-ceph Operator

    rook-ceph-operator-*

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

    多云对象网关

    • noobaa-operator-* (任何 worker 节点上 1 个 pod)
    • noobaa-core-* (任何存储节点上 1 个 pod)
    • NooBaa-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 Container Storage 集群是否正常运行

要验证 OpenShift Container Storage 的集群是否正常运行,请按照以下步骤执行。

流程

  1. Storage → Overview,点 Block and File 选项卡。
  2. Status 卡 中,验证 Storage ClusterData Resiliency 具有绿色勾号标记。
  3. Details 卡 中,验证是否显示集群信息。

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

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

要验证 OpenShift Container Storage Multicloud 对象网关是否健康,请按照以下步骤执行。

流程

  1. 在 OpenShift Web 控制台中点 Storage → Overview,然后点击 Object 选项卡。
  2. Status 卡 中,验证 Object ServiceData Resiliency 都处于 Ready 状态(绿色钩号)。
  3. Details 卡 中,验证是否显示了 Multicloud 对象网关信息。

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

4.4. 验证 OpenShift Container Storage 特定的存储类是否存在

要验证集群中的存储类是否存在,请按照以下步骤执行。

流程

  1. 从 OpenShift Web 控制台点 Storage → Storage Classes
  2. 验证是否在创建 OpenShift Container Storage 集群时创建了以下存储类:

    • ocs-storagecluster-ceph-rbd
    • ocs-storagecluster-cephfs
    • openshift-storage.noobaa.io
    • ocs-storagecluster-ceph-rgw

第 5 章 安装区识别示例应用程序

使用本节来部署区识别示例应用程序,以验证 OpenShift Container Storage Metro Disaster 恢复设置是否正确配置。

重要

随着数据区域之间的延迟,可以预期与节点和区域之间具有低延迟的 OpenShift 集群(例如,同一位置的所有节点)相比,可以看到性能下降。性能会下降多少,取决于区域之间的延迟和使用存储(如高写流量)的应用行为。请确保使用 Metro DR 集群配置测试关键应用程序,以确保应用程序性能达到所需的服务水平。

5.1. 安装区示例应用程序

在本节中,ocs-storagecluster-cephfs 存储类用于创建一个可由多个 pod 同时使用的 Read-Write-Many(RWX)PVC。我们将使用的应用程序称为文件上传程序。

由于此应用共享用于存储文件的 RWX 卷,我们可以演示如何在拓扑区域之间分散应用,以便在站点中断时仍可用。这也适用于持久数据访问,因为 OpenShift Container Storage 被配置为具有区感知和高可用性的 Metro DR 扩展集群。

  1. 创建一个新项目

    oc new-project my-shared-storage
  2. 部署名为 file-uploader 的 PHP 应用程序示例:

    oc new-app openshift/php:7.2-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 路由资源。我们需要手动创建路线。

通过将应用程序区扩展到 4 个副本并公开其服务,让应用程序区了解并可用:

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

几分钟后,您应该有 4 个文件加载器 Pod。重复上述命令,直到 Running STATUS 中有 4 个 file-uploader Pod。

您可以创建一个 PersistentVolumeClaim,并使用 oc set volume 命令将其附加到应用程序中。执行以下命令

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

此命令将:

  • 创建 PersistentVolumeClaim
  • 更新应用部署,使其包含卷定义
  • 更新应用部署,将卷挂载附加到指定的 mount-path
  • 导致 4 个应用程序 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

注意 ACCESSMODE 设置为 RWX(ReadWriteMany)。

所有 4 个文件-uploaderPods 都使用相同的 RWX 卷。如果没有此 ACCESSMODE,OpenShift 将不会尝试可靠地将多个 Pod 附加到同一持久性卷。如果您试图扩展正在使用 RWO( ReadWriteOnce)持久性卷的部署,则 Pod 将在同一节点上被在一起。

5.2. 将 Deployment 修改为区域 Aware

目前,file-uploader Deployment 不知道区,并可调度同一区域中的所有 Pod。在这种情况下,如果站点中断,则应用将不可用。如需更多信息,请参阅使用 pod 拓扑分布约束

  1. 为了让我们的应用程序区了解,我们需要在应用部署配置中添加 pod 放置规则。运行以下命令并查看下方所示的输出:在下一步中,我们将修改 Deployment 以使用拓扑区域标签,如以下输出中的 Start 和 End 部分所示。

    $ 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
    [...]
          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
  3. 将部署扩展为 个 Pod,然后重新扩展到 四个 Pod。这是必要的,因为部署在 Pod 的放置方面发生了变化。

    oc scale deployment file-uploader --replicas=0 -n my-shared-storage

    输出示例:

    deployment.apps/file-uploader scaled

    然后返回到 4 个 Pod。

    $ oc scale deployment file-uploader --replicas=4 -n my-shared-storage

    输出示例:

    deployment.apps/file-uploader scaled
  4. 验证这四个 Pod 分布到 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
  5. 使用浏览器中的 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. 从本地计算机中选择一个任意文件并将其上传到应用程序。

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

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

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