流程

1. 将任何 OLM Operator 升级到与您要升级到的版本兼容的版本。

2. 验证所有 MachineConfigPools 均显示 UPDATED 状态，没有 MachineConfigPools 显示 UPDATING 状态。要查看所有 MachineConfigPools 的状态，请运行以下命令：

   $ oc get mcp

   输出示例

   为清晰起见，输出已被修剪：

   NAME     CONFIG                                         	UPDATED   UPDATING
   master   rendered-master-ecbb9582781c1091e1c9f19d50cf836c       True  	  False
   worker   rendered-worker-00a3f0c68ae94e747193156b491553d5       True  	  False

3. 暂停您要跳过重启的 MachineConfigPools，运行以下命令：

   注意

   您无法暂停 master 池。

   $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'

4. 切换到 eus-4.10 频道，运行以下命令：

   $ oc adm upgrade channel eus-4.10

5. 更新至 4.9，运行以下命令：

   $ oc adm upgrade --to-latest

   输出示例

   Updating to latest version 4.9.18

6. 运行以下命令，查看集群版本以确保更新已完成：

   $ oc get clusterversion

   输出示例

   NAME  	  VERSION  AVAILABLE  PROGRESSING   SINCE   STATUS
   version   4.9.18   True       False         6m29s   Cluster version is 4.9.18

7. 如有必要，使用 web 控制台中的 Administrator 视角升级 OLM operator。

8. 更新至 4.10，运行以下命令：

   $ oc adm upgrade --to-latest

9. 运行以下命令，查看集群版本以确保更新已完成：

   $ oc get clusterversion

   输出示例

   NAME  	  VERSION  AVAILABLE  PROGRESSING   SINCE   STATUS
   version   4.10.1   True       False         6m29s   Cluster version is 4.10.1

10. 取消暂停所有之前暂停的 MachineConfigPools，运行以下命令：

    $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'

    注意

    如果没有取消暂停池，集群不允许升级到将来的次要维护任务，如证书轮转。这会使集群面临未来降级的风险。

11. 验证之前暂停的池是否已更新，集群完成了更新到 4.10，运行以下命令：

    $ oc get mcp

    输出示例

    为清晰起见，输出已被修剪：

    NAME 	   CONFIG                                            UPDATED     UPDATING
    master   rendered-master-52da4d2760807cb2b96a3402179a9a4c    True  	 False
    worker   rendered-worker-4756f60eccae96fb9dcb4c392c69d497    True 	 False

流程

1. 提取并检查 新版本的 CredentialsRequest 自定义资源。

   详情请参阅您的云供应商的“手动创建 IAM”部分来了解如何获取和使用您的云所需的凭证。

2. 更新集群中手动维护的凭证：

   • 为新发行镜像添加的任何 CredentialsRequest 自定义资源创建新 secret。
   • 如果存储在 secret 中的任何现有凭证的 CredentialsRequest 自定义资源更改了其权限要求，请根据需要更新权限。

3. 当所有 secret 都对新发行版本正确时，表示集群已准备好升级：

   1. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。

   2. 编辑 CloudCredential 资源，以在 metadata 字段中添加 可升级至 注解：

      $ oc edit cloudcredential cluster

      要添加的文本

      ...
        metadata:
          annotations:
            cloudcredential.openshift.io/upgradeable-to: <version_number>
      ...

      其中 <version_number> 是您要升级到的版本，格式为 x.y.z。例如，OpenShift Container Platform 4.8.2 代表 OpenShift Container Platform 4.8.2。

      添加可升级状态进行更改的注解后，可能需要几分钟时间。

4. 验证 CCO 是否可升级：

   1. 在 Web 控制台的 Administrator 视角中，导航到 Administration → Cluster Settings。
   2. 要查看 CCO 状态详情，请点击 Cluster Operators 列表中的 cloud-credential。
   3. 如果 Conditions 部分中的 Upgradeable 状态为 False，请验证 upgradeable-to 注解没有拼写错误。

流程

1. 登陆到 OpenShift Container Platform Web 控制台。
2. 进入到 Compute → MachineHealthChecks。

