更新集群

OpenShift Container Platform 4.7

更新 OpenShift Container Platform 集群

摘要

本文档提供了有关更新和升级 OpenShift Container Platform 集群的信息。更新集群的过程较简单,可以在不需要使集群离线的情况下进行。

第 1 章 了解 OpenShift Update Service

对于可访问互联网的集群,红帽通过 OpenShift Container Platform 更新服务提供更新,它作为公共 API 后面的一个托管服务运行。

注意

如果您使用一个受限的网络,集群无法访问公共 API,您可以在本地安装 OpenShift Update Service。请参阅安装和配置 OpenShift Update Service

1.1. 关于 OpenShift Update 服务

OpenShift 更新服务(OpenShift Update Service,简称 OSUS)为 OpenShift Container Platform(包括 Red Hat Enterprise Linux CoreOS(RHCOS))提供了无线更新(over-the air update)功能。它提供了一个图表,其中包含组件 Operator 的顶点(vertices)和连接它们的 边(edges)。图中的边代表了您可以安全更新到的版本。顶点是更新的有效负载,用于指定受管集群组件的预期状态。

集群中的 Cluster Version Operator (CVO) 会检查 OpenShift Container Platform 更新服务,并根据当前组件版本和图中的信息决定有效的更新和更新路径。当您请求更新时,CVO 使用该更新的发行镜像来升级您的集群。发行工件 (artifact) 作为容器镜像托管在 Quay 中。

为了让 OpenShift Update Service 仅提供兼容的更新,可以使用一个版本验证管道来驱动自动化过程。每个发行工件都会被验证是否与支持的云平台和系统架构以及其他组件包兼容。在管道确认有适用的版本后,OpenShift Update Service 会通知您它可用。

重要

OpenShift Update Service 显示当前集群的所有推荐更新。如果 OpenShift Update Service 不建议升级路径,这可能是因为更新或目标发行版本存在已知问题。

两个控制器在持续更新模式下运行。第一个控制器持续更新有效负载清单,将清单应用到集群,并输出 Operator 的受控推出的状态,以指示它们是否处于可用、升级或失败状态。第二个控制器轮询 OpenShift Update Service,以确定更新是否可用。

重要

仅支持升级到较新版本。不支持将集群还原或回滚到以前的版本。如果您的更新失败,请联系红帽支持。

在更新过程中,Machine Config Operator(MCO)将新配置应用到集群机器。MCO 会处理由 maxUnavailable 字段指定的、协调机器配置池中的节点数量,并将它们标记为不可用。在默认情况下,这个值被设置为 1。然后,MCO 会应用新配置并重启机器。

如果您将 Red Hat Enterprise Linux (RHEL) 机器用作 worker,MCO 不会在这些机器上更新 kubelet,因为您必须首先在这些机器上更新 OpenShift API。

当新版本规格应用到旧的 kubelet 时,RHEL 机器无法返回 Ready 状态。在机器可用前,您无法完成更新。但是,因为已设置了最大不可用节点数,所以可以在一定机器无法使用的情况下,确保正常的集群操作。

OpenShift Update Service 由 Operator 和一个或多个应用程序实例组成。

1.2. 非受管 Operator 的支持策略

Operator 的 管理状态 决定了一个 Operator 是否按设计积极管理集群中其相关组件的资源。如果 Operator 设置为 非受管(unmanaged) 状态,它不会响应配置更改,也不会收到更新。

虽然它可以在非生产环境集群或调试过程中使用,但处于非受管状态的 Operator 不被正式支持,集群管理员需要完全掌控各个组件的配置和升级。

可使用以下方法将 Operator 设置为非受管状态:

  • 独立 Operator 配置

    独立 Operator 的配置中具有 managementState 参数。这可以通过不同的方法来访问,具体取决于 Operator。例如,Red Hat OpenShift Logging Operator 通过修改它管理的自定义资源(CR)来达到此目的,而 Cluster Samples Operator 使用了集群范围配置资源。

    managementState 参数更改为 Unmanaged 意味着 Operator 不会主动管理它的资源,也不会执行与相关组件相关的操作。一些 Operator 可能不支持此管理状态,因为它可能会损坏集群,需要手动恢复。

    警告

    将独立 Operator 更改为非受管状态会导致不支持该特定组件和功能。报告的问题必须在 受管(Managed) 状态中可以重复出现才能继续获得支持。

  • Cluster Version Operator (CVO) 覆盖

    可将 spec.overrides 参数添加到 CVO 配置中,以便管理员提供对组件的 CVO 行为覆盖的列表。将一个组件的 spec.overrides[].unmanaged 参数设置为 true 会阻止集群升级并在设置 CVO 覆盖后提醒管理员:

    Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
    警告

    设置 CVO 覆盖会使整个集群处于不受支持状态。在删除所有覆盖后,必须可以重现报告的问题方可获得支持。

第 2 章 更新集群概述

您可以使用 Web 控制台或 OpenShift CLI(oc)通过单个操作更新 OpenShift Container Platform 4 集群。

2.1. 了解 OpenShift Update Service

了解 OpenShift Update Service :对于具有互联网访问性的集群,红帽通过 OpenShift Container Platform 更新服务作为公共 API 后面的托管服务提供无线更新。如需更多信息,请参阅以下:

2.2. 安装和配置 OpenShift Update Service

安装和配置 OpenShift Update Service :具有互联网访问的集群可以访问公共 API;受限网络中的集群无法访问公共 API 来更新信息。要在受限网络中提供类似的升级体验,您可以在本地安装和配置 OpenShift Update Service,使其在断开连接的环境中可用。如需更多信息,请参阅以下:

2.3. 了解升级频道和发行版本

升级频道和发行版本 :升级频道允许您选择升级策略。升级频道特定于 OpenShift Container Platform 的次版本。升级频道仅控制发行版本选择,不会影响您安装的集群版本。OpenShift Container Platform 特定版本的 openshift-install 二进制文件总是安装该次版本。如需更多信息,请参阅以下:

2.4. 使用 Web 控制台更新集群

使用 Web 控制台更新集群:您可以使用 Web 控制台 更新 OpenShift Container Platform 集群。以下步骤在次版本中更新集群。您可以使用相同的说明在次版本之间更新集群。

2.5. 使用 CLI 更新集群

使用 CLI 更新集群 :您可以使用 OpenShift CLI(oc)更新 OpenShift Container Platform 集群。以下步骤在次版本中更新集群。您可以使用相同的说明在次版本之间更新集群。

2.6. 执行 canary rollout 更新

执行 Canary 推出部署更新: 通过控制对 worker 节点的更新,您可以确保关键任务应用程序在整个更新过程中仍然可用,即使更新过程会导致应用程序失败。根据您的机构需求,您可能需要更新一小部分 worker 节点,在一个时间段内评估集群和工作负载健康状况,然后更新剩余的节点。这称为 Canary 更新。或者,您可能还希望将通常需要主机重新引导的 worker 节点更新放入较小的定义的维护窗口(不可能一次使用大型维护窗口来更新整个集群)。您可以执行以下步骤:

2.7. 更新包含使用 RHEL 的计算(compute)系统的集群

更新包含 RHEL 计算机器的集群 :如果集群包含 Red Hat Enterprise Linux(RHEL)机器,则必须执行额外的步骤来更新这些机器。您可以执行以下步骤:

2.8. 更新受限网络集群

更新受限网络集群 :如果镜像主机无法同时访问互联网和集群,您可以将镜像(mirror)到与该环境中断开连接的文件系统,然后在这一差距中造成主机或可移动介质。如果本地容器 registry 和集群连接到 registry 的镜像主机,您可以直接将发行镜像推送到本地 registry。

第 3 章 安装和配置 OpenShift Update Service

对于可访问互联网的集群,红帽通过 OpenShift Container Platform 更新服务提供更新,它作为公共 API 后面的一个托管服务运行。但是,受限网络中的集群无法访问公共 API 来获取更新信息。

要在受限网络中提供类似的升级体验,您可以在本地安装和配置 OpenShift Update Service,使其在断开连接的环境中可用。

以下小节描述了如何为断开连接的集群及其底层操作系统提供无线更新。

3.1. 先决条件

3.1.1. 为 OpenShift 更新服务配置对安全 registry 的访问权限

如果发行镜像包括在安全 registry 中,请完成 为镜像 registry 访问配置额外信任存储的步骤,以及更新服务的以下更改。

OpenShift Update Service Operator 需要 registry CA 证书中的配置映射键名称为 updateservice-registry

更新服务的镜像 registry CA 配置映射示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  updateservice-registry: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 2
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

1
OpenShift Update Service Operator 需要 registry CA 证书中的配置映射键名称 updateservice-registry。
2
如果 registry 带有端口,如 registry-with-port.example.com:5000: 需要被 .. 替换。

3.1.2. 更新全局集群 pull secret

您可以通过替换当前的 pull secret 或附加新的 pull secret 来更新集群的全局 pull secret。

当用户使用单独的 registry 存储镜像而不使用安装过程中的 registry时,需要这个过程。

警告

集群资源必须调整为新的 pull secret,这样可暂时限制集群的可用性。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 可选: 要将新的 pull secret 附加到现有 pull secret 中,请完成以下步骤:

    1. 输入以下命令下载 pull secret:

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1
      1
      提供 pull secret 文件的路径。
    2. 输入以下命令来添加新 pull secret:

      $ oc registry login --registry="<registry>" \ 1
      --auth-basic="<username>:<password>" \ 2
      --to=<pull_secret_location> 3
      1
      提供新的 registry。您可以在同一个 registry 中包含多个软件仓库,例如:--registry="<registry/my-namespace/my-repository>"
      2
      提供新 registry 的凭据。
      3
      提供 pull secret 文件的路径。

      另外,您可以对 pull secret 文件执行手动更新。

  2. 输入以下命令为您的集群更新全局 pull secret:

    $ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1
    1
    提供新 pull secret 文件的路径。

    该更新将推广至所有节点,可能需要一些时间,具体取决于集群大小。

    注意

    从 OpenShift Container Platform 4.7.4 开始,对全局 pull secret 的更改不再触发节点排空或重启。

3.2. 安装 OpenShift Update Service Operator

要安装 OpenShift Update Service,您必须首先使用 OpenShift Container Platform Web 控制台或 CLI 安装 OpenShift Update Service Operator。

