美文网首页OpenShift Origin
OpenShift 升级指南

OpenShift 升级指南

作者: 枫之叶_eliu | 来源:发表于2018-04-29 23:29 被阅读86次

概述

openshift-ansible 为 OpenShift Origin 集群提供了方便的升级手册,在主版本之间进行升级绝大部分没有问题。但请注意,从测试版(如 3.7.0-rc.0 -> 3.7.0)或者小版本(3.6.0 -> 3.6.1)升级时会有问题。

OpenShift Origin 版本和 openshift-ansible 分支的对照关系表如下:

Origin/OCP OpenShift-Ansible version openshift-ansible branch
1.3 / 3.3 3.3 release-1.3
1.4 / 3.4 3.4 release-1.4
1.5 / 3.5 3.5 release-1.5
3.X 3.X release-3.x

官方的升级文档请访问 https://docs.openshift.org/latest/install_config/upgrading/index.html

主版本升级

主版本之间除 3.7 到 3.9 版本之间允许跨版本进行升级之外,其他主版本之间不允许跨版升级,具体见如下表格:

版本从 版本至 备注
3.6.x 3.7
3.7.x 3.8 需手工设置 3.8 的 YUM 源
3.7.x 3.9 需手工设置 3.8 的 YUM 源
3.8.x 3.9

通用升级步骤

我们以 3.6 升级至 3.7 为例来说明。

更新版本标识

编辑 ansible 配置文件 /etc/ansible/hosts 并将以下属性并修改为 3.7 版本的相应值。

#openshift_release=3.6
openshift_release=3.7

运行升级手册

ansible-playbook /path/to/openshift-ansible/playbooks/byo/openshift-cluster/upgrades/v3_7/upgrade.yml

⚠︎ 注意

Origin 3.7 版本以后默认会启用 Service Catalog 和 Template Service Broker 这两个组件。以目前国内的网络情况看,他们可能在安装前后都不会正常的工作,因此建议在升级前禁用它们。具体做法就是在 /etc/ansible/hosts 里面加入以下设置:

openshift_enable_service_catalog=false
template_service_broker_install=false

跨版本升级

OpenShift 唯一一次允许跨版本升级是从 3.7.x 升级至 3.9,据官方文档描述,这个升级过程分为两个阶段:

  1. 从 3.7.x 升级到 3.8
  2. 从 3.8 升级到 3.9

全程自动升级,无需手工干预。不过,从笔者的升级实践上看,社区版进行升级时会由于未自动启用 3.8 的 YUM 软件源而升级失败,提示 Package 'origin-3.8*' not found 的错误。因此在升级之前,我们需要手工设置一下 Origin 3.8 的 YUM 软件源。

设置 Origin 3.8 软件源

将文件 CentOS-OpenShift-Origin38.repo 复制到目录 /etc/yum.repos.d/ 下。文件内容如下:

[centos-openshift-origin38]
name=CentOS OpenShift Origin
baseurl=http://mirror.centos.org/centos/7/paas/x86_64/openshift-origin38/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-PaaS

[centos-openshift-origin38-testing]
name=CentOS OpenShift Origin Testing
baseurl=http://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin38/
enabled={{ 1 if openshift_repos_enable_testing else 0 }}
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-PaaS

[centos-openshift-origin38-debuginfo]
name=CentOS OpenShift Origin DebugInfo
baseurl=http://debuginfo.centos.org/centos/7/paas/x86_64/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-PaaS

[centos-openshift-origin38-source]
name=CentOS OpenShift Origin Source
baseurl=http://vault.centos.org/centos/7/paas/Source/openshift-origin38/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-PaaS

更新版本标识

编辑 ansible 配置文件 /etc/ansible/hosts 并将以下属性并修改为 3.7 版本的相应值。

openshift_release=3.9

运行升级手册

# 切换至 3.9 分支
cd /path/to/openshift-ansible
git checkout release-3.9
# 运行升级手册
ansible-playbook playbooks/byo/openshift-cluster/upgrades/v3_9/upgrade.yml

小版本升级

小版本升级一般不需要变更 Ansible 的 hosts 文件,除非读者在之前的安装时强制指定了 openshift_image_tag 或者 openshift_pkg_version 这两个变量,那么您可能需要手工指定两个版本值或者直接去掉它们。

升级时读者仅需要找到当前主版本对应的升级手册运行即可。我们以 3.7 为例,最开始安装的时候,ansible 自动找到了明细的版本为 3.7.0,后面社区推出了小版本升级包 3.7.1,这时读者仅需要运行 3.7 对应的升级手册即可:

ansible-playbook /path/to/openshift-ansible/playbooks/byo/openshift-cluster/upgrades/v3_7/upgrade.yml

相关文章

网友评论

  • NotFoundW:3.7到3.9直接升级的话,如果在3.7的时候,infra节点上有自己创建的pod存在,比如一个busybox,那么升级过程中这个pod是无法从infra节点drain到其他节点的,升级完之后,这个pod就会一直处于pending状态,调度器找不到合适的节点部署这个pod。也就是说之前在infra节点的那个pod被杀掉后,新的pod是起不来的。3.9版本会给这个新的pod加上一个默认的nodeselector,就是node-role.kubernetes.io/compute=true,而同时这个pod也保留了之前的一个nodeselector,就是region=infra。在3.9版本中,默认情况下是没有node同时存在这两个label的。

本文标题:OpenShift 升级指南

本文链接:https://www.haomeiwen.com/subject/bigalftx.html