3. 要暂停机器健康检查，请在每个 MachineHealthCheck 资源中添加 cluster.x-k8s.io/paused="" 注解。例如，要将注解添加到 machine-api-termination-handler 资源，请完成以下步骤：

   1. 点 machine-api-termination-handler 旁边的 Options 菜单 并点 Edit annotations。
   2. 在 Edit annotations 对话框中，点 Add more。
   3. 在 Key 和 Value 字段中，分别添加 cluster.x-k8s.io/paused 和 "" 值，然后点 Save。

流程

1. 在 web 控制台中点击 Administration → Cluster Settings 并查看 Details 选项卡中的内容。

2. 对于生产环境中的集群，请确保将 Channel 设置为您要升级到的版本的正确频道，如 stable-4.9。

   重要

   对于生产环境中的集群，您必须订阅一个 stable-*, eus-* 或 fast-* 频道。

   • 如果 Update 状态 不是 Updates available，则无法升级集群。
   • Select channel 表示集群正在运行或正在更新的集群版本。

3. 选择要更新到的版本，然后单击 Save。

   输入频道 Update Status 变为Update to <product-version> in progress，您可以通过监视 Operator 和节点的进度条来查看集群更新的进度。

   注意

   如果您要将集群升级到下一个次版本，如从 4.y 升级到 4.(y+1)，建议在部署依赖新功能的工作负载前确认您的节点已升级：任何尚未更新的 worker 节点池都会显示在 Cluster Settings 页面。

4. 更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。

   • 如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
   • 如果没有可用的更新，请将 Channel 改为下一个次版本的 stable-*, eus-* 或 fast-* 频道，并更新至您在该频道中想要的版本。

   您可能需要执行一些过渡的更新，直到您到达您想要的版本。

流程

1. 导航到 Administration → Cluster Settings，点 version。

2. 点击 YAML 选项卡，然后编辑 upstream 参数值：

   输出示例

     ...
     spec:
       clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
       upstream: '<update-server-url>' 1
     ...

   1

   <update-server-url> 变量指定更新服务器的 URL。

   默认 upstream 是 https://api.openshift.com/api/upgrades_info/v1/graph。

3. 点 Save。

流程

1. 要列出您要暂停的所有可用 MachineHealthCheck 资源，请运行以下命令：

   $ oc get machinehealthcheck -n openshift-machine-api

2. 要暂停机器健康检查，请将 cluster.x-k8s.io/paused="" 注解添加到 MachineHealthCheck 资源。运行以下命令:

   $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""

   注解的 MachineHealthCheck 资源类似以下 YAML 文件：

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineHealthCheck
   metadata:
     name: example
     namespace: openshift-machine-api
     annotations:
       cluster.x-k8s.io/paused: ""
   spec:
     selector:
       matchLabels:
         role: worker
     unhealthyConditions:
     - type:    "Ready"
       status:  "Unknown"
       timeout: "300s"
     - type:    "Ready"
       status:  "False"
       timeout: "300s"
     maxUnhealthy: "40%"
   status:
     currentHealthy: 5
     expectedMachines: 5

   重要

   更新集群后恢复机器健康检查。要恢复检查，请运行以下命令从 MachineHealthCheck 资源中删除暂停注解：

   $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

流程

1. 确认集群可用：

   $ oc get clusterversion

   输出示例

   NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
   version   4.8.13     True        False         158m    Cluster version is 4.8.13

2. 查看当前的更新频道信息，并确认您的频道已设置为 stable-4.9:

   $ oc get clusterversion -o json|jq ".items[0].spec"

   输出示例

   {
     "channel": "stable-4.9",
     "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff"
   }

   重要

   对于生产环境中的集群，您必须订阅一个 stable-*, eus-* 或 fast-* 频道。

3. 查看可用更新，记录下要应用的更新的版本号：

   $ oc adm upgrade

   输出示例

   Cluster version is 4.8.13
   
   Updates:
   
   VERSION IMAGE
   4.9.0   quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b

4. 应用更新：

   • 要更新到最新版本：

     $ oc adm upgrade --to-latest=true 1

   • 要更新到一个特定版本：

     $ oc adm upgrade --to=<version> 1

     1 1

     <version>是从上一个命令输出中获取的更新版本。