注意

对于在受限网络中安装的集群(也称为断开连接的集群),Operator Lifecycle Manager 默认无法访问托管在远程 registry 上的红帽提供的 OperatorHub 源,因为这些远程源需要有互联网连接。如需更多信息,请参阅 在受限网络中使用 Operator Lifecycle Manager

3.2.1. 使用 Web 控制台安装 OpenShift Update Service Operator

您可以使用 Web 控制台安装 OpenShift Update Service Operator。

流程

  1. 在 Web 控制台中,点 OperatorsOperatorHub

    注意

    Filter by keyword…​ 字段中输入 Update Service,以更快地查找 Operator。

  2. 从可用的 Operator 列表中选择 OpenShift Update Service,然后点 Install

    1. 频道 v1 被选为 Update Channel,因为它是这个版本中唯一可用的频道。
    2. Installation Mode 下选择 A specific namespace on the cluster
    3. Installed Namespace 选择一个命名空间,或接受推荐的命名空间 openshift-update-service
    4. 选择一个 批准策略

      • Automatic 策略允许 Operator Lifecycle Manager(OLM)在有新版本可用时自动更新 Operator。
      • Manual 策略要求集群管理员批准 Operator 更新。
    5. Install
  3. 通过切换到 Operators Installed Operators 页来验证 OpenShift Update Service Operator 是否已安装。
  4. 确保 OpenShift Update Service 列在所选命名空间中,StatusSucceeded

3.2.2. 使用 CLI 安装 OpenShift Update Service Operator

您可以使用 OpenShift CLI(oc)安装 OpenShift Update Service Operator。

流程

  1. 为 OpenShift Update Service Operator 创建命名空间:

    1. 为 OpenShift Update Service Operator 创建一个 Namespace 对象 YAML 文件,如 update-service-namespace.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-update-service
        annotations:
          openshift.io/node-selector: ""
        labels:
          openshift.io/cluster-monitoring: "true" 1
      1
      openshift.io/cluster-monitoring 标签设置为在该命名空间中启用 Operator-recommended 集群监控。
    2. 创建命名空间:

      $ oc create -f <filename>.yaml

      例如:

      $ oc create -f update-service-namespace.yaml
  2. 通过创建以下对象来安装 OpenShift Update Service Operator:

    1. 创建一个 OperatorGroup 对象 YAML 文件,如 update-service-operator-group.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: update-service-operator-group
      spec:
        targetNamespaces:
        - openshift-update-service
    2. 创建一个 OperatorGroup 对象:

      $ oc -n openshift-update-service create -f <filename>.yaml

      例如:

      $ oc -n openshift-update-service create -f update-service-operator-group.yaml
    3. 创建一个 Subscription 对象 YAML 文件,如 update-service-subscription.yaml

      订阅示例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: update-service-subscription
      spec:
        channel: v1
        installPlanApproval: "Automatic"
        source: "redhat-operators" 1
        sourceNamespace: "openshift-marketplace"
        name: "cincinnati-operator"

      1
      指定提供 Operator 的目录源的名称。对于不使用自定义 Operator Lifecycle Manager(OLM)的集群,指定 redhat-operators。如果 OpenShift Container Platform 集群安装在受限网络中(也称为断开连接的集群),请指定配置 Operator Lifecycle Manager(OLM)时创建的 CatalogSource 对象的名称。
    4. 创建 Subscription 对象:

      $ oc create -f <filename>.yaml

      例如:

      $ oc -n openshift-update-service create -f update-service-subscription.yaml

      OpenShift Update Service Operator 被安装到 openshift-update-service 命名空间,并以 openshift-update-service 命名空间为目标。

  3. 验证 Operator 安装:

    $ oc -n openshift-update-service get clusterserviceversions

    输出示例

    NAME                             DISPLAY                    VERSION   REPLACES   PHASE
    update-service-operator.v4.6.0   OpenShift Update Service   4.6.0                Succeeded
    ...

    如果列出了 OpenShift Update Service Operator,则会成功安装。版本号可能与所示不同。

3.2.3. 创建 OpenShift Update Service 图形数据容器镜像

OpenShift Update Service 需要图形数据容器镜像,OpenShift Update Service 从中检索有关频道成员资格和阻止更新边缘的信息。图形数据通常直接从升级图形数据仓库中获取。在互联网连接不可用的环境中,从 init 容器加载此信息是使图形数据可供 OpenShift Update Service 使用的另一种方式。init 容器的角色是提供图形数据的本地副本,在 pod 初始化期间,init 容器会将数据复制到该服务可访问的卷中。

流程

  1. 创建一个 Dockerfile,如 ./Dockerfile,包含以下内容:

    FROM registry.access.redhat.com/ubi8/ubi:8.1
    
    RUN curl -L -o cincinnati-graph-data.tar.gz https://github.com/openshift/cincinnati-graph-data/archive/master.tar.gz
    
    CMD exec /bin/bash -c "tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/cincinnati/graph-data/ --strip-components=1"
  2. 使用上一步中创建的 docker 文件来构建图形数据容器镜像,如 registry.example.com/openshift/graph-data:latest

    $ podman build -f ./Dockerfile -t registry.example.com/openshift/graph-data:latest
  3. 将上一步中创建的 graph-data 容器镜像推送到 OpenShift Update Service 可以访问的存储库,如 registry.example.com/openshift/graph-data:latest

    $ podman push registry.example.com/openshift/graph-data:latest
    注意

    要将图形数据镜像推送到受限网络中的本地 registry,请将上一步中创建的 graph-data 容器镜像复制到可供 OpenShift Update Service 访问的存储库。运行 oc image mirror --help 查看可用选项。

3.2.4. 镜像 OpenShift Container Platform 镜像存储库

OpenShift Update Service 需要本地可访问的 registry,其中包含更新发行有效负载。

重要

为了避免 OpenShift Update Service 应用程序过量使用内存,建议将发行镜像镜像到单独的存储库,如下所述。

先决条件

  • 您已查看并完成了 "Mirroring images for a disconnected installation" 中直到(不包括)Mirroring the OpenShift Container Platform image repository 的步骤。
  • 您已将镜像 registry 配置为在受限网络中使用,并可访问您配置的证书和凭证。
  • 您已从 Red Hat OpenShift Cluster Manager 下载了 pull secret,并已修改为包含镜像存储库身份验证信息。
  • 如果您使用没有设置 Subject Alternative Name 的自签名证书,则必须在这个过程中使用 GODEBUG=x509ignoreCN=0 前执行 oc 命令。如果没有设置此变量,oc 命令会失败并显示以下错误:

    x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

流程

