稳定运行 1000 天的 Kubernetes 如何跨版本升级?

大家好,我是张晋涛。

祝大家新年快乐!

恰逢年末,我在梳理自己手头的服务时突然发现有一台已经稳定运行 1000 天的机器,被我遗忘在了角落。

2d715d4d6683cc283bce4e21b489ca1d.png

这是个 v1.23 版本的单节点 Kubernetes , 上面只运行着我自己的日历服务和网关等,服务倒是一直没有中断过,所以也就基本上没有去管过它。

1035a5df2db963ed14f2adf0d52ff6df.png

考虑到 v1.23 已经 EOL 几年了,我打算把它升级到 v1.32 。

该开个直播还是升级完后写篇踩坑记呢?🤔 我在这里发起一个投票,欢迎大家投票,最后按投票结果来决定是开直播(有可能翻车)还是升级完成后分享经验。

c8dd7ef480890ae661dedd69c22182b3.png

Kubernetes 升级的要点

  • 是否存在废弃 API 依赖

50559013886f358361555745a52b5cec.png

这是非常关键的点,如果使用了已经废弃的 API,在升级后就可能会导致服务受到影响。

这里我推荐使用 kubent: https://github.com/doitintl/kube-no-trouble

这个工具可以很快速的检查是否有在使用已经废弃的 API。

$./kubent
6:25PM INF >>> Kube No Trouble `kubent` <<<
6:25PM INF Initializing collectors and retrieving data
6:25PM INF Retrieved 103 resources from collector name=Cluster
6:25PM INF Retrieved 0 resources from collector name="Helm v3"
6:25PM INF Loaded ruleset name=deprecated-1-16.rego
6:25PM INF Loaded ruleset name=deprecated-1-20.rego
__________________________________________________________________________________________
>>> 1.16 Deprecated APIs <<<
------------------------------------------------------------------------------------------
KIND         NAMESPACE     NAME                    API_VERSION
Deployment   default       nginx-deployment-old    apps/v1beta1
Deployment   kube-system   event-exporter-v0.2.5   apps/v1beta1
Deployment   kube-system   k8s-snapshots           extensions/v1beta1
Deployment   kube-system   kube-dns                extensions/v1beta1
__________________________________________________________________________________________
>>> 1.20 Deprecated APIs <<<
------------------------------------------------------------------------------------------
KIND      NAMESPACE   NAME           API_VERSION
Ingress   default     test-ingress   extensions/v1beta1
  • 是否存在破坏性变更

其实 Kubernetes 相对还好,有比较完善的兼容性策略。而且由于我最近 5 年基本上都在更新 『k8s生态周报』(2024 年断更了,争取明年恢复更新),我也一直在关注 Kubernetes 中的变化,这里是我对于 Kubernetes 每个版本更新做的总结:

  • 组件间依赖的兼容性

除了 Kubernetes 自身外,其实还包括服务器使用的 OS,容器运行时的版本以及相关的依赖。这里具体来说就是:

  • OS 版本 + 内核版本

  • containerd

  • runc

  • CNI/CSI 等插件

  • 其他相关依赖

7d3cb85e1b369b5ed0f7423e61ec1a7d.png

e8e0f209fed1015a40103809a8bb5748.png

  • 回滚计划

制定如果升级失败或者出现异常时候的计划,要跨版本升级可能出现的问题还是比较多的,所以万一出现异常也需要有个计划。

  • 其他

其实升级嘛,还需要考虑是否有测试环境来进行验证;制定维护窗口,设定一个大概的影响时间;以及如果是有提供其他服务的话,还需要做好沟通。

但是我这个环境,我估计就不加测试环境了,但是考虑到要避免服务中断,那么我可能会先把这个单节点集群进行扩容,为它增加 control plane 和 Node ,让它成为一个高可用模式后,再进行升级。

082e2b4cfd92f87893948ac04bfc369d.png

欢迎在文章开头投票!是直播还是写文章你来决定

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

张晋涛-MoeLove

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值