5. 查看 Cluster Version Operator 的状态：

   $ oc get clusterversion -o json|jq ".items[0].spec"

   输出示例

   {
     "channel": "stable-4.9",
     "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
     "desiredUpdate": {
       "force": false,
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
       "version": "4.9.0" 1
     }
   }

   1

   如果desiredUpdate中的version值与您指定的值匹配，则更新正在进行中。

6. 查看集群版本状态历史记录以监控更新的状态。这可能需要一些时间才能完成对所有对象的更新。

   $ oc get clusterversion -o json|jq ".items[0].status.history"

   输出示例

   [
     {
       "completionTime": null,
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:b8fa13e09d869089fc5957c32b02b7d3792a0b6f36693432acc0409615ab23b7",
       "startedTime": "2021-01-28T20:30:50Z",
       "state": "Partial",
       "verified": true,
       "version": "4.9.0"
     },
     {
       "completionTime": "2021-01-28T20:30:50Z",
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:b8fa13e09d869089fc5957c32b02b7d3792a0b6f36693432acc0409615ab23b7",
       "startedTime": "2021-01-28T17:38:10Z",
       "state": "Completed",
       "verified": false,
       "version": "4.8.13"
     }
   ]

   历史记录包含了应用于集群的最新版本的列表。当CVO应用更新时，此值将会被相应更新。该列表按日期排序，最新的更新会在列表中第一个显示。如果历史信息中的更新状态为 Completed，则表示部署已完成；如果状态为 Partial，则表示更新失败或还未完成。

7. 更新完成后，可以通过以下方法确认集群已更新为新版本：

   $ oc get clusterversion

   输出示例

   NAME      VERSION     AVAILABLE   PROGRESSING   SINCE     STATUS
   version   4.9.0       True        False         2m        Cluster version is 4.9.0

   注意

   如果 oc get clusterversion 命令在 PROGRESSING 状态为 True 时显示以下错误，您可以忽略这个错误。

   NAME    VERSION AVAILABLE PROGRESSING SINCE STATUS
   version 4.10.26 True      True        24m   Unable to apply 4.11.0-rc.7: an unknown error has occurred: MultipleErrors

8. 如果您要将集群升级到下一个次版本，如从 4.y 升级到 4.(y+1)，建议在部署依赖新功能的工作负载前确认您的节点已升级：

   $ oc get nodes

   输出示例

   NAME                           STATUS   ROLES    AGE   VERSION
   ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.22.1
   ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.22.1
   ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.22.1
   ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.22.1
   ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.22.1
   ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.22.1

1. 根据 worker 池创建 MCP。每个 MCP 中的节点数量取决于几个因素，如每个 MCP 的维护窗口持续时间以及集群中可用的保留容量（即额外的 worker 节点）。

   注意

   您可以更改 MCP 中的 maxUnavailable 设置，以指定在任意给定时间可以更新的机器的百分比或数量。默认值为 1。

2. 将节点选择器添加到自定义 MCP。对于您不想与剩余的集群同时更新的每个节点，请向节点添加匹配的标签。该标签将节点与 MCP 相关联。

   注意

   不要从节点中删除默认 worker 标签。节点 必须具有 role 标签才能在集群中正常工作。

3. 在更新过程中暂停您不想更新的 MCP。

   注意

   暂停 MCP 还会暂停 kube-apiserver-to-kubelet-signer 自动 CA 证书轮转。在自安装日期起的 292 天生成新 CA 证书，旧证书将从安装日期的 365 天后删除。请参阅红帽 OpenShift 4 中的了解 CA 证书自动续订，以了解您在下一次自动 CA 证书轮转前的时间。确保发生 CA 证书轮转时，池已被取消暂停。如果 MCP 暂停，则不会发生证书轮转，这会导致集群降级，并导致多个 oc 命令失败，包括但不限于 oc debug、oc logs、oc exec 和 oc attach。

4. 执行集群更新。更新过程更新没有暂停的 MCP，包括 control plane 节点。
5. 在更新的节点上测试应用，以确保它们按预期工作。
6. 逐一取消暂停剩余的 MCP，并在这些节点上测试应用程序，直到所有 worker 节点都已更新。取消暂停 MCP 会启动与该 MCP 关联的节点的更新过程。您可以通过点击 Administration → Cluster settings 从 web 控制台检查更新的进度。或者，使用 oc get machineconfigpools CLI 命令。
7. （可选）从更新的节点中删除自定义标签并删除自定义 MCP。