在镜像主机上完成以下步骤:

  1. 查看 OpenShift Container Platform 下载页面,以确定您要更新的 OpenShift Container Platform 版本,并决定 Repository Tags 页中的相应标签(tag)。
  2. 设置所需的环境变量:

    1. 导出发行版本信息:

      $ OCP_RELEASE=<release_version>

      对于 <release_version>,请指定与 OpenShift Container Platform 版本对应的标签,用于您的架构,如 4.6.4

    2. 导出本地 registry 名称和主机端口:

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      对于 <local_registry_host_name>,请指定镜像存储库的 registry 域名;对于 <local_registry_host_port>,请指定用于提供内容的端口。

    3. 导出本地存储库名称:

      $ LOCAL_REPOSITORY='<local_repository_name>'

      对于 <local_repository_name>,请指定要在 registry 中创建的仓库名称,如 ocp4/openshift4

    4. 导出包含发行镜像的额外本地存储库名称:

      $ LOCAL_RELEASE_IMAGES_REPOSITORY='<local_release_images_repository_name>'

      对于 <local_release_images_repository_name>,请指定要在 registry 中创建的仓库名称,如 ocp4/openshift4-release-images

    5. 导出要进行镜像的存储库名称:

      $ PRODUCT_REPO='openshift-release-dev'

      对于生产环境版本,必须指定 openshift-release-dev

    6. 导出 registry pull secret 的路径:

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      对于 <path_to_pull_secret>,请指定您创建的镜像 registry 的 pull secret 的绝对路径和文件名。

    7. 导出发行版本镜像:

      $ RELEASE_NAME="ocp-release"

      对于生产环境版本,您必须指定 ocp-release

    8. 为您的服务器导出构架类型,如 x86_64

      $ ARCHITECTURE=<server_architecture>
    9. 导出托管镜像的目录的路径:

      $ REMOVABLE_MEDIA_PATH=<path> 1
      1
      指定完整路径,包括开始的正斜杠(/)字符。
  3. 将版本镜像(mirror)到镜像 registry:

    • 如果您的镜像主机无法访问互联网,请执行以下操作:

      1. 将可移动介质连接到连接到互联网的系统。
      2. 查看要镜像的镜像和配置清单:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
      3. 将镜像镜像到可移动介质的目录中:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
      4. 将介质上传到受限网络环境中,并将镜像上传到本地容器 registry:

        $ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1
        1
        对于 REMOVABLE_MEDIA_PATH,您必须使用挂载可移动介质的路径。
      5. 将发行镜像镜像到单独的存储库:

        $ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
    • 如果本地容器 registry 连接到镜像主机,请直接将发行镜像推送到本地 registry:

      $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
           --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
           --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
           --to-release-image=${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

3.3. 创建 OpenShift Update Service 应用程序

您可以使用 OpenShift Container Platform Web 控制台或 CLI 创建 OpenShift Update Service 应用程序。

3.3.1. 使用 Web 控制台创建 OpenShift Update Service 应用程序

您可以使用 OpenShift Container Platform Web 控制台使用 OpenShift Update Service Operator 创建 OpenShift Update Service 应用程序。

先决条件

  • 已安装 OpenShift Update Service Operator。
  • OpenShift Update Service graph-data 容器镜像已创建并推送到 OpenShift Update Service 访问的存储库。
  • 当前发行版本和更新目标版本已被 mirror 到本地可访问的 registry 中。

流程

  1. 在 Web 控制台中,点 OperatorsInstalled Operators
  2. 从安装的 Operator 列表中选择 OpenShift Update Service
  3. Update Service 选项卡。
  4. Create UpdateService
  5. Name 字段中输入名称,如 service
  6. Graph Data Image 字段中输入本地 pullspec,指向在"创建 OpenShift Update Service 图形数据容器镜像"中创建的图形数据容器镜像,如 registry.example.com/openshift/graph-data:latest
  7. Releases 字段中,输入创建的本地 registry 和存储库,以在"镜像 OpenShift Container Platform 镜像存储库"中包括发行镜像,例如 registry.example.com/ocp4/openshift4-release-images
  8. Replicas 字段中输入 2
  9. 单击 Create 以创建 OpenShift Update Service 应用。
  10. 验证 OpenShift Update Service 应用程序:

    • Update Service 选项卡中的 UpdateServices 列表中,点刚才创建的 Update Service 应用程序。
    • 单击 Resources 选项卡。
    • 验证每个应用资源的状态是否为 Created

3.3.2. 使用 CLI 创建 OpenShift Update Service 应用程序

您可以使用 OpenShift CLI(oc)来创建 OpenShift Update Service 应用。

先决条件

  • 已安装 OpenShift Update Service Operator。
  • OpenShift Update Service graph-data 容器镜像已创建并推送到 OpenShift Update Service 访问的存储库。
  • 当前发行版本和更新目标版本已被 mirror 到本地可访问的 registry 中。

流程

  1. 配置 OpenShift Update Service 目标命名空间,如 openshift-update-service

    $ NAMESPACE=openshift-update-service

    命名空间必须与 operator 组中的 targetNamespaces 值匹配。

  2. 配置 OpenShift Update Service 应用程序的名称,如 service

    $ NAME=service
  3. 按照"镜像 OpenShift Container Platform 镜像存储库"中配置,为发行镜像配置本地 registry 和存储库,如 registry.example.com/ocp4/openshift4-release-images

    $ RELEASE_IMAGES=registry.example.com/ocp4/openshift4-release-images
  4. 将 graph-data 镜像的本地 pullspec 设置为在"创建 OpenShift Update Service 图形数据容器镜像"中创建的图形数据容器镜像,如 registry.example.com/openshift/graph-data:latest:

    $ GRAPH_DATA_IMAGE=registry.example.com/openshift/graph-data:latest
  5. 创建 OpenShift Update Service 应用程序对象:

    $ oc -n "${NAMESPACE}" create -f - <<EOF
    apiVersion: updateservice.operator.openshift.io/v1
    kind: UpdateService
    metadata:
      name: ${NAME}
    spec:
      replicas: 2
      releases: ${RELEASE_IMAGES}
      graphDataImage: ${GRAPH_DATA_IMAGE}
    EOF
  6. 验证 OpenShift Update Service 应用程序:

    1. 使用以下命令获取策略引擎路由:

      $ while sleep 1; do POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"; SCHEME="${POLICY_ENGINE_GRAPH_URI%%:*}"; if test "${SCHEME}" = http -o "${SCHEME}" = https; then break; fi; done

      您可能需要轮询,直到命令成功为止。

    2. 从策略引擎检索图形。确保为 channel 指定一个有效版本。例如,如果在 OpenShift Container Platform 4.7 中运行,请使用 stable-4.7

      $ while sleep 10; do HTTP_CODE="$(curl --header Accept:application/json --output /dev/stderr --write-out "%{http_code}" "${POLICY_ENGINE_GRAPH_URI}?channel=stable-4.6")"; if test "${HTTP_CODE}" -eq 200; then break; fi; echo "${HTTP_CODE}"; done

      这会轮询到图形请求成功为止,但生成的图形可能为空,具体取决于您已镜像的发行镜像。

注意

基于 RFC-1123 的策略引擎路由名称不能超过 63 个字符。如果您看到 ReconcileCompleted 状态为 false,原因为 CreateRouteFailed caused by host must conform to DNS 1123 naming convention and must be no more than 63 characters,请尝试使用较短的名称创建 Update Service。

3.3.3. 配置 Cluster Version Operator(CVO)

安装 OpenShift Update Service Operator 并创建 OpenShift Update Service 应用程序后,可以更新 Cluster Version Operator(CVO)从本地安装的 OpenShift Update Service 中拉取图形数据。

先决条件

  • 已安装 OpenShift Update Service Operator。
  • OpenShift Update Service graph-data 容器镜像已创建并推送到 OpenShift Update Service 访问的存储库。
  • 当前发行版本和更新目标版本已被 mirror 到本地可访问的 registry 中。
  • OpenShift Update Service 应用已创建。

流程

  1. 设置 OpenShift Update Service 目标命名空间,如 openshift-update-service

    $ NAMESPACE=openshift-update-service
  2. 设置 OpenShift Update Service 应用程序的名称,如 service

    $ NAME=service
  3. 获取策略引擎路由:

    $ POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"
  4. 为拉取图形数据设置补丁:

    $ PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
  5. 对 CVO 进行补丁以使用本地 OpenShift 更新服务:

    $ oc patch clusterversion version -p $PATCH --type merge
注意

请参阅启用集群范围代理以将 CA 配置为信任更新服务器。

3.4. 删除 OpenShift Update Service 应用程序

您可以使用 OpenShift Container Platform Web 控制台或 CLI 删除 OpenShift Update Service 应用程序。

3.4.1. 使用 Web 控制台删除 OpenShift Update Service 应用程序

您可以使用 OpenShift Container Platform Web 控制台使用 OpenShift Update Service Operator 删除 OpenShift Update Service 应用程序。

先决条件

  • 已安装 OpenShift Update Service Operator。

流程

  1. 在 Web 控制台中,点 OperatorsInstalled Operators
  2. 从安装的 Operator 列表中选择 OpenShift Update Service
  3. Update Service 选项卡。
  4. 从安装的 OpenShift Update Service 应用列表中,选择要删除的应用,然后单击 Delete UpdateService
  5. Delete UpdateService? 确认对话框中,单击 Delete 以确认删除。

3.4.2. 使用 CLI 删除 OpenShift Update Service 应用程序

您可以使用 OpenShift CLI(oc)删除 OpenShift Update Service 应用。

流程

  1. 使用 OpenShift Update Service 应用程序在其中创建的命名空间获取 OpenShift Update Service 应用程序的名称,如 openshift-update-service

    $ oc get updateservice -n openshift-update-service

    输出示例

    NAME      AGE
    service   6s

  2. 使用上一步中的 NAME 值以及 OpenShift Update Service 应用程序创建命名空间删除 OpenShift Update Service 应用程序,如 openshift-update-service

    $ oc delete updateservice service -n openshift-update-service

    输出示例

    updateservice.updateservice.operator.openshift.io "service" deleted

3.5. 卸载 OpenShift Update Service Operator

要卸载 OpenShift Update Service,首先需要使用 OpenShift Container Platform Web 控制台或 CLI 删除所有 OpenShift Update Service 应用程序。

3.5.1. 使用 Web 控制台卸载 OpenShift Update Service Operator

您可以使用 OpenShift Container Platform Web 控制台卸载 OpenShift Update Service Operator。

先决条件

  • 所有 OpenShift Update Service 应用都已删除。

流程

  1. 在 Web 控制台中,点 OperatorsInstalled Operators
  2. 从安装的 Operator 列表中选择 OpenShift Update Service 并点 Uninstall Operator
  3. Uninstall Operator? 确认对话框中点 Uninstall 确认卸载。

3.5.2. 使用 CLI 卸载 OpenShift Update Service Operator

您可以使用 OpenShift CLI(oc)卸载 OpenShift Update Service Operator。

先决条件

  • 所有 OpenShift Update Service 应用都已删除。

流程

  1. 更改到包含 OpenShift Update Service Operator 的项目,如 openshift-update-service

    $ oc project openshift-update-service

    输出示例

    Now using project "openshift-update-service" on server "https://example.com:6443".

  2. 获取 OpenShift Update Service Operator operator 组的名称:

    $ oc get operatorgroup

    输出示例

    NAME                             AGE
    openshift-update-service-fprx2   4m41s

  3. 删除 operator 组,如 openshift-update-service-fprx2

    $ oc delete operatorgroup openshift-update-service-fprx2

    输出示例

    operatorgroup.operators.coreos.com "openshift-update-service-fprx2" deleted

  4. 获取 OpenShift Update Service Operator 订阅的名称:

    $ oc get subscription

    输出示例

    NAME                      PACKAGE                   SOURCE                        CHANNEL
    update-service-operator   update-service-operator   updateservice-index-catalog   v1

  5. 使用上一步中的 Name 值,在 currentCSV 字段中检查订阅的 OpenShift Update Service Operator 的当前版本:

    $ oc get subscription update-service-operator -o yaml | grep " currentCSV"

    输出示例

      currentCSV: update-service-operator.v0.0.1

  6. 删除订阅,如 update-service-operator

    $ oc delete subscription update-service-operator

    输出示例

    subscription.operators.coreos.com "update-service-operator" deleted

  7. 使用上一步中的 currentCSV 值删除 OpenShift Update Service Operator 的 CSV:

    $ oc delete clusterserviceversion update-service-operator.v0.0.1

    输出示例

    clusterserviceversion.operators.coreos.com "update-service-operator.v0.0.1" deleted

第 4 章 了解升级频道和发行版本

在 OpenShift Container Platform 4.1 中,红帽引进了频道的概念,用于为集群更新推荐适当的版本。通过控制更新的速度,这些升级频道允许您选择更新策略。升级频道与 OpenShift Container Platform 的次要版本关联。例如,OpenShift Container Platform 4.7 升级频道推荐对 4.7 进行更新以及在 4.7 内更新。它们还推荐在 4.6 内更新以及从 4.6 升级到 4.7,以便 4.6 上的集群最终更新至 4.7。它们不推荐更新 4.8 或更高版本。此策略可确保管理员明确决定升级到下一个 OpenShift Container Platform 次要版本。

升级频道仅控制版本选择,它不会影响您安装的集群版本; 特定版本的 OpenShift Container Platform 的 openshift-install 二进制文件始终会安装这个特定版本。

OpenShift Container Platform 4.7 提供了以下升级频道:

  • candidate-4.7
  • fast-4.7
  • stable-4.7
  • eus-4.y(仅在运行偶数 4.y 集群发行版本时,如 4.6)
警告

红帽建议升级到 Openshift Update Service 建议的版本。对于次版本更新,版本必须相邻。红帽没有测试在非连续地版本间的升级,无法保证与之前版本的兼容性。

4.1. 升级频道和发行路径

集群管理员可以通过 Web 控制台配置升级频道。

4.1.1. candidate-4.7 频道

candidate-4.7 频道包含 z-stream(4.7.z)和之前的次版本的候选构建。发行候选版本包含该产品的所有功能但不被正式支持。发行候选版本可以用来测试新版本的功能以决定下一个 OpenShift Container Platform 版本是否适用于您的系统。发行候选是指候选频道中可用的构建,包括那些不包含 预发布版本 (如 -rc )的构建。当一个版本出现在候选频道中后,它仍然会进行更多的质量测试。如果达到质量标准,则会将其推广至 fast-4.7stable-4.7 频道。因此,如果一个特定的版本同时存在于 candidate-4.7 频道以及 fast-4.7stable-4.7 的频道中,则代表红帽会支持这个版本。candidate-4.7 频道可能会包括任何频道都不推荐更新的发行版本。

您可以使用 candidate-4.7 频道以前的 OpenShift Container Platform 次版本进行升级。

4.1.2. fast-4.7 频道

当红帽声明某个特定版本成为正式发行版本时,fast-4.7 频道被更新来包括这个新的和以前的 4.7 次版本。这意味着,这些版本被完全支持,且具有符合生产环境的质量,当它们作为发行候选版本出现在 candidate-4.7 频道期间,被证明可以正常工作。当一个发行版本出现在 fast-4.7 频道中的一段时间后,会被添加到 stable-4.7 频道。在它们出现在 fast-4.7 频道之前,不会出现在 stable-4.7 频道中。

您可以使用 fast-4.7 频道来从以前的 OpenShift Container Platform 次版本进行升级。

4.1.3. stable-4.7 频道

虽然当它们的勘误被发布后马上就会出现在 fast-4.7 频道中,但这些内容可能需要一段延迟时间会被添加到 stable-4.7 频道中。在此延迟期间,红帽 SRE 团队、红帽支持服务以及参与连接的客户程序的生产前和产品环境中收集有关此发行版本的稳定性数据。您可以使用 stable-4.7 频道来从以前的 OpenShift Container Platform 次版本进行更新。

4.1.4. eus-4.y 频道

除了 stable 频道外,所有以数字相等的 OpenShift Container Platform 次版本都提供延长更新支持 (EUS)。对于具有标准和高级订阅的客户,这些 EUS 版本将完全支持和维护支持阶段延长至 18 个月。

虽然 stable-4.yeus-4.y 频道之间没有区别,直到 OpenShift Container Platform 4.y 过渡到 EUS 阶段,您可以立即切换到 eus-4.y 频道。

当提供了升级到下一个 EUS 的频道时,您可以切换到下一个 EUS 频道并升级,直到您升级到下一个 EUS 版本。

此更新过程不适用于 eus-4.6 频道。

注意

标准和非 EUS 订阅者都可以访问所有 EUS 软件仓库和所需的 RPM(rhel-*-eus-rpms),它们都能够支持关键目的,如调试和构建驱动程序。

4.1.5. 升级版本路径

OpenShift Container Platform 维护一个升级建议服务,它了解已安装的 OpenShift Container Platform 版本以及您选择用来获取下一版本的频道中的路径。

您可在 fast-4.7 频道中看到以下内容:

  • 4.7.0
  • 4.7.1
  • 4.7.3
  • 4.7.4

该服务只建议经过测试且不存在严重问题的升级。它不会建议把系统更新到一个包含已知漏洞的 OpenShift Container Platform 版本。例如,如果您的集群为 4.7.1,OpenShift Container Platform 推荐 4.7.4,您可以安全地从 4.7.1 升级到 4.7.4。您不需要一定在连续的补丁号间进行升级。在这个示例中,该频道并没有(且从来没有)包括 4.7.2。

更新的稳定性取决于您的频道。在 candidate-4.7 频道中存在一个更新建议并不意味着这个更新会被支持。它代表,在更新中还没有发现任何严重问题,这可能是因为此更新还没有足够的使用情况来证明它的稳定性。如果在 fast-4.7stable-4.7 频道中出现了一个更新建议,则代表这个更新被支持。虽然发行版本永远不会从一个频道中删除,但存在严重问题的更新建议会从所有频道中删除。在更新建议被删除后启动的更新仍被支持。

红帽最终会为 fast-4.7stable-4.7 频道中支持的发行版本提供到最新的 4.7.z 版本的更新路径,但可能会因为创建并验证解决已知问题的更新路径而有一定的延迟。

4.1.6. fast 和 stable 频道的使用和策略

通过 fast-4.7stable-4.7 频道,您可以选择在一个发行版本正式发行后马上接收到这个版本,或选择由红帽控制向用户推出更新的过程。如果在推出部署的过程或之后发现问题,到这个版本的更新可能会在 fast-4.7stable-4.7 频道中被禁止。一个新版本可能会出现,做为新的首选更新目标。

通过在 fast-4.7 频道中配置预生产环境的系统、在 stable-4.7 频道中配置生产环境的系统,并参与红帽连接的客户项目,用户可以改进更新的过程。红帽使用这个程序观察更新对您特定的硬件和软件配置的影响。将来的版本可能会改进或修改更新从 fast-4.7 频道进入 stable-4.7 频道的速度。

4.1.7. 受限网络集群

如果您自己为 OpenShift Container Platform 集群管理容器镜像,您必须考虑与产品关联的红帽勘误中的升级信息。在升级过程中,用户界面可能会提醒您在这些版本间进行切换,因此您必须在跳过这些警告前确定选择了正确的版本。

4.1.8. 在频道间切换

可以从 web 控制台或通过 patch 命令来切换频道:

$ oc patch clusterversion version --type json -p '[{"op": "add", "path": "/spec/channel", "value": "<channel>”}]'

如果您切换到没有包括当前版本的频道,web 控制台将显示警报。在没有当前发行版本的频道中,web 控制台不推荐任何更新。但是,您可以在任何时候返回原始频道。

更改您的频道可能会影响集群的可支持性。可能适用以下条件:

  • 如果您从 stable-4.7 频道改到 fast-4.7 频道,您的集群仍然被支持。
  • 您可以切换到 candidate-4.7 频道,但这个频道的一些发行版本可能不被支持。
  • 如果您当前的发行版本是正式发布版本,则可以从 candidate-4.7 频道切换到 fast-4.7 频道。
  • fast-4.7 频道切换到 stable-4.7 频道始终被允许。如果当前版本最近被提升,该发行版本可能会有最多一天的延迟才会出现在 stable-4.7 中。

第 5 章 使用 Web 控制台更新集群

您可以使用 web 控制台对 OpenShift Container Platform 集群进行更新或升级。以下步骤在次版本中更新集群。您可以使用相同的说明在次版本之间更新集群。

注意

由于使用 oc更改更新频道会比较困难,所以请使用 web 控制台来更改更新频道。建议您在 web 控制台中完成更新过程。在改到一个 4.7 频道后,按照使用 CLI 更新集群中的步骤完成更新。

5.1. 先决条件

  • 使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义和应用权限
  • 具有最新的 etcd 备份,以防因为升级失败需要将集群恢复到以前的状态
  • 确保之前通过 Operator Lifecycle Manager(OLM)安装的所有 Operator 均更新至其最新频道中的最新版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版本切换到下一个次版本时,它们有有效的升级路径。如需更多信息,请参阅升级安装的 Operator
  • 确保所有机器配置池 (MCP) 都正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行 canary rollout 更新策略,可以暂停 MCP。
  • 如果您的集群使用手动维护的凭证,请确保 Cloud Credential Operator(CCO)处于可升级状态。如需更多信息,请参阅为 AWSAzureGCP 手动维护凭证升级集群
重要
  • 当更新无法完成时,Cluster Version Operator(CVO)会在尝试协调更新时报告任何阻塞组件的状态。当前还不支持将集群还原到以前的版本。如果您的更新无法完成,请联系红帽支持。
  • 使用 unsupportedConfigOverrides 部分修改 Operator 配置不受支持,并可能会阻止集群更新。您必须在更新集群前删除此设置。

5.2. 执行 canary rollout 更新

在某些情况下,您可能需要一个受控的更新过程,如您不希望特定节点与集群的其余部分同时更新。这些用例包括但不限于:

  • 您有任务关键型应用程序,您希望在更新过程中仍然可以使用这些应用程序。在更新后,您可以慢慢地以小批的形式对应用进行测试。
  • 您有一个短的维护窗口,在此期间不允许更新所有节点;或者您有多个维护窗口。

滚动更新过程不是典型的更新工作流。对于较大的集群,这可能是一个耗时的过程,需要您执行多个命令。这种复杂性可能会导致出现可能会影响整个集群的错误。建议您仔细考虑您的机构是否希望使用滚动更新,并在开始前仔细规划流程的实施。

本主题中描述的滚动更新过程涉及:

  • 创建一个或多个自定义机器配置池 (MCP)。
  • 标记您不想立即更新的每个节点,以将这些节点移至自定义 MCP。
  • 暂停这些自定义 MCP,这会阻止对这些节点的更新。
  • 执行集群更新。
  • 取消暂停一个自定义 MCP,它会在这些节点上触发更新。
  • 测试这些节点上的应用程序,以确保应用程序在这些新更新的节点上可以正常工作。
  • (可选)从小批处理中的其余节点移除自定义标签,并在这些节点上测试应用。
注意

暂停 MCP 可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。如果 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动更新证书时,MCP 会暂停,但不会在相应机器配置池中的节点中应用新证书。这会导致多个 oc 命令失败,包括但不限于 oc debugoc logsoc execoc attach。在暂停 MCP 时应该非常小心,需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题,且仅在短时间内暂停。

如果要使用 Canary rollout 更新过程,请参阅执行 Canforming rollout 更新

5.3. 使用Web控制台更新集群

如果有可用更新,您可以从Web控制台更新集群。

您可以在客户门户网站的勘误部分找到有关可用 OpenShift Container Platform 公告和更新的信息。

先决条件

  • 使用具有 admin 权限的用户登陆到 web 控制台。

流程

  1. 在 web 控制台中点击 AdministrationCluster Settings 并查看 Details 选项卡中的内容。
  2. 对于生产环境中的集群,请确保将 Channel 设置为您要升级到的版本的正确频道,如 stable-4.7

    重要

    对于生产环境中的集群,需要订阅到 stable-*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-*fast-* 频道,并更新至您在该频道中想要的版本。

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

5.4. 使用 Web 控制台更改更新服务器

更改更新服务器是可选的。如果您在本地安装和配置了 OpenShift Update Service (OSUS),您必须将服务器的 URL 设置为 upstream,以便在更新期间使用本地服务器。

流程

  1. 导航到 AdministrationCluster Settings,点 version
  2. 点击 YAML 选项卡,然后编辑 upstream 参数值:

    输出示例

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

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

    默认 upstreamhttps://api.openshift.com/api/upgrades_info/v1/graph

  3. 点击 Save

第 6 章 使用 CLI 更新集群

您可以使用 OpenShift CLI (oc) 将 OpenShift Container Platform 集群更新或升级到一个次版本。您还可以按照相同的说明在次版本间更新集群。

6.1. 先决条件

  • 使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义和应用权限
  • 具有最新的 etcd 备份,以防因为升级失败需要将集群恢复到以前的状态
  • 确保之前通过 Operator Lifecycle Manager(OLM)安装的所有 Operator 均更新至其最新频道中的最新版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版本切换到下一个次版本时,它们有有效的升级路径。如需更多信息,请参阅升级安装的 Operator
  • 确保所有机器配置池 (MCP) 都正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行 canary rollout 更新策略,可以暂停 MCP。
  • 如果您的集群使用手动维护的凭证,请确保 Cloud Credential Operator(CCO)处于可升级状态。如需更多信息,请参阅为 AWSAzureGCP 手动维护凭证升级集群
重要
  • 当更新无法完成时,Cluster Version Operator(CVO)会在尝试协调更新时报告任何阻塞组件的状态。当前还不支持将集群还原到以前的版本。如果您的更新无法完成,请联系红帽支持。
  • 使用 unsupportedConfigOverrides 部分修改 Operator 配置不受支持,并可能会阻止集群更新。您必须在更新集群前删除此设置。

6.2. 使用 CLI 更新集群

如果有可用更新,您可以使用OpenShift CLI (oc)更新集群。

您可以在客户门户网站的勘误部分找到有关可用 OpenShift Container Platform 公告和更新的信息。

先决条件

  • 安装与更新版本的版本匹配的 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 权限的用户登陆到集群。
  • 安装jq软件包。

流程

  1. 确认集群可用

    $ oc get clusterversion

    输出示例

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

  2. 检查当前的更新频道信息,并确认您的频道已设置为stable-4.7

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

    输出示例

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

    重要

    对于生产环境中的集群,需要订阅到 stable-*fast-* 频道。

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

    $ oc adm upgrade

    输出示例

    Cluster version is 4.1.0
    
    Updates:
    
    VERSION IMAGE
    4.1.2   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.7",
      "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
      "desiredUpdate": {
        "force": false,
        "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
        "version": "4.7.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.7.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.7.0"
      }
    ]

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

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

    $ oc get clusterversion

    输出示例

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

  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.20.0
    ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.20.0
    ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.20.0
    ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.20.0
    ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.20.0
    ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.20.0

