流程

1. 在 web 控制台中点 Administration > Cluster Settings，查看 Overview 标签页中的内容。

2. 对于生产环境中的集群，请确保将 CHANNEL 设置为您当前使用的次版本的正确频道，如 stable-4.3。

   重要

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

   • 如果 UPDATE STATUS 的值不是 Updates Available，则不能升级您的集群。
   • DESIRED VERSION显示正在运行的集群版本，或正在更新到的集群版本。
3. 点 Updates Available，选择最高可用版本并点 Update。UPDATE STATUS会变为Updating ，您可以在Cluster Operators页中查看Operator升级的进度。

4. 如果您要从 OpenShift Container Platform 4.2 升级到这个版本，则必须在升级完成后重启所有 Pod。您可以使用以下命令进行此操作，该命令需要 OpenShift CLI（oc）：

   $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
         do oc delete pods --all -n $I; \
         sleep 1; \
         done

   注意

   需要重启所有 Pod，因为服务 CA 会在 OpenShift Container Platform 4.3.5 中自动轮转。升级过程中会轮转服务 CA，之后需要重启服务以确保所有服务在上一个服务 CA 过期前都使用新的服务 CA。

   这个手动重启操作只需要执行一次，后续的升级和轮转将在服务 CA 过期前确保重启，而无需人工干预。

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

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

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

流程

1. 在 web 控制台中点 Administration > Cluster Settings，查看 Overview 标签页中的内容。

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

   重要

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

   • 如果 UPDATE STATUS 的值不是 Updates Available，则不能升级您的集群。
   • DESIRED VERSION显示正在运行的集群版本，或正在更新到的集群版本。
3. 点 Updates Available，选择要更新到的版本，最新可用版本并点 Update。UPDATE STATUS会变为Updating ，您可以在Cluster Operators页中查看Operator升级的进度。

4. 如果您要从 OpenShift Container Platform 4.3.3 或更早版本，或 4.2 升级到这个版本，则必须在升级完成后重启所有 Pod。您可以使用以下命令进行此操作，该命令需要 OpenShift CLI（oc）：

   $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
         do oc delete pods --all -n $I; \
         sleep 1; \
         done

   注意

   需要重启所有 Pod，因为服务 CA 会作为 OpenShift Container Platform 4.3.5 自动轮转。升级过程中会轮转服务 CA，之后需要重启服务以确保所有服务在上一个服务 CA 过期前都使用新的服务 CA。

   这个手动重启操作只需要执行一次，后续的升级和轮转将在服务 CA 过期前确保重启，而无需人工干预。

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

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

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

流程

1. 确认集群可用

   $ oc get clusterversion
   
   NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
   version   4.3.0     True        False         158m    Cluster version is 4.3.0

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

   $ oc get clusterversion -o json|jq ".items[0].spec"
   
   {
     "channel": "stable-4.3",
     "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
     "upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
   }

   重要

   对于生产环境集群，您必须订阅一个 stable-* 频道。

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.3",
     "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
     "desiredUpdate": {
       "force": false,
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
       "version": "4.3.1" 1
     },
     "upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
   }

   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:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
       "startedTime": "2019-06-19T20:30:50Z",
       "state": "Partial",
       "verified": true,
       "version": "4.1.2"
     },
     {
       "completionTime": "2019-06-19T20:30:50Z",
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:b8307ac0f3ec4ac86c3f3b52846425205022da52c16f56ec31cbe428501001d6",
       "startedTime": "2019-06-19T17:38:10Z",
       "state": "Completed",
       "verified": false,
       "version": "4.1.0"
     }
   ]

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

   重要

   如果升级失败，Operator 将停止操作并报告故障组件的状态。当前还不支持将集群还原到以前的版本。如果升级失败，请联系红帽支持。

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

   $ oc get clusterversion
   
   NAME      VERSION     AVAILABLE   PROGRESSING   SINCE     STATUS
   version   4.1.2       True        False         2m        Cluster version is 4.1.2

8. 如果您要从 OpenShift Container Platform 4.3.3 或更早版本升级到这个版本，则必须在升级完成后重启所有 Pod。您可以使用以下命令完成此操作：

   $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
         do oc delete pods --all -n $I; \
         sleep 1; \
         done

   注意

   需要重启所有 Pod，因为服务 CA 会在 OpenShift Container Platform 4.3.5 中自动轮转。升级过程中会轮转服务 CA，之后需要重启服务以确保所有服务在上一个服务 CA 过期前都使用新的服务 CA。

   这个手动重启操作只需要执行一次，后续的升级和轮转将在服务 CA 过期前确保重启，而无需人工干预。

流程

1. 在 web 控制台中点 Administration > Cluster Settings，查看 Overview 标签页中的内容。

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

   重要

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

   • 如果 UPDATE STATUS 的值不是 Updates Available，则不能升级您的集群。
   • DESIRED VERSION显示正在运行的集群版本，或正在更新到的集群版本。
3. 点 Updates Available，选择要更新到的版本，最新可用版本并点 Update。UPDATE STATUS会变为Updating ，您可以在Cluster Operators页中查看Operator升级的进度。