1. 从 worker 节点创建 MCP。

   1. 列出集群中的 worker 节点。

      $ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes

      输出示例

      ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
      ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
      ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm

   2. 对于您要延迟的节点，在节点中添加自定义标签：

      $ oc label node <node name> node-role.kubernetes.io/<custom-label>=

      例如：

      $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary=

      输出示例

      node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled

   3. 创建新的 MCP：

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: workerpool-canary 1
      spec:
        machineConfigSelector:
          matchExpressions: 2
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,workerpool-canary]
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/workerpool-canary: "" 3

      1

      为 MCP 指定名称。

      2

      指定 worker 和自定义 MCP 名称。

      3

      指定添加到此池中的自定义标签。

      $ oc create -f <file_name>

      输出示例

      machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created

   4. 查看集群中的 MCP 列表及其当前状态：

      $ oc get machineconfigpool

      输出示例

      NAME              CONFIG                                                        UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
      master            rendered-master-b0bb90c4921860f2a5d8a2f8137c1867              True      False      False      3              3                   3                     0                      97m
      workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36   True      False      False      1              1                   1                     0                      2m42s
      worker            rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36              True      False      False      2              2                   2                     0                      97m

      创建新的机器配置池 workerpool-canary，机器计数中会显示您添加自定义标签的节点数量。worker MCP 机器数会减少相同的数字。更新机器数可能需要几分钟时间。在本例中，一个节点已从 worker MCP 移到 worker pool-canary MCP。

1. 对您要暂停的 MCP 进行补丁：

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge

   例如：

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge

   输出示例

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

1. 对您要取消暂停的 MCP 进行补丁：

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge

   例如：

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge

   输出示例

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

   您可以使用 oc get machineconfigpools 命令检查更新的进度。

2. 在更新的节点上测试您的应用，以确保它们按预期工作。
3. 逐一取消暂停任何其他暂停的 MCP，并验证您的应用程序是否正常工作。

1. 从节点移除自定义标签。

   $ oc label node <node_name> node-role.kubernetes.io/<custom-label>-

   例如：

   $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-

   输出示例

   node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled

   MCO 将节点移回到原始 MCP，并将节点与 MCP 配置协调。

2. 查看集群中的 MCP 列表及其当前状态：

   $oc get mcp

   NAME                CONFIG                                                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master              rendered-master-1203f157d053fd987c7cbd91e3fbc0ed         True      False      False      3              3                   3                     0                      61m
   workerpool-canary   rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028   True      False      False      0              0                   0                     0                      21m
   worker              rendered-worker-5ad4791166c468f3a35cd16e734c9028         True      False      False      3              3                   3                     0                      61m

   该节点从自定义 MCP 中删除，并移回原始 MCP。更新机器数可能需要几分钟时间。在这个示例中，将一个节点从删除的 workerpool-canary MCP 移到 'worker'MCP。

3. 可选：删除自定义 MCP：

   $ oc delete mcp <mcp_name>

流程

1. 在 web 控制台中点击 Administration → Cluster Settings 并查看 Details 选项卡中的内容。

2. 对于生产环境中的集群，请确保将 Channel 设置为您要升级到的版本的正确频道，如 stable-4.9。

   重要

   对于生产环境中的集群，您必须订阅一个 stable-*, eus-* 或 fast-* 频道。

   • 如果 Update 状态 不是 Updates available，则无法升级集群。
   • Select channel 表示集群正在运行或正在更新的集群版本。

3. 选择要更新到的版本，然后单击 Save。

   输入频道 Update Status 变为Update to <product-version> in progress，您可以通过监视 Operator 和节点的进度条来查看集群更新的进度。

   注意

   如果您要将集群升级到下一个次版本，如从 4.y 升级到 4.(y+1)，建议在部署依赖新功能的工作负载前确认您的节点已升级：任何尚未更新的 worker 节点池都会显示在 Cluster Settings 页面。

4. 更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。

   • 如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
   • 如果没有可用的更新，请将 Channel 改为下一个次版本的 stable-*, eus-* 或 fast-* 频道，并更新至您在该频道中想要的版本。

   您可能需要执行一些过渡的更新，直到您到达您想要的版本。

   注意

   当您更新包含有 Red Hat Enterprise Linux (RHEL) worker 机器的集群时，这些 worker 会在更新过程中暂时不可用。当集群进入 NotReady 状态时，您需要针对每个 RHEL 机器运行升级 playbook 以完成更新。

