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