4. 如果您要从 OpenShift Container Platform 4.3.3 或更早版本，或 4.2 升级到这个版本，则必须在升级完成后重启所有 Pod。您可以使用以下命令进行此操作，该命令需要 OpenShift CLI（oc）：

   $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
         do oc delete pods --all -n $I; \
         sleep 1; \
         done

   注意

   需要重启所有 Pod，因为服务 CA 会作为 OpenShift Container Platform 4.3.5 自动轮转。升级过程中会轮转服务 CA，之后需要重启服务以确保所有服务在上一个服务 CA 过期前都使用新的服务 CA。

   这个手动重启操作只需要执行一次，后续的升级和轮转将在服务 CA 过期前确保重启，而无需人工干预。

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

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

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

   注意

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

流程

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

   # systemctl disable --now firewalld.service

   注意

   请不要在以后启用防火墙。如果这样做，则无法访问 worker 上的 OpenShift Container Platform 日志。

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

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

      # subscription-manager repos --disable=rhel-7-server-ansible-2.7-rpms  \
                                   --disable=rhel-7-server-ose-4.2-rpms \
                                   --enable=rhel-7-server-ansible-2.8-rpms \
                                   --enable=rhel-7-server-ose-4.3-rpms

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

      # yum update openshift-ansible openshift-clients

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

      # subscription-manager repos --disable=rhel-7-server-ose-4.2-rpms \
                                   --enable=rhel-7-server-ose-4.3-rpms

3. 更新 RHEL worker 机器：

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

      # oc get node
      NAME                        STATUS                        ROLES    AGE    VERSION
      mycluster-control-plane-0   Ready                         master   145m   v1.16.2
      mycluster-control-plane-1   Ready                         master   145m   v1.16.2
      mycluster-control-plane-2   Ready                         master   145m   v1.16.2
      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目录并运行升级 playbook：

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

      1

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

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

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

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

1. 从 Red Hat OpenShift Cluster Manager 站点的 Pull Secret 页面下载 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>1

   1

   指定到存储 pull secret 的文件夹的路径，以及您创建的 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"
       }
     }
   }

4. 编辑新文件并添加描述 registry 的部分：

     "auths": {
       "<mirror_registry>": { 1
         "auth": "<credentials>", 2
         "email": "you@example.com"
     },

   1

   对于 <mirror_registry>，指定 registry 域名，以及您的镜像 registry 用来提供内容的可选端口。例如： registry.example.com 或 registry.example.com:5000

   2

   使用 <credentials> 为您的镜像 registry 指定 base64 编码的用户名和密码。

   该文件类似于以下示例：

   {
     "auths": {
       "<mirror_registry>": {
         "auth": "<credentials>",
         "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"
       }
     }
   }

1. 编辑新文件并添加描述 registry 的部分：

     "auths": {
   ...
       "<mirror_registry>": { 1
         "auth": "<credentials>", 2
         "email": "you@example.com"
     },
   ...

   1

   对于 <mirror_registry>，指定 registry 域名，以及您的镜像 registry 用来提供内容的可选端口。例如： registry.example.com 或 registry.example.com:5000

   2

   使用 <credentials> 为您的镜像 registry 指定 base64 编码的用户名和密码。

   该文件类似于以下示例：

   {
     "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"
       },
       "<mirror_registry>": {
         "auth": "<credentials>",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

流程

1. 查看 OpenShift Container Platform 升级路径，以确认您的当前和预定集群版本之间有升级路径。

2. 设置所需的环境变量：

   $ OCP_RELEASE=<release_version> 1
   $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>' 2
   $ LOCAL_REPOSITORY='<repository_name>' 3
   $ PRODUCT_REPO='openshift-release-dev' 4
   $ LOCAL_SECRET_JSON='<path_to_pull_secret>' 5
   $ RELEASE_NAME='ocp-release' 6
   $ ARCHITECTURE=<server_architecture> 7
   $ REMOVABLE_MEDIA_PATH=<path> 8

   1

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

   2

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

   3

   对于 <repository_name>，请指定要在 registry 中创建的存储库名称，如 ocp4/openshift4。

   4

   要镜像的存储库。对于生产环境版本，必须指定 openshift-release-dev。

   5

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

   6

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

   7

   对于 <server_architecture>，指定服务器的构架，如 x86_64。

   8

   对于 <path>，指定托管镜像的目录的路径。

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}

   • 如果本地容器 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}

流程

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/ubi8/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-minimal1
       source: registry.access.redhat.com/ubi8/ubi-minimal2
     - mirrors:
       - example.com/example/ubi-minimal
       source: registry.access.redhat.com/ubi8/ubi-minimal

   1

   指明镜像 registry 和存储库的名称

   2

   指明包含所镜像内容的 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.16.2
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.16.2
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.16.2
      ip-10-0-147-35.ec2.internal    Ready,SchedulingDisabled   worker   7m   v1.16.2
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.16.2
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.16.2

      您可以发现，在应用更改时每个 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 文件，确保已完成更改：

      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