DO280管理和监控OpenShift平台--OCP升级

个人简介：大家好，我是 金鱼哥，CSDN运维领域新星创作者，华为云·云享专家，阿里云社区·专家博主
个人资质：CCNA、HCNP、CSNA（网络分析师），软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL
格言：努力不一定成功，但要想成功就必须努力

支持我：可点赞、可收藏⭐️、可留言

升级OPENSHIFT

当OCP的新版本发布时，可以升级现有集群，以应用最新的增强功能和bug修复。这包括从以前的次要版本(如从3.7升级到3.9)升级，以及对次要版本(3.7)应用更新。

提示：OCP 3.9包含了Kubernetes 1.8和1.9的特性和补丁的合并。由于主要版本之间的核心架构变化，OpenShift Enterprise 2环境无法升级为OpenShift容器平台3，必须需要重新安装。

通常，主版本中不同子版本的node是向前和向后兼容的。但是，运行不匹配的版本的时间不应超过升级整个集群所需的时间。此外，不支持使用quick installer将版本3.7升级到3.9。

---

升级方式

有两种方法可以执行OpenShift容器平台集群升级，一种为in-place升级(可以自动升级或手动升级)，也可以使用blue-green部署方法进行升级。

in-place升级：使用此方式，集群升级将在单个运行的集群中的所有主机上执行。首先升级master，然后升级node。在node升级开始之前，Pods被迁移到集群中的其他节点。这有助于减少用户应用程序的停机时间。

注意：对于使用quick和高级安装方法安装的集群，可以使用自动in-place方式升级。

当使用高级安装方法安装集群时，您可以通过重用它们的库存文件执行自动化或手动就地升级。

blue-green部署：blue-green部署是一种旨在减少停机时间同时升级环境的方法。在blue-green部署中，相同的环境与一个活动环境一起运行，而另一个环境则被更新。OpenShift升级方法标记了不可调度节点，并将pod调度到可用节点。升级成功后，节点将恢复到可调度状态。

---

执行自动化集群升级

使用高级安装方法，可以使用Ansible playbook自动化执行OpenShift集群升级过程。用于升级的剧本位于/usr/share/ansible/openshift-ansible/Playbooks/common/openshift-cluster/updates/中。该目录包含一组用于升级集群的子目录，例如v3_9。

注意：将集群升级到 OCP 3.9 前，集群必须已经升级到 3.7。集群升级一次不能跨越一个以上的次要版本，因此，如果集群的版本早于3.6，则必须先渐进地升级，例如从3.5升级到3.6，然后从3.6升级到3.7

要执行升级，可以使用ansible-playbook命令运行升级剧本，如使用v3_9 playbook将运行3.7版本的现有OpenShift集群升级到3.9版本。

---

自动升级主要执行以下任务:

• 应用最新的配置更改；
• 保存Etcd数据；
• 将api从3.7更新到3.8，然后从3.8更新到3.9；
• 如果存在，将默认路由器从3.7更新到3.9；
• 如果存在，则将默认仓库从3.7更新到3.9；
• 更新默认is和Templates。

注意：在继续升级之前，确保已经满足了所有先决条件，否则可能导致升级失败。

---

如果使用容器化的GlusterFS，节点将不会从pod中撤离，因为GlusterFS pod作为daemonset的一部分运行。要正确地升级运行容器化GlusterFS的集群，需要:

1：升级master服务器、Etcd和基础设施服务(route、内部仓库、日志记录和metric)。

2：升级运行应用程序容器的节点。

3：一次升级一个运行GlusterFS的节点。

注意：在升级之前，使用oc adm diagnostics命令验证集群的健康状况。这确认节点处于ready状态，运行预期的启动版本，并且没有诊断错误或警告。对于离线安装，使用–network-pod-image='REGISTRY URL/ IMAGE参数指定要使用的image。

---

准备自动升级