流程

1. 停止并禁用主机上的防火墙：

   # systemctl disable --now firewalld.service

   注意

   默认情况下，使用 "Minimal" 安装选项的基础操作系统 RHEL 启用 firewalld 保护。在主机上启用了 firewalld 服务会阻止您访问 worker 上的 OpenShift Container Platform 日志。如果您希望继续访问 worker 上的 OpenShift Container Platform 日志，以后不要启用 firewalld。

2. 启用 OpenShift Container Platform 4.9 所需的存储库：

   1. 在运行 Ansible playbook 的机器上，更新所需的存储库：

      # subscription-manager repos --disable=rhel-7-server-ose-4.8-rpms \
                                   --enable=rhel-7-server-ansible-2.9-rpms \
                                   --enable=rhel-7-server-ose-4.9-rpms

   2. 在运行 Ansible playbook 的机器上，更新所需的软件包，包括 openshift-ansible：

      # yum update openshift-ansible openshift-clients

   3. 在每个 RHEL 计算节点上，更新所需的软件仓库：

      # subscription-manager repos --disable=rhel-7-server-ose-4.8-rpms \
                                   --enable=rhel-7-server-ose-4.9-rpms  \
                                   --enable=rhel-7-fast-datapath-rpms   \
                                   --enable=rhel-7-server-optional-rpms

3. 更新 RHEL worker 机器：

   1. 查看当前节点状态，以确定要更新哪个 RHEL worker：

      # oc get node

      输出示例

      NAME                        STATUS                        ROLES    AGE    VERSION
      mycluster-control-plane-0   Ready                         master   145m   v1.22.1
      mycluster-control-plane-1   Ready                         master   145m   v1.22.1
      mycluster-control-plane-2   Ready                         master   145m   v1.22.1
      mycluster-rhel7-0           NotReady,SchedulingDisabled   worker   98m    v1.22.1
      mycluster-rhel7-1           Ready                         worker   98m    v1.22.1
      mycluster-rhel7-2           Ready                         worker   98m    v1.22.1
      mycluster-rhel7-3           Ready                         worker   98m    v1.22.1

      记录下哪个机器具有 NotReady，SchedulingDisabled 状态。

   2. 查看位于 /<path>/inventory/hosts 中的 Ansible 清单文件，并更新其内容，以便只有具有 NotReady,SchedulingDisabled 状态的机器才列在 [workers] 部分中，如下例所示：

      [all:vars]
      ansible_user=root
      #ansible_become=True
      
      openshift_kubeconfig_path="~/.kube/config"
      
      [workers]
      mycluster-rhel7-0.example.com

   3. 进入 openshift-ansible 目录：

      $ cd /usr/share/ansible/openshift-ansible

   4. 运行 upgrade playbook:

      $ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1

      1

      对于<path> ，指定您创建的Ansible库存文件的路径。

      注意

      upgrade playbook 仅升级 OpenShift Container Platform 软件包。它不会更新操作系统软件包。

4. 按照上一步中的流程更新集群中的每个 RHEL worker 机器。

5. 更新完所有 worker 后，确认所有集群节点已更新至新版本：

   # oc get node

   输出示例

   NAME                        STATUS                        ROLES    AGE    VERSION
   mycluster-control-plane-0   Ready                         master   145m   v1.22.1
   mycluster-control-plane-1   Ready                         master   145m   v1.22.1
   mycluster-control-plane-2   Ready                         master   145m   v1.22.1
   mycluster-rhel7-0           NotReady,SchedulingDisabled   worker   98m    v1.22.1
   mycluster-rhel7-1           Ready                         worker   98m    v1.22.1
   mycluster-rhel7-2           Ready                         worker   98m    v1.22.1
   mycluster-rhel7-3           Ready                         worker   98m    v1.22.1

6. 可选：更新 upgrade playbook 没有更新的操作系统软件包。要更新不在 4.9 中的软件包，请使用以下命令：

   # yum update

   注意

   如果您使用安装 4.9 时使用的相同 RPM 存储库，则不需要排除 RPM 软件包。