6.3. 使用 CLI 更改更新服务器

更改更新服务器是可选的。如果您在本地安装和配置了 OpenShift Update Service (OSUS),您必须将服务器的 URL 设置为 upstream,以便在更新期间使用本地服务器。upstream 的默认值是 https://api.openshift.com/api/upgrades_info/v1/graph

流程

  • 更改集群版本中的 upstream 参数值:

    $ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update-server-url>"}}' --type=merge

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

    输出示例

    clusterversion.config.openshift.io/version patched

第 7 章 执行 canary rollout 更新

有些情况下,您可能希望对 worker 节点进行更多受控的更新推出,以确保任务关键型应用程序在更新过程中仍然可用,即使更新过程导致您的应用程序失败。根据您的机构需求,您可能需要更新一小部分 worker 节点,在一个时间段内评估集群和工作负载健康状况,然后更新剩余的节点。这通常被称为 Canary 更新。或者,您可能还希望将通常需要主机重新引导的 worker 节点更新放入较小的定义的维护窗口(不可能一次使用大型维护窗口来更新整个集群)。

在这些情况下,您可以创建多个自定义机器配置池 (MCP),以防止某些 worker 节点在更新集群时进行更新。在更新剩余的集群后,您可以在适当的时间批量更新这些 worker 节点。