下面的过程展示了如何为自动升级准备环境，在执行升级之前，Red Hat建议检查配置Inventory文件，以确保对Inventory文件进行了手动更新。如果配置没有修改，则使用默认值覆盖更改。

1. 如果这是从OCP 3.7升级到3.9，手动禁用3.7存储库，并在每个master节点和node节点上启用3.8和3.9存储库：

[root@demo ~]# subscription-manager repos \
--disable="rhel-7-server-ose-3.7-rpms" \
--enable="rhel-7-server-ose-3.9-rpms" \
--enable="rhel-7-server-ose-3.8-rpms" \
--enable="rhel-7-server-rpms" \
--enable="rhel-7-server-extras-rpms" \
--enable="rhel-7-server-ansible-2.4-rpms" \
--enable="rhel-7-fast-datapath-rpms"
[root@demo ~]# yum clean all

2. 确保在每个RHEL 7系统上都有最新版本的atom-openshift-utils包，它还更新openshift-ansible-*包。

[root@demo ~]# yum update atomic-openshift-utils

3. 在OpenShift容器平台的以前版本中，安装程序默认将master节点标记为不可调度，但是，从OCP 3.9开始，master节点必须标记为可调度的，这是在升级过程中自动完成的。

如果没有设置默认的节点选择器(如下配置)，它们将在升级过程中添加。则master节点也将被标记为master节点角色。所有其他节点都将标记为compute node角色。

openshift_node_labels="{'region':'infra', 'node-role.kubernetes.io/compute':'true'}

4. 如果将openshift_disable_swap=false变量添加到的Ansible目录中，或者在node上手动配置swap，那么在运行升级之前禁用swap内存。

---

升级master节点和node节点

在满足了先决条件(如准备工作)之后，则可以按照如下步骤进行升级：

1. 在清单文件中设置openshift_deployment_type=openshift-enterprise变量。

2. 如果使用自定义Docker仓库，则必须显式地将仓库的地址指定为openshift_web_console_prefix和template_service_broker_prefix变量。这些值由Ansible在升级过程中使用。

  openshift_web_console_prefix=registry.demo.example.com/openshift3/ose-
  template_service_broker_prefix=registry.demo.example.com/openshift3/ose-

3. 如果希望重启service或重启node，请在Inventory文件中设置openshift_rolling_restart_mode=system选项。如果未设置该选项，则默认值表明升级过程在master节点上执行service重启，但不重启系统。

4. 可以通过运行一个Ansible Playbook (upgrade.yml)来更新环境中的所有节点，也可以通过使用单独的Playbook分多个阶段进行升级。

5. 重新启动所有主机，重启之后，如果没有部署任何额外的功能，可以验证升级。

---

分阶段升级集群

如果决定分多个阶段升级环境，根据Ansible Playbook (upgrade_control_plan .yml)确定的第一个阶段，升级以下组件:

1. master节点；

2. 运行master节点的节点services；

3. Docker服务位于master节点和任何独立Etcd主机上。

---

第二阶段由upgrade_nodes.yml playbook，升级了以下组件。在运行此第二阶段之前，必须已经升级了master节点。

1. node节点的服务；

2. 运行在独立节点上的Docker服务。

---

两个阶段的升级过程允许通过指定自定义变量自定义升级的运行方式。例如，要升级总节点的50%，可以运行以下命令:

[root@demo ~]# ansible-playbook \
/usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
v3_9/upgrade_nodes.yml \
-e openshift_upgrade_nodes_serial="50%"

若要在HA region一次升级两个节点，请运行以下命令：

[root@demo ~]# ansible-playbook \
/usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
v3_9/upgrade_nodes.yml \
-e openshift_upgrade_nodes_serial="2"
-e openshift_upgrade_nodes_label="region=HA"

要指定每个更新批处理中允许有多少节点失败，可使用openshift_upgrade_nodes_max_fail_percent选项。当故障百分比超过定义的值时，Ansible将中止升级。

