OpenShift跨版本升级

官方的in-place upgrade直接在线升级,但问题是只能一个一个版本的升无法做到跨版本升级,如果一次跨越多个版本,并且集群规模比较大的化,就需要花费很长的时间了。

实际生产过程中因为是分布式环境,所以机器量一般都比较大,官方升级模式有一个好处就是始终能够对外提供服务。

问题是连续升级的时间消耗比较长,而且容易出问题。而这篇文章的方法是,直接安装新的集群模式,同时将原有的旧节点覆盖成新的版本。

1.原有集群备份

基于每个project备份

  • 先列一下有啥东西
[[email protected] ~]# oc get all -n myproject
NAME        DOCKER REPO                                         TAGS      UPDATED
is/tomcat   docker-registry.default.svc:5000/myproject/tomcat   8-slim    4 minutes ago

NAME        REVISION   DESIRED   CURRENT   TRIGGERED BY
dc/tomcat   1          1         1         config,image(tomcat:8-slim)

NAME          DESIRED   CURRENT   READY     AGE
rc/tomcat-1   1         1         1         3m

NAME            HOST/PORT                          PATH      SERVICES   PORT       TERMINATION   WILDCARD
routes/tomcat   tomcat-myproject.app.example.com             tomcat     8080-tcp                 None

NAME         CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
svc/tomcat   172.30.66.175   <none>        8080/TCP   3m

NAME                READY     STATUS    RESTARTS   AGE
po/tomcat-1-6c3s0   1/1       Running   0          3m
  • 备份所有项目对象
[[email protected] ~]# oc get -o yaml --export all > project.yaml
[[email protected] ~]# ls
anaconda-ks.cfg  project.yaml  tomcat.tar
  • 备份serviceaccount,secrets,pvc等等信息
[[email protected] ~]# for object in rolebindings serviceaccounts secrets imagestreamtags podpreset cms egressnetworkpolicies rolebindingrestrictions limitranges resourcequotas pvcs templates cronjobs statefulsets hpas deployments replicasets poddisruptionbudget endpoints
> do
>   oc get -o yaml --export $object > $object.yaml
> done
the server doesn‘t have a resource type "cms"
the server doesn‘t have a resource type "pvcs"
the server doesn‘t have a resource type "hpas"
[[email protected] ~]# ls
anaconda-ks.cfg   egressnetworkpolicies.yaml  limitranges.yaml          pvcs.yaml                     rolebindings.yaml     templates.yaml
cms.yaml          endpoints.yaml              poddisruptionbudget.yaml  replicasets.yaml              secrets.yaml          tomcat.tar
cronjobs.yaml     hpas.yaml                   podpreset.yaml            resourcequotas.yaml           serviceaccounts.yaml
deployments.yaml  imagestreamtags.yaml        project.yaml              rolebindingrestrictions.yaml  statefulsets.yaml

2.新版本集群安装

比如3.11, 加入一个fresh机器作为新的master节点

原有节点需要完成的工作包括:

  • 删除节点配置信息

在原来的node1.example.com, node2.example.com中进行如下操作,如果不删除配置将无法产生csr的请求