例如,如果您的集群有 100 个节点,且有 10% 过量的容量,维护窗口不能超过 4 小时,并且您知道排空和重新引导 worker 节点的时间不超过 8 分钟,您可以利用 MCP 来实现您的目标。例如,您可以定义四个 MCP,分别名为 workerpool-canaryworkerpool-Aworkerpool-Bworkerpool-C,分别有 10、30、30 和 30 个节点。

在第一次维护窗口中,您将暂停 workerpool-Aworkerpool-Bworkerpool-C 的 MCP,然后启动集群更新。这会更新在 OpenShift Container Platform 上运行的组件,以及属于 workerpool-canary MCP 成员的 10 个节点,因为这个池没有暂停。其他三个 MCP 不会更新,因为它们已暂停。如果出于某种原因,您确定集群或工作负载健康受到 workerpool-canary 更新的负面影响,那么在分析完问题前,您会在保持足够容量的同时,对那个池中的所有节点进行 cordon 和 drain 操作。当一切正常时,您将在决定取消暂停前评估集群和工作负载健康状况,从而在每个额外的维护窗口中持续更新 workerpool-Aworkerpool-Bworkerpool-C

使用自定义 MCP 管理 worker 节点更新提供了灵活性,这可能是一个耗时的过程,需要您执行多个命令。这种复杂性可能会导致出现可能会影响整个集群的错误。建议您仔细考虑您的组织需求,并在开始之前仔细规划流程的实施。

注意

不建议将 MCP 更新至不同的 OpenShift Container Platform 版本。例如,请勿将一个 MCP 从 4.y.10 更新至 4.y.11,另一个更新为 4.y.12。这个场景还没有被测试,可能会导致未定义的集群状态。

重要

暂停机器配置池可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。如果 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动更新证书时,MCP 会暂停,但不会在相应机器配置池中的节点中应用新证书。这会导致多个 oc 命令失败,包括但不限于 oc debugoc logsoc execoc attach。在暂停 MCP 时应该非常小心,需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题,且仅在短时间内暂停。

7.1. 关于 Canary rollout 更新过程和 MCP

在 OpenShift Container Platform 中,节点不会被单独考虑。节点分组到机器配置池中 (MCP)。默认 OpenShift Container Platform 集群中有两个 MCP:一个用于 control plane 节点,一个用于 worker 节点。OpenShift Container Platform 更新会同时影响所有 MCP。

在更新过程中,Machine Config Operator (MCO) 会排空并记录 MCP 中的所有节点,直至指定的 maxUnavailable 数量(如果指定),默认为 1。排空节点取消调度节点上的所有 pod,并将该节点标记为不可调度。节点排空后,Machine Config Daemon 应用一个新的机器配置,其中包括更新操作系统 (OS)。更新操作系统需要主机重新引导。

要防止特定节点被更新,且不会排空、进行 cordoned 和更新,您可以创建自定义 MCP。然后,暂停这些 MCP,以确保不更新与这些 MCP 关联的节点。MCO 不会更新任何暂停的 MCP。您可以创建一个或多个自定义 MCP,这样可以让您更好地控制您更新这些节点的顺序。更新第一个 MCP 中的节点后,您可以验证应用兼容性,然后逐步将其余节点更新至新版本。

注意

为确保 control plane 的稳定性,不支持从 control plane 节点(也称为 master 节点)创建自定义 MCP。Machine Config Operator (MCO) 会忽略为 control plane 节点创建的任何自定义 MCP。

根据工作负载部署拓扑,您应该仔细考虑您创建的 MCP 数以及每个 MCP 中的节点数量。例如,如果需要将更新融入特定的维护窗口,您需要知道 OpenShift Container Platform 可在窗口中更新的节点数量。这个数字取决于您具体的集群和工作负载特性。

另外,您需要考虑集群中可用的额外容量量。例如,当应用程序无法在更新的节点上按预期工作时,您可以对池中那些节点进行 cordon 和 drain 操作,这会将应用 pod 移到其他节点上。您需要考虑您可用的额外容量数量,以确定您需要的自定义 MCP 数量以及每个 MCP 中有多少节点。例如,如果您使用两个自定义 MCP 和 50% 的节点在每个池中,则需要确定运行 50% 的节点是否能为您的应用程序提供足够的服务质量(QoS)。

您可以将这个更新过程与所有记录的 OpenShift Container Platform 更新过程一起使用。但是,该过程不适用于使用 Ansible playbook 进行更新的 Red Hat Enterprise Linux (RHEL) 机器。

7.2. 关于执行 canary rollout 更新

本主题描述了此 canary rollout 更新过程的一般工作流。以下小节介绍了工作流中执行每项任务的步骤。

  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 debugoc logsoc execoc attach

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

7.3. 创建机器配置池来执行 canary rollout 更新