使用openshift_upgrade_nodes_drain_timeout选项指定中止play前等待的时间。

示例：如下所示一次升级10个节点，以及如果20%以上的节点(两个节点)失败，以及终止play执行的等待时间。

[root@demo ~]# ansible-playbook \
/usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
v3_9/upgrade_nodes.yml \
-e openshift_upgrade_nodes_serial=10 \
-e openshift_upgrade_nodes_max_fail_percentage=20 \
-e openshift_upgrade_nodes_drain_timeout=600

---

使用Ansible Hooks

可以通过hook为特定的操作执行定制的任务。hook允许通过定义在升级过程中特定点之前或之后执行的任务来扩展升级过程的默认行为。例如，可以在升级集群时验证或更新自定义基础设施组件。

提示：hook没有任何错误处理机制，因此，hook中的任何错误都会中断升级过程。需要修复hook并重新运行升级过程。

使用Inventory文件的[OSEv3:vars]部分来定义hook。每个hook必须指向一个.yaml文件，该文件定义了可能的任务。该文件是作为include语句的一部分集成的，该语句要求定义一组任务，而不是一个剧本。Red Hat建议使用绝对路径来避免任何歧义。

---

以下hook可用于定制升级过程：

1. openshift_master_upgrade_pre_hook：hook在更新每个master节点之前运行。

2. openshift_master_upgrade_hook：hook在每个master节点升级之后、主服务或节点重新启动之前运行。

3. openshift_master_upgrade_post_hook：hook在每个master节点升级并重启服务或系统之后运行。

---

示例：在库存文件中集成一个钩子。

[OSEv3:vars]
openshift_master_upgrade_pre_hook=/usr/share/custom/pre_master.yml
openshift_master_upgrade_hook=/usr/share/custom/master.yml
openshift_master_upgrade_post_hook=/usr/share/custom/post_master.yml

如上示例，引入了一个pre_master.yml，包括了以下任务：

---
- name: note the start of a master upgrade
  debug:
    msg: "Master upgrade of {{ inventory_hostname }} is about to start"

- name: require an operator agree to start an upgrade pause:
  prompt: "Hit enter to start the master upgrade"

---

验证升级

升级完成后，应该执行以下步骤以确保升级成功。

[root@demo ~]# oc get nodes		    #验证node处于ready
[root@demo ~]# oc get -n default dc/docker-registry -o json | grep \"image\"  #验证仓库版本
[root@demo ~]# oc get -n default dc/router -o json | grep \"image\"          #验证image版本
[root@demo ~]# oc adm diagnostics	   #使用诊断工具

---

升级步骤汇总

1. 确保在每个RHEL 7系统上都有atom-openshift-utils包的最新版本。

2. 如果使用自定义Docker仓库，可以选择将仓库的地址指定为openshift_web_console_prefix和template_service_broker_prefix变量。

3. 禁用所有节点上的swap。

4. 重新启动所有主机，重启之后，检查升级。

5. 可选地：检查Inventory文件中的节点选择器。

6. 禁用3.7存储库，并在每个master主机和node节点主机上启用3.8和3.9存储库。

7. 通过使用合适的Ansible剧本集，使用单个或多个阶段策略进行更新。

8. 在清单文件中设置openshift_deployment_type=openshift-enterprise变量。

---

总结

RHCA认证需要经历5门的学习与考试，还是需要花不少时间去学习与备考的，好好加油，可以噶。

以上就是【金鱼哥】对 第九章 管理和监控OpenShift平台–OCP升级 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。

红帽认证专栏系列：
RHCSA专栏：戏说 RHCSA 认证
RHCE专栏：戏说 RHCE 认证
此文章收录在RHCA专栏：RHCA 回忆录

如果这篇【文章】有帮助到你，希望可以给【金鱼哥】点个赞，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。

如果有对【运维技术】感兴趣，也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】！