rm -rf /etc/origin/node/*
vi /etc/origin/node/resolv.conf

# nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh
# Generated by NetworkManager
search cluster.local example.com
nameserver 192.168.56.113
  • 更新/etc/hosts文件指到新的master.example.com的地址
192.168.56.113    master.example.com
192.168.56.104    node1.example.com
192.168.56.105    node2.example.com
192.168.56.115    node3.example.com
192.168.56.115    registry.example.com

地址里面,node1,node2是3.6的版本,而node3是新节点。

  • 修改ocp.repo指到新的yum源
  • 建立节点互信
ssh-copy-id [email protected]
ssh-copy-id [email protected]

master配置

master.example.com中的/etc/ansible/hosts文件

[[email protected] ~]# cat /etc/ansible/hosts
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
# SSH user, this user should allow ssh based auth without requiring a password
ansible_ssh_user=root

# If ansible_ssh_user is not root, ansible_become must be set to true
#ansible_become=true

openshift_deployment_type=openshift-enterprise
openshift_image_tag=v3.11.16
openshift_pkg_version=-3.11.16

openshift_master_default_subdomain=apps.example.com
openshift_docker_options="--selinux-enabled --insecure-registry 172.30.0.0/16 --log-driver json-file --log-opt max-size=50M --log-opt max-file=3 --insecure-registry registry.example.com --add-registry registry.example.com"

oreg_url=registry.example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

openshift_metrics_install_metrics=true
openshift_logging_install_logging=false
openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_enable_service_catalog=false
ansible_service_broker_install=false

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
openshift_master_identity_providers=[{‘name‘: ‘htpasswd_auth‘, ‘login‘: ‘true‘, ‘challenge‘: ‘true‘, ‘kind‘: ‘HTPasswdPasswordIdentityProvider‘}]

openshift_disable_check="disk_availability,docker_image_availability,memory_availability,docker_storage,package_version"

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
master.example.com

# host group for nodes, includes region info
[nodes]
master.example.com openshift_node_group_name=‘node-config-master‘
node1.example.com openshift_node_group_name=‘node-config-infra‘
node2.example.com openshift_node_group_name=‘node-config-compute‘
node3.example.com openshift_node_group_name=‘node-config-compute‘

资源问题,不安装log,service catalog什么的了。

运行部署

ansible-playbook -vv /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml

验证安装

[[email protected] openshift-ansible]# oc get nodes
NAME                 STATUS    ROLES     AGE       VERSION
master.example.com   Ready     master    44m       v1.11.0+d4cacc0
node1.example.com    Ready     infra     40m       v1.11.0+d4cacc0
node2.example.com    Ready     compute   40m       v1.11.0+d4cacc0
node3.example.com    Ready     compute   40m       v1.11.0+d4cacc0

3.项目恢复

$ oc new-project <projectname>

导入镜像(如果镜像仓库没修改就不用了)

$ oc create -f project.yaml
$ oc create -f secret.yaml
$ oc create -f serviceaccount.yaml
$ oc create -f pvc.yaml
$ oc create -f rolebindings.yaml

备份和恢复参考

https://docs.openshift.com/container-platform/3.11/day_two_guide/project_level_tasks.html

原文地址:https://www.cnblogs.com/ericnie/p/10193480.html

时间: 2024-10-08 01:25:30

OpenShift跨版本升级的相关文章

总结Fedora 22跨版本升级到Fedora 24方法

(总结)Fedora 22跨版本升级到Fedora 24方法   最近测试一套比较新的开源ERP,对系统软件版本要求很新,CentOS7也没这么新的开发包,也不喜欢编译安装(洁癖).想起了Fedora来,之前有台测试机Fedora22,就想把它更新到最新的Fedora24.该版本glibc 更新到2.23,GCC编译器更新到6.1了,够新!折腾了下,跨版本升级成功.注意:此操作只合适开发和测试环境,不能在生产环境这样折腾.Fedora是新技术试验场,不合适用于生产环境的. 一.使用 DNF 插件

Debian跨版本升级

相对于某些重量级linux发行版而言,同样是通过网络跨版本升级,Debian的升级过程总要显得轻快很多.不会因为要下载数量惊人的软件包并安装而把升级时间拉得很长,也不用担心中途某些程序崩溃退出导致升级失败系统损坏,只需备份重要文件就可以开始了.整个过程不会超过3条命令,顺利完成后新系统即可直接投入使用.网络跨版本升级也是官方推荐的升级方法,大家可以放心试水. 首先把当前系统的软件升级到最新. $ sudo aptitude update && sudo aptitude upgrade 然

ORACLE跨版本升级

跨版本升级(10.2.0.5升级到11.2.0.3)10.2.0.5版本:ORACLE_BASE: /oracle/u01/app/oracleORACLE_HOME: /oracle/u01/app/oracle/product/10.2/db_111.2.0.3版本:ORACLE_BASE: /oracle/u02/app/oracleORACLE_HOME: /oracle/u02/app/oracle/product/10.2/db_1 描述:新装11g的软件,用新的软件来挂原来10g的

Android SQLite数据库版本升级原理解析

Android使用SQLite数据库保存数据,那数据库版本升级是怎么回事呢,这里说一下. 一.软件v1.0 安装v1.0,假设v1.0版本只有一个account表,这时走继承SQLiteOpenHelper的onCreate,不走onUpgrade. 1.v1.0(直接安装v1.0) 二.软件v2.0 有2种安装软件情况: 1.v1.0   -->  v2.0              不走onCreate,走onUpgrade 2.v2.0(直接安装v2.0)          走onCrea

SQLite数据库版本升级的管理实现

我们知道在SQLiteOpenHelper的构造方法: super(Context context, String name, SQLiteDatabase.CursorFactory factory, int version) 中最后一个参数表示数据库的版本号.当新的版本号大于当前的version时会调用方法: onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) 所以我们的重点是在该方法中实现SQLite数据库版本升级的管理

应用程序版本升级之通用更新组件

目的 很多做应用程序的朋友都做过为应用程序进行版本升级的功能,这个功能本身非常简单,但是各位有没有考虑过这个问题:假如我需要维护多个应用程序的时候(>2).每个应用程序的升级工作将变得很繁琐.我们需要有一套通用的更新机制,只需要为需要升级的应用程序进行简单的配置,就可以为之进行版本升级控制,而不需要单独给每个应用程序写升级的功能从而达到一劳永逸的目的. 组成 那么通用更新的组件应该如何来设计,它至少需要以下两个模块构成: 1.客户端模块    1.1 负责发送版本验证请求    1.2 负责下载

【转】Android使用SQLite数据库版本升级

Android使用SQLite数据库保存数据,那数据库版本升级是怎么回事呢,这里说一下. 一.软件v1.0 安装v1.0,假设v1.0版本只有一个account表,这时走继承SQLiteOpenHelper的onCreate,不走onUpgrade. 1.v1.0(直接安装v1.0) 二.软件v2.0 有2种安装软件情况: 1.v1.0   -->  v2.0              不走onCreate,走onUpgrade 2.v2.0(直接安装v2.0)          走onCrea

PostgreSQL升级之pg_upgrade升级

PostgreSQL中的升级,如果针对小版本的升级,比如9.6.1升级到9.6.2(当前的最新版本),只需要用9.6.2版本的软件替换9.6.1版本的软件即可,不需要做额外的操作,因为整个大版本是相互兼容的,内部存储形式也是兼容的.但如果涉及到跨大版本升级比如9.4.11升级到9.6.2,这种直接替换软件就不行了,因为跨版本的内部存储形式发生了变化. 官方给了三种升级的方式来解决跨版本升级: pg_dumpall pg_upgrade 通过复制 pg_dumpall是一种把数据从旧版本逻辑导出,

军规14 增量升级必不可少

作为一个用户,测试过程中要注意APP升级时是否必须先卸载,才能安装:还有就是安装了最新版的,却发现之前的登陆信息全没了,还需要重新登陆:还有这就是最新版的安装后会不会崩溃. 14.1 测试APP的增量升级 对于增量升级,测试员不能只为了方便只进行全新安装的测试,还需要对APP升级安装也进行测试.不过可以对全新安装的APP进行重点测试,对APP升级的进行冒烟测试,或者对改变的功能进行有重点的测试.对于降级可以不考虑测试. 测试APP升级,需要注意以下细节: 1.在APP升级前登陆的用户信息在APP