1
sanxianA 2023-11-29 19:26:48 +08:00 via Android
好奇+1 ,但是一般这种 k8s 集群不是应该都有双活集群设计或者灾备设计的嘛
|
2
kdd0063 2023-11-29 19:27:59 +08:00
难道生产环境敢直接 k8s 升大版本?这未免也太心大了。好歹搞个灰度环境用金丝雀策略试试水吧
|
3
assassing 2023-11-29 20:03:51 +08:00
看了眼居然还在用 1.12 以下版本。
控制节点升错了版本确实没有什么办法能回退,只能重建集群。估计开始还想着能不能降级回来,所以停了那么久。 |
4
dianso 2023-11-29 20:05:40 +08:00
是升级 xp 的时候弄坏了,各种谣言
|
5
NX2023 2023-11-29 20:13:14 +08:00
想起来前几周的 Gopher China ((
|
6
NX2023 2023-11-29 20:17:57 +08:00 1
|
7
kuituosi 2023-11-29 20:18:51 +08:00
明显是借口,而且很长时间都没有恢复
明显是数据出问题了,工程师修复数据太花时间了 |
8
fujohnwang 2023-11-29 20:20:40 +08:00
|
9
gam2046 2023-11-29 20:39:47 +08:00
运维问题导致中断服务不至于这么久,即使直接上生产,即使升崩了,即使整个集群重建,12 个小时还是太久了。
个人偏向认为#7 说的数据问题的可能性更大。由于误操作或者其他原因导致生产数据被污染需要更久的恢复时间。 网上有用户说故障期间,计费、派单等异常,虽然不知道滴滴是怎么设计的,但是以普遍理性而言,如果集群内部分服务降级甚至不可用,一般会导致依赖服务降级或不可用。但是出现短距离的打车出现千元的计费,猜起来确实更像数据被污染了。 |
10
mightybruce 2023-11-29 21:24:49 +08:00
k8s 是包含服务注册、降级、也是很多服务配置中心以及元数据存储的地方
滴滴技术在文章里写原地大版本升级,艺高人胆大,链接在下 https://mp.weixin.qq.com/s/nMSIsS72fSXGqJO9Vy_Pfw |
11
xuanbg 2023-11-30 04:04:04 +08:00
@mightybruce 他们这两个方案,要么原地升级,要么全量替代,确实很极端。。。
就不能用折衷方案?就是部署一套新的运维环境,这要不了几台机器。然后新环境上一个 node 就切一点流量,一会儿功夫也就切完了,只要不在这个过程中升级服务,哪里会有什么 P 事。 因为作为生产者的服务和数据两个环境都是一样的,所以对消费者而言就无感。 |
12
golangLover 2023-11-30 07:49:54 +08:00 via Android
@mightybruce 他都能写出来了,肯定不是一个月前的升级了。。。
|
14
dyllen 2023-11-30 10:41:22 +08:00
|
16
wr410 2023-11-30 10:54:13 +08:00
根据我的经验,超过 1 小时恢复不了的问题都是数据库问题
|
17
kiddingU 2023-11-30 10:55:35 +08:00
原地升级简直爆炸,不理解为啥不是单独新增机房慢慢迁移,出了事故就是这帮人自己背锅了,只能说艺高人胆大~
|
18
golangLover 2023-11-30 11:15:57 +08:00 via Android
@dyllen 对阿。这么多人都理解错了。。。还有说是 k8s 版本看错的,也有人信。真的什么有人都有
|
19
kiddingU 2023-11-30 11:20:44 +08:00
@golangLover 文章写出来了,所有的机房所有的集群就都升级完了?一个公司的机房又不是一个,内网升级了部分机房,然后写出技术文章,有毛病吗?
|
20
buffzty 2023-11-30 11:24:15 +08:00
@gam2046 升级是很快 有些兼容问题很难解决 比如你升级了 k8s rook-ceph 就不兼容了 但是 rook 官网说它兼容 k8s 这个版本 实际上根本运行不了 在网上也找不到答案 只能慢慢看 ceph 源码 他们这 18 个小时要么是去找人了 要么就是去看源码了 可能就改一个参数就好了 但是这个参数官网没写 网上也搜不到
|
21
dx3759 2023-11-30 11:33:36 +08:00
原地升级方案介绍:
只有一个 k8s 集群,将 master 和周边组件直接从 1.12 升级到 1.20 ; 逐步将集群中的 node 也就是 kubelet 从 1.12 版本升级到 1.20 ; 不做任何业务负载相关的操作,也就是 sts 和 pod 无需重建,其实的流量分布也不做操作,随着 node 升级流量天然就逐步从 1.12 切到 1.20 了; 有问题的时候需要部分回滚 node 的 kubelet ,当出现全局性风险的时候需要全量回滚 master 和周边组件。 他们一定充分测试了版本兼容性吧。 |
22
gam2046 2023-11-30 12:26:20 +08:00
@buffzty 之前我和阿里的老哥聊天,谈到过,如果线上遇到任何故障/bug ,哪怕只是文本错误,处理方案有且只有一种,回退。并不存在线上修 bug 的可能性,回退以后,测试环境继续修 bug ,然后重新走测试、上线流程。
滴滴也是个独角兽企业了,大体流程上,不能够这么草率吧,线上业务都停了,然后找人在线上改 bug 。 当然啦,也不排除集群设计的时候,降级困难甚至无法降级回退,只能硬着头皮在线上修吧 |
23
MuSit 2023-11-30 17:06:10 +08:00 via Android
我推测应该是这样 像滴滴这种高并发实时性强的业务肯定很多地方用的的是内存 cache 12 升 20 一开始服务起不来 修复起来后发现 sc 可能因为版本关系也重建了 缓存持久化
|
24
MuSit 2023-11-30 17:07:53 +08:00 via Android
的东西是存在 pv 里 也就是 pv 也都重建了 业务重启后面对全国服务重新 init cache 不亚于一次大规模 ddos 导致大量服务不正常
|
25
MuSit 2023-11-30 17:14:14 +08:00 via Android
测试集群可能没这么大的 cache 不会影响 或者之前测试升级时候升 sc 本来是在后边的版本进行 需要对
pv 数据备份 误操作直接干上去导致数据都丢了 |
26
singer 2023-11-30 20:46:26 +08:00 via iPhone
滴滴的不知道是不是有隐藏 bug ,虽然爆发在 11 月 28 晚上,但我在 11 月 25 晚碰到了类似的情况。打了专车,司机定位就在我边上,就是死活找不到车。给司机打电话后,司机挂断电话。再次拨打电话号码变了,再拨打,再变。每次拨打都在通话中。
|
27
golangLover 2023-12-05 03:58:36 +08:00 via Android
@kiddingU 你仔细看一下滴滴的文章吧:
目前已无损升级滴滴所有核心机房万级别的 node 和十万级别 pod ,且升级过程中业务完全无感,未发生一次故障。 升级从来都是非核心然后到核心,也就是说他这个升级方案已经通过了非核心应用,以及所有核心应用的验证。 |
28
kiddingU 2023-12-05 14:08:25 +08:00
@golangLover 吹的再好,也是发生了事故,别再这里抬杠,结果就是除了事故
|
29
golangLover 2023-12-05 23:50:58 +08:00 via Android
@kiddingU 有事故是事实。但把滴滴运维当普通人的言论, 什么看错 k8s 版本啊,是不是所有机房都升级完了才发文章之类,推敲一下就有答案了
|
30
kiddingU 364 天前
@golangLover 你在说神马?????你赢了。。
|