执行此 canary rollout 更新的第一个任务是创建一个或多个机器配置池 (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。

7.4. 暂停机器配置池

在这个 Canary rollout 更新过程中,在使用 OpenShift Container Platform 集群的其余集群标记了节点并创建机器配置池 (MCP) 后,您会暂停这些 MCP。暂停 MCP 可防止 Machine Config Operator (MCO) 更新与该 MCP 关联的节点。

注意

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

暂停 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

7.5. 执行集群更新

当 MCP 进入 ready 状态时,您可以执行集群更新。根据您的集群,请查看以下更新方法之一:

更新完成后,您可以开始逐一取消暂停 MCP。

7.6. 取消暂停机器配置池

在这个 Canary rollout 更新过程中,OpenShift Container Platform 更新完成后,取消逐一暂停自定义 MCP。取消暂停 MCP 允许 Machine Config Operator (MCO) 更新与该 MCP 关联的节点。

取消暂停 MCP:

  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,并验证您的应用程序是否正常工作。

7.6.1. 如果应用程序失败

如果应用程序出现故障,如应用程序未在更新的节点上工作,您可以对池中的节点进行 cordon 和 drain 操作,这会将应用 pod 移到其他节点,以帮助维护应用程序的服务质量。第一个 MCP 不应大于过量容量。

7.7. 将节点移到原始机器配置池中

在这个 Canary rollout 更新过程中,在取消暂停自定义机器配置池 (MCP) 并验证与该 MCP 关联的节点上的应用程序是否按预期工作后,您应该删除添加到节点的自定义标签,将节点移回原始 MCP。

重要

节点必须具有角色才能在集群中正常工作。

将节点移动到其原始 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>

第 8 章 更新包含使用 RHEL 的计算(compute)系统的集群

您可以更新或升级OpenShift Container Platform集群。如果您的集群包含Red Hat Enterprise Linux(RHEL)系统,则必须执行额外的步骤来更新这些系统。

8.1. 先决条件

重要

如果您使用附加的 Prometheus PVC 运行集群监控,在集群升级过程中可能会出现 OOM 终止的情况。当 Prometheus 使用持久性存储时,Prometheus 内存在升级过程中会加倍,并在升级完成后的几小时内仍会是这个情况。为了避免 OOM 终止问题,允许升级前有双倍可用内存的 worker 节点。例如,如果您在最低推荐节点上运行监控(2 个内核,8 GB RAM),将内存增加到 16 GB。如需更多信息,请参阅 BZ#1925061

8.2. 使用Web控制台更新集群

如果有可用更新,您可以从Web控制台更新集群。

您可以在客户门户网站的勘误部分找到有关可用 OpenShift Container Platform 公告和更新的信息。

先决条件

  • 使用具有 admin 权限的用户登陆到 web 控制台。

流程

  1. 在 web 控制台中点击 AdministrationCluster Settings 并查看 Details 选项卡中的内容。
  2. 对于生产环境中的集群,请确保将 Channel 设置为您要升级到的版本的正确频道,如 stable-4.7

    重要

    对于生产环境中的集群,需要订阅到 stable-*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-*fast-* 频道,并更新至您在该频道中想要的版本。

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

    注意

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

8.3. 可选:添加 hook 以在RHEL系统上执行Ansible任务

在OpenShift Container Platform更新期间,您可以使用hook在RHEL计算系统上运行Ansible任务。

8.3.1. 在升级过程中使用 Ansible hook

更新OpenShift Container Platform时,可以使用hook在执行特定操作时在Red Hat Enterprise Linux(RHEL)节点上运行自定义的任务。您可以使用 hook 提供定义了在执行特定任务之前或之后要运行的任务的文件。在OpenShift Container Platform集群中更新RHEL计算节点时,可以使用 hook 来验证或修改自定义的基础架构。

因为当 hook 失败时,这个操作将会失败,所以您必须把 hook 设计为可以多次运行,并且获得相同的结果。

hook 有以下限制: - hook 没有已定义或版本化的界面。它们可以使用内部的openshift-ansible变量,但这些变量可能会在将来的OpenShift Container Platform版本被修改或删除。 - hook 本身没有错误处理机制,因此 hook 中的错误会暂停更新过程。如果出现错误,则需要解决相关的问题,然后再次进行升级。

8.3.2. 配置Ansible inventory文件以使用 hook

您可以在 hosts inventory 文件的all:vars 部分中定义 Red Hat Enterprise Linux(RHEL)compute 机器(也称为 worker 机器)更新时使用的 hook 。

先决条件

  • 您可以访问用于添加RHEL compute 系统集群的计算机。您必须有访问定义RHEL系统的hosts Ansible 清单文件的权限。

流程

  1. 在设计了 hook 后,创建一个YAML文件,为其定义Ansible任务。此文件必须是一组任务,不能是一个 playbook,如以下示例所示:

    ---
    # Trivial example forcing an operator to acknowledge the start of an upgrade
    # file=/home/user/openshift-ansible/hooks/pre_compute.yml
    
    - name: note the start of a compute machine update
      debug:
          msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"
    
    - name: require the user agree to start an upgrade
      pause:
          prompt: "Press Enter to start the compute machine update"
  2. 修改 hosts Ansible inventory 文件来指定 hook 文件。hook 文件作为参数值在 [all:vars] 部分指定。如下所示:

    清单文件中的 hook 定义示例

    [all:vars]
    openshift_node_pre_upgrade_hook=/home/user/openshift-ansible/hooks/pre_node.yml
    openshift_node_post_upgrade_hook=/home/user/openshift-ansible/hooks/post_node.yml

    为了避免歧义,请在其定义中使用 hook 文件的绝对路径而不要使用相对路径。

8.3.3. RHEL计算系统可用的 hook

在更新OpenShift Container Platform集群中的Red Hat Enterprise Linux(RHEL)compute 系统时,可以使用以下 hook。

Hook 名描述

openshift_node_pre_cordon_hook

  • 在每个节点被封锁(cordon)之前运行。
  • 此 hook 以串行方式针对每个节点运行。
  • 如果某个任务必须针对其他主机运行,则该任务必须使用delegate_tolocal_action

openshift_node_pre_upgrade_hook

  • 在每个节点被封锁,且被更新运行。
  • 此 hook 以串行方式针对每个节点运行。
  • 如果某个任务必须针对其他主机运行,则该任务必须使用delegate_tolocal_action

openshift_node_pre_uncordon_hook

  • 在每个节点被更新,且被取消封锁(uncordon)运行。
  • 此 hook 以串行方式针对每个节点运行。
  • 如果某个任务必须针对其他主机运行,则该任务必须使用delegate_tolocal_action

openshift_node_post_upgrade_hook

  • 每个节点未被取消封锁运行。这是最后一个节点更新操作。
  • 此 hook 以串行方式针对每个节点运行。
  • 如果某个任务必须针对其他主机运行,则该任务必须使用delegate_tolocal_action

8.4. 更新集群中的RHEL compute 系统

在对集群进行更新后,必须更新集群中的Red Hat Enterprise Linux(RHEL)compute 系统。

重要

因为 worker (compute) 机器只支持 Red Hat Enterprise Linux (RHEL) 版本 7.9 或更高版本,所以不能将 RHEL worker 机器升级到版本 8。

如果您使用 RHEL 作为操作系统,您还可以将计算机器更新至 OpenShift Container Platform 的另一个次要版本。当执行次版本更新时,您不需要排除 RHEL 中的任何 RPM 软件包。

先决条件

  • 已更新了集群

    重要

    因为 RHEL 机器需要集群生成的资产才能完成更新过程,所以您必须在更新其中的 RHEL worker 机器前更新集群。

  • 您可以访问用于将 RHEL 计算机器添加到集群的本地机器。您必须有权访问定义了 RHEL 系统及 upgrade playbook 的hosts Ansible 清单文件。
  • 对于次版本的更新,RPM 存储库使用的是集群上运行的相同版本的 OpenShift Container Platform。

流程

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

    # systemctl disable --now firewalld.service
    注意

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

  2. 启用 OpenShift Container Platform 4.7 所需的仓库:

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

      # subscription-manager repos --disable=rhel-7-server-ose-4.6-rpms \
                                   --enable=rhel-7-server-ansible-2.9-rpms \
                                   --enable=rhel-7-server-ose-4.7-rpms
    2. 在运行 Ansible playbook 的机器上,更新所需的软件包,包括 openshift-ansible

      # yum update openshift-ansible openshift-clients
    3. 在每个 RHEL 计算节点上,更新所需的软件仓库:

      # subscription-manager repos --disable=rhel-7-server-ose-4.6-rpms \
                                   --enable=rhel-7-server-ose-4.7-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.20.0
      mycluster-control-plane-1   Ready                         master   145m   v1.20.0
      mycluster-control-plane-2   Ready                         master   145m   v1.20.0
      mycluster-rhel7-0           NotReady,SchedulingDisabled   worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-1           Ready                         worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-2           Ready                         worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-3           Ready                         worker   98m    v1.14.6+97c81d00e

      记录下哪个机器具有 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.20.0
    mycluster-control-plane-1   Ready                         master   145m   v1.20.0
    mycluster-control-plane-2   Ready                         master   145m   v1.20.0
    mycluster-rhel7-0           NotReady,SchedulingDisabled   worker   98m    v1.20.0
    mycluster-rhel7-1           Ready                         worker   98m    v1.20.0
    mycluster-rhel7-2           Ready                         worker   98m    v1.20.0
    mycluster-rhel7-3           Ready                         worker   98m    v1.20.0

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

    # yum update
    注意

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

第 9 章 更新受限网络集群

您可以使用 oc CLI 更新受限网络 OpenShift Container Platform 集群。

受限网络环境是集群节点无法访问互联网的环境。因此,您必须在 registry 中填充安装镜像。如果您的 registry 主机无法同时访问互联网和集群,您可以将镜像镜像到与这个环境断开连接的文件系统中,然后使用主机或可移动介质填补该空白。如果本地容器 registry 和集群连接到镜像 registry 的主机,您可以直接将发行镜像推送到本地 registry。

如果受限网络中有多个集群,请将所需的发行镜像镜像到单个容器镜像 registry,并使用该 registry 更新所有集群。

9.1. 先决条件

  • 可以访问互联网来获取所需的容器镜像。
  • 具有对 restricted-network 环境中的容器 registry 的写入权限,以便推送和拉取镜像。容器 registry 必须与 Docker registry API v2 兼容。
  • 您必须安装了 oc 命令行界面(CLI)工具。
  • 使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义和应用权限
  • 具有最新的 etcd 备份,以防因为升级失败需要将集群恢复到以前的状态
  • 确保所有机器配置池 (MCP) 都正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行 canary rollout 更新策略,可以暂停 MCP。
  • 如果您的集群使用手动维护的凭证,请确保 Cloud Credential Operator(CCO)处于可升级状态。如需更多信息,请参阅为 AWSAzureGCP 手动维护凭证升级集群
重要

如果您使用附加的 Prometheus PVC 运行集群监控,在集群升级过程中可能会出现 OOM 终止的情况。当 Prometheus 使用持久性存储时,Prometheus 内存在升级过程中会加倍,并在升级完成后的几小时内仍会是这个情况。为了避免 OOM 终止问题,允许升级前有双倍可用内存的 worker 节点。例如,如果您在最低推荐节点上运行监控(2 个内核,8 GB RAM),将内存增加到 16 GB。如需更多信息,请参阅 BZ#1925061

9.2. 准备您的镜像主机

执行镜像步骤前,必须准备主机以检索内容并将其推送到远程位置。

9.2.1. 通过下载二进制文件安装 OpenShift CLI

您可以安装 OpenShift CLI(oc)来使用命令行界面与 OpenShift Container Platform 进行交互。您可以在 Linux、Windows 或 macOS 上安装 oc

重要

如果安装了旧版本的 oc,则无法使用 OpenShift Container Platform 4.7 中的所有命令。下载并安装新版本的 oc。如果您要在受限网络中升级集群,安装计划升级到的 oc 版本。

9.2.1.1. 在 Linux 上安装 OpenShift CLI

您可以按照以下流程在 Linux 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 导航到红帽客户门户网站上的 OpenShift Container Platform 下载页面
  2. Version 下拉菜单中选择相应的版本。
  3. 单击 OpenShift v4.7 Linux 客户端条目旁边的 Download Now,再保存文件。
  4. 解包存档:

    $ tar xvzf <file>
  5. oc 二进制文件放到 PATH 中的目录中

    要查看您的 PATH,请执行以下命令:

    $ echo $PATH

安装 OpenShift CLI 后,可以使用 oc 命令:

$ oc <command>

9.2.1.2. 在 Windows 上安装 OpenShift CLI

您可以按照以下流程在 Windows 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 导航到红帽客户门户网站上的 OpenShift Container Platform 下载页面
  2. Version 下拉菜单中选择相应的版本。
  3. 单击 OpenShift v4.7 Windows 客户端条目旁边的 Download Now,再保存文件。
  4. 使用 ZIP 程序解压存档。
  5. oc 二进制文件移到 PATH 中的目录中

    要查看您的 PATH,请打开命令提示并执行以下命令:

    C:\> path

安装 OpenShift CLI 后,可以使用 oc 命令:

C:\> oc <command>

9.2.1.3. 在 macOS 上安装 OpenShift CLI

您可以按照以下流程在 macOS 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 导航到红帽客户门户网站上的 OpenShift Container Platform 下载页面
  2. Version 下拉菜单中选择相应的版本。
  3. 单击 OpenShift v4.7 MacOSX 客户端条目旁边的 Download Now,再保存文件。
  4. 解包和解压存档。
  5. oc 二进制文件移到 PATH 的目录中。

    要查看您的 PATH,请打开终端并执行以下命令:

    $ echo $PATH

安装 OpenShift CLI 后,可以使用 oc 命令:

$ oc <command>

9.3. 配置允许对容器镜像进行镜像的凭证

创建容器镜像 registry 凭证文件,允许将红帽的镜像镜像到您的镜像环境中。

警告

安装集群时不要使用此镜像 registry 凭据文件作为 pull secret。如果在安装集群时提供此文件,集群中的所有机器都将具有镜像 registry 的写入权限。

警告

此过程需要您可以对镜像 registry 上的容器镜像 registry 进行写操作,并将凭证添加到 registry pull secret。

先决条件

  • 配置了一个镜像(mirror) registry 在受限网络中使用。
  • 您在镜像 registry 中标识了镜像仓库的位置,以将容器镜像镜像(mirror)到这个位置。
  • 您置备了一个镜像 registry 帐户,允许将镜像上传到该镜像仓库。

流程

在安装主机上完成以下步骤:

  1. 从 Red Hat OpenShift Cluster Manager 下载 registry.redhat.io 的 pull secret,并将它保存到 .json 文件中。
  2. 为您的镜像 registry 生成 base64 编码的用户名和密码或令牌:

    $ echo -n '<user_name>:<password>' | base64 -w0 1
    BGVtbYk3ZHAtqXs=
    1
    通过 <user_name><password> 指定 registry 的用户名和密码。
  3. 以 JSON 格式创建您的 pull secret 副本:

    $ cat ./pull-secret.text | jq .  > <path>/<pull_secret_file_in_json>1
    1
    指定到存储 pull secret 的文件夹的路径,以及您创建的 JSON 文件的名称。
  4. 将文件保存为 ~/.docker/config.json$XDG_RUNTIME_DIR/containers/auth.json

    该文件类似于以下示例:

    {
      "auths": {
        "cloud.openshift.com": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "quay.io": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "registry.connect.redhat.com": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        },
        "registry.redhat.io": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        }
      }
    }
  5. 编辑新文件并添加描述 registry 的部分:

      "auths": {
        "<mirror_registry>": { 1
          "auth": "<credentials>", 2
          "email": "you@example.com"
      },
    1
    对于 <mirror_registry>,指定 registry 域名,以及您的镜像 registry 用来提供内容的可选端口。例如: registry.example.comregistry.example.com:8443
    2
    使用 <credentials> 为您的镜像 registry 指定 base64 编码的用户名和密码。

    该文件类似于以下示例:

    {
      "auths": {
        "registry.example.com": {
          "auth": "BGVtbYk3ZHAtqXs=",
          "email": "you@example.com"
        },
        "cloud.openshift.com": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "quay.io": {
          "auth": "b3BlbnNo...",
          "email": "you@example.com"
        },
        "registry.connect.redhat.com": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        },
        "registry.redhat.io": {
          "auth": "NTE3Njg5Nj...",
          "email": "you@example.com"
        }
      }
    }

