2025年k8s 升级（k8s升级gitlab版本）

科技前沿 • 2025-06-09 08:53 • 阅读 72

大家好，我是讯享网，很高兴认识大家。

本文是一个系列，本篇为系列文章的第四篇：

第一篇：

第二篇：

第三篇：

本文仍基于在腾讯云购买的轻量机 cn-tx-bj7-a9 上安装，AlmaLinux 9.4 版本，配置为 4C4G60G

上一篇文章中介绍了公司内部使用的 GitLab 是如何配置每日执行异地备份的

结尾提及下一篇文章计划介绍生产环境跨 6 个大版本的真实升级经历，没错，这篇文章就来详细回顾一下当时升级的全流程

这里说一下，生产环境的机子是 CentOS 7 版本的，而标题为了统一仍沿用了 AlmaLinux 9（标题已经换掉了）

但并不会影响到整体升级的思路

好端端跑着的服务，为啥要升级呢？原因自然是 GitLab 曝出新授权漏洞需要及时打补丁了

我们接到的通知比较延后，下午收到的通知，晚上就要执行升级

于是开始一边看官方文档，一边捋升级的整体流程

万事开头难，毕竟谁都没有搞过，想着还是先备份一下，先整机备份好了

没有把第二步的备份档下载到自己的电脑上，而是直接 rsync 传到了另一台异地 VM 上，这样就双保险了

上面这两个层级的备份搞完，差不多就花了 3+ 个小时吧，因为这 VM 在圣何塞……网速实在是不快，好在不会掉线

接下来就可以无所畏惧的计划升级了

参考官方文档：

是要先生成 Upgrade Path：，也就是跨大版本的逐级升级

查看摘要

额外提醒最下面那个 glibc 兼容性问题需要留意

具体升级的版本列表如下

一共需要 16 + 1 = 17 次升级，通宵是在劫难逃了

为了稳定考虑，没有使用 yum install 在线安装，而是去下载了 rpm 包，这样就能盯着实时升级的进度看了

执行命令为：rpm -Uvh xxx.rpm > version.log

万事开头难，但没想到第一个升级顺利完成了，可以看到 rake 输出的一大堆日志，也并不需要我们做什么

这里还有一个问题，VM 硬盘空间危！

为了给升级留够空间，上传一个 rpm 升级后再上传下一个，一个一个来

但自己早上起来才得知，半夜执行到某个版本后还是 disk full 了，折腾了一大顿好在卸载重装后恢复正常了，不然可就是进退两难的局面了

实测每个 rpm 包先下载到自己 PC 上再上传到 VM，都比直接在 VM 上下载要来的快

以及还是因为并不快的网速，最终从第一天晚上搞到第二天下午才彻底完成了升级：11.4.X -> 16.3.9

作为 admin，在第二天上午还是看到有同事在使用 GitLab 进行 merge，是真不怕提交记录说无就无了

参照官方文档：

在 rpm 升级完一个版本之后，一定要等待后台迁移完毕之后再升级下个版本

没过几天，就又收到了升级通知，于是继续升级，毕竟被折磨过一回了，もう何も怖くない（已经没什么好怕的了）

这里贴一下自己的腾讯云轻量机上部署的实例概览，可以看到详细的版本信息

一直都想把这次的升级经验拿出来讲讲，趁双十一活动花了接近 2h 终于是给写完了

通宵是不可能通宵的，这辈子都不可能通宵的，狗命要紧，该睡还是得睡的

众所周知，升级打补丁还是放在定期任务里比较合适，就不用临阵抱佛脚了，但道理都懂

下一篇文章开始介绍 GitLab CI/CD 的相关实践，计划从部署GitLab Runner 说起

也欢迎购买轻量机进行尝试，双十一拼团有优惠：