9.4. 镜像 OpenShift Container Platform 镜像存储库

在受限网络中置备的基础架构上升级集群前,您必须将所需的容器镜像镜像(mirror)到那个环境中。您也可以在不受限制的网络中使用此流程来确保集群只使用满足您机构对外部内容控制的容器镜像。

流程

  1. 使用 Red Hat OpenShift Container Platform Upgrade Graph visualizer 和 update planner 计划从一个版本升级到另一个版本。OpenShift Upgrade Graph 提供频道图形,并演示了如何确认您的当前和预定集群版本之间有更新路径。
  2. 设置所需的环境变量:

    1. 导出发行版本信息:

      $ export OCP_RELEASE=<release_version>

      对于 <release_version>,请指定与升级到的 OpenShift Container Platform 版本对应的标签,如 4.5.4

    2. 导出本地 registry 名称和主机端口:

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      对于 <local_registry_host_name>,请指定镜像存储库的 registry 域名;对于 <local_registry_host_port>,请指定用于提供内容的端口。

    3. 导出本地存储库名称:

      $ LOCAL_REPOSITORY='<local_repository_name>'

      对于 <local_repository_name>,请指定要在 registry 中创建的仓库名称,如 ocp4/openshift4

    4. 导出要进行镜像的存储库名称:

      $ PRODUCT_REPO='openshift-release-dev'

      对于生产环境版本,必须指定 openshift-release-dev

    5. 导出 registry pull secret 的路径:

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      对于 <path_to_pull_secret>,请指定您创建的镜像 registry 的 pull secret 的绝对路径和文件名。

      注意

      如果您的集群使用 ImageContentSourcePolicy 对象来配置存储库镜像,则只能将全局 pull secret 用于镜像 registry。您不能在项目中添加 pull secret。

    6. 导出发行版本镜像:

      $ RELEASE_NAME="ocp-release"

      对于生产环境版本,您必须指定 ocp-release

    7. 为您的服务器导出构架类型,如 x86_64

      $ ARCHITECTURE=<server_architecture>
    8. 导出托管镜像的目录的路径:

      $ REMOVABLE_MEDIA_PATH=<path> 1
      1
      指定完整路径,包括开始的前斜杠(/)字符。
  3. 查看要镜像的镜像和配置清单:

    $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
  4. 将版本镜像镜像(mirror)到镜像 registry。

    • 如果您的镜像主机无法访问互联网,请执行以下操作:

      1. 将可移动介质连接到连接到互联网的系统。
      2. 将镜像和配置清单镜像到可移动介质的目录中:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
      3. 将介质上传到受限网络环境中,并将镜像上传到本地容器 registry。

        $ oc image mirror  -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1
        1
        对于 REMOVABLE_MEDIA_PATH,您必须使用与镜像镜像时指定的同一路径。
      4. 使用 oc 命令行界面(CLI)登录到您要升级的集群。
      5. 将镜像发行镜像签名配置映射应用到连接的集群:

        $ oc apply -f ${REMOVABLE_MEDIA_PATH}/mirror/config/<image_signature_file> 1
        1
        对于 <image_signature_file>,指定文件的路径和名称,例如 signature-sha256-81154f5c03294534.yaml
    • 如果本地容器 registry 和集群连接到镜像主机,将发行镜像直接推送到本地 registry,并使用以下命令将配置映射应用到集群:

      $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
        --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} --apply-release-image-signature
      注意

      如果包含 --apply-release-image-signature 选项,不要为镜像签名验证创建配置映射。

9.5. 创建镜像签名配置映射

在更新集群前,需要手动创建包含您使用的发行版本镜像签名的配置映射。此签名允许 Cluster Version Operator(CVO)通过比较预期的及实际镜像签名来验证发行的镜像没有被修改。

如果要从 4.4.8 或更高版本升级,您可以使用 oc CLI 创建配置映射。如果您是从更早的版本升级,则必须使用手动方法。

9.5.1. 手动创建镜像签名配置映射

创建并应用镜像签名配置映射到您要更新的集群。

注意

每次更新集群时都必须执行以下步骤。

流程

  1. 请参阅 OpenShift Container Platform 升级路径 知识库文章,以确定集群的有效升级路径。
  2. 将版本添加到 OCP_RELEASE_NUMBER 环境变量中:

    $ OCP_RELEASE_NUMBER=<release_version> 1
    1
    对于 <release_version>,请指定与集群升级到的 OpenShift Container Platform 版本对应的标签,如 4.4.0
  3. 将集群的系统构架添加到 ARCHITECTURE 环境变量中:

    $ ARCHITECTURE=<server_architecture> 1
    1
    对于 server_architecture,指定服务器的构架,如 x86_64
  4. Quay 获取发行版本镜像摘要:

    $ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
  5. 设置摘要算法:

    $ DIGEST_ALGO="${DIGEST%%:*}"
  6. 设置摘要签名:

    $ DIGEST_ENCODED="${DIGEST#*:}"
  7. mirror.openshift.com 网站获取镜像签名。

    $ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
  8. 创建配置映射:

    $ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: release-image-${OCP_RELEASE_NUMBER}
      namespace: openshift-config-managed
      labels:
        release.openshift.io/verification-signatures: ""
    binaryData:
      ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64}
    EOF
  9. 将配置映射应用到集群以更新:

    $ oc apply -f checksum-${OCP_RELEASE_NUMBER}.yaml

9.6. 升级受限网络集群

将受限网络集群更新至您下载的发行镜像的 OpenShift Container Platform 版本。

注意

如果您有一个本地 OpenShift Update Service,您可以使用连接的 Web 控制台或 CLI 指令来更新,而不是使用此流程。

先决条件

  • 您已将新发行版本的镜像镜像(mirror)到 registry。
  • 您已将发行镜像签名 ConfigMap 在新发行版本中应用到集群。
  • 从镜像签名 ConfigMap 中获取了发行版本的 sha256 sum 值。
  • 安装 OpenShift CLI(oc)版本 4.4.8 或更高版本。

流程

  • 更新集群:

    $ oc adm upgrade --allow-explicit-upgrade --to-image ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}<sha256_sum_value> 1
    1
    <sha256_sum_value> 值是镜像签名 ConfigMap 的 sha256 sum 值,例如 @sha256:81154f5c03294534e1eaf0319BEF7a601134f891689ccede5d705ef659aa8c92

    如果镜像 registry 使用 ImageContentSourcePolicy,可以使用 Canonical registry 名称而非 LOCAL_REGISTRY

    注意

    您只能为具有 ImageContentSourcePolicy 对象的集群配置全局 pull secret。您不能在项目中添加 pull secret。

9.7. 配置镜像 registry 存储库镜像

通过设置容器 registry 存储库镜像,您可以进行以下操作:

  • 配置 OpenShift Container Platform 集群,以便重定向从源镜像 registry 上的存储库拉取(pull)镜像的请求,并通过已镜像 (mirror) 的镜像 registry 上的存储库来解决该请求。
  • 为每个目标存储库识别多个已镜像 (mirror)的存储库,以确保如果一个镜像停止运作,仍可使用其他镜像。

OpenShift Container Platform 中存储库镜像的属性包括:

  • 镜像拉取(pull)可应对 registry 停机的问题
  • 受限网络中的集群可以从关键位置(如 quay.io)拉取镜像,并让位于公司防火墙后的 registry 提供请求的镜像。
  • 发出镜像拉取(pull)请求时尝试特定 registry 顺序,通常最后才会尝试持久性 registry。
  • 您所输入的镜像信息会添加到 OpenShift Container Platform 集群中每个节点上的 /etc/containers/registries.conf 文件中。
  • 当节点从源存储库中请求镜像时,它会依次尝试每个已镜像的存储库,直到找到所请求的内容。如果所有镜像均失败,集群则会尝试源存储库。如果成功,则镜像拉取至节点中。

可通过以下方式设置存储库镜像:

  • 在 OpenShift Container Platform 安装中:

    通过拉取(pull) OpenShift Container Platform 所需的容器镜像,然后将这些镜像放至公司防火墙后,即可将 OpenShift Container Platform 安装到受限网络中的数据中心。

  • 安装 OpenShift Container Platform 后:

    即使没有在 OpenShift Container Platform 安装期间配置镜像 (mirror),之后您仍可使用 ImageContentSourcePolicy 对象进行配置。

以下流程提供安装后镜像配置,您可在此处创建 ImageContentSourcePolicy 对象来识别:

  • 您希望镜像 (mirror) 的容器镜像存储库的源
  • 您希望为其提供从源存储库请求的内容的每个镜像存储库的单独条目。
注意

您只能为具有 ImageContentSourcePolicy 对象的集群配置全局 pull secret。您不能在项目中添加 pull secret。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 通过以下方法配置已镜像的存储库:

    • 按照 Red Hat Quay 存储库镜像中所述,使用 Red Hat Quay 来设置已镜像的存储库。使用 Red Hat Quay 有助于您将镜像从一个存储库复制到另一存储库,并可随着时间的推移重复自动同步这些存储库。
    • 使用 skopeo 等工具手动将镜像从源目录复制到已镜像的存储库。

      例如:在 Red Hat Enterprise Linux(RHEL 7 或 RHEL 8)系统上安装 skopeo RPM 软件包后,使用 skopeo 命令,如下例所示:

      $ skopeo copy \
      docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
      docker://example.io/example/ubi-minimal

      在本例中,您有一个名为 example.io 的容器镜像 registry,其中包含一个名为 example 的镜像存储库,您希望将 ubi8/ubi-minimal 镜像从 registry.access.redhat.com 复制到此镜像存储库。创建该 registry 后,您可将 OpenShift Container Platform 集群配置为将源存储库的请求重定向到已镜像的存储库。

  2. 登录您的 OpenShift Container Platform 集群。
  3. 创建 ImageContentSourcePolicy 文件(如:registryrepomirror.yaml),将源和镜像 (mirror) 替换为您自己的 registry、存储库对和镜像中的源和镜像:

    apiVersion: operator.openshift.io/v1alpha1
    kind: ImageContentSourcePolicy
    metadata:
      name: ubi8repo
    spec:
      repositoryDigestMirrors:
      - mirrors:
        - example.io/example/ubi-minimal 1
        source: registry.access.redhat.com/ubi8/ubi-minimal 2
      - mirrors:
        - example.com/example/ubi-minimal
        source: registry.access.redhat.com/ubi8/ubi-minimal
      - mirrors:
        - mirror.example.com/redhat
        source: registry.redhat.io/openshift4 3
    1
    指明镜像 registry 和存储库的名称。
    2
    指明包含所镜像内容的 registry 和存储库。
    3
    您可以在 registry 中配置命名空间以使用该命名空间中的任何镜像。如果您使用 registry 域作为源,ImageContentSourcePolicy 资源将应用到 registry 中的所有存储库。
  4. 创建新的 ImageContentSourcePolicy 对象:

    $ oc create -f registryrepomirror.yaml

    创建 ImageContentSourcePolicy 对象后,新的设置将部署到每个节点,集群开始使用已镜像的存储库来响应源存储库请求。

  5. 要检查是否应用了已镜像的配置设置,在其中一个节点上执行以下内容。

    1. 列出您的节点:

      $ oc get node

      输出示例

      NAME                           STATUS                     ROLES    AGE  VERSION
      ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.20.0
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.20.0
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.20.0
      ip-10-0-147-35.ec2.internal    Ready,SchedulingDisabled   worker   7m   v1.20.0
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.20.0
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.20.0

      您可以发现,在应用更改时每个 worker 节点上的调度都会被禁用。

    2. 启动调试过程以访问节点:

      $ oc debug node/ip-10-0-147-35.ec2.internal

      输出示例

      Starting pod/ip-10-0-147-35ec2internal-debug ...
      To use host binaries, run `chroot /host`

    3. 访问节点的文件:

      sh-4.2# chroot /host
    4. 检查 /etc/containers/registries.conf 文件,确保已完成更改:

      sh-4.2# cat /etc/containers/registries.conf

      输出示例

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      [[registry]]
        location = "registry.access.redhat.com/ubi8/"
        insecure = false
        blocked = false
        mirror-by-digest-only = true
        prefix = ""
      
        [[registry.mirror]]
          location = "example.io/example/ubi8-minimal"
          insecure = false
      
        [[registry.mirror]]
          location = "example.com/example/ubi8-minimal"
          insecure = false

    5. 将镜像摘要从源拉取到节点,并检查是否通过镜像解析。ImageContentSourcePolicy 对象仅支持镜像摘要,不支持镜像标签。

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

存储库镜像故障排除

如果存储库镜像流程未按规定工作,请使用以下有关存储库镜像如何工作的信息协助排查问题。

  • 首个工作镜像用于提供拉取(pull)的镜像。
  • 只有在无其他镜像工作时,才会使用主 registry。
  • 从系统上下文,Insecure 标志用作回退。
  • 最近更改了 /etc/containers/registries.conf 文件的格式。现在它是第 2 版,采用 TOML 格式。

9.8. 镜像镜像目录的范围,以减少集群节点重启的频率

您可以在存储库级别或更广泛的 registry 级别限定镜像目录。一个范围广泛的 ImageContentSourcePolicy 资源可减少节点在响应资源更改时需要重启的次数。

要强化 ImageContentSourcePolicy 资源中镜像目录的范围,请执行以下步骤。

先决条件

  • 安装 OpenShift Container Platform CLI oc
  • 以具有 cluster-admin 权限的用户身份登录。
  • 配置镜像镜像目录,以便在断开连接的集群中使用。

流程

  1. 运行以下命令,为 <local_registry><pull_spec><pull_secret_file> 指定值:

    $ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry

    其中:

    <local_registry>
    您为断开连接的集群配置的本地 registry,如 local.registry:5000
    <pull_spec>
    断开连接的 registry 中配置的拉取规格,如 redhat/redhat-operator-index:v4.7
    <pull_secret_file>
    .json 文件格式的 registry.redhat.io pull secret。您可以从 Red Hat OpenShift Cluster Manager 下载 pull secret

    oc adm catalog mirror 命令创建 /redhat-operator-index-manifests 目录,并生成 imageContentSourcePolicy.yamlcatalogSource.yamlmapping.txt 文件。

  2. 将新的 ImageContentSourcePolicy 资源应用到集群:

    $ oc apply -f imageContentSourcePolicy.yaml

验证

  • 验证 oc apply 是否成功将更改应用到 ImageContentSourcePolicy:

    $ oc get ImageContentSourcePolicy -o yaml

    输出示例

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1alpha1
      kind: ImageContentSourcePolicy
      metadata:
        annotations:
          kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"operator.openshift.io/v1alpha1","kind":"ImageContentSourcePolicy","metadata":{"annotations":{},"name":"redhat-operator-index"},"spec":{"repositoryDigestMirrors":[{"mirrors":["local.registry:5000"],"source":"registry.redhat.io"}]}}
    ...

更新 ImageContentSourcePolicy 资源后,OpenShift Container Platform 会将新设置部署到每个节点,集群开始使用已镜像的存储库向源存储库发出请求。

9.9. 其它资源