1
libook 2021-10-28 12:20:43 +08:00
没有应用过,这方面做得最好的貌似是 Netflix ,你可以看看他们有什么最佳实践。
|
2
sggggy 2021-10-28 14:00:46 +08:00
找个测试环境先测吧,chaosblade 用过,后来和团队说了,想试试看要不要搞这个,大家都很慌,我们也久按住没动了。要做混沌工程,全链路监控要先做好才行。
|
3
QAO 2021-10-28 14:07:51 +08:00
如果应用已经运行在 k8s 毫无疑问用 chaos mesh,如果还是裸跑在机器上的话就用 chaosblade 吧。
另外搞混沌工程,对这些工具的使用只是一部分,如何做好观测、恢复、自动化等都是需要考虑的 |
4
SmiteChow 2021-10-28 14:11:30 +08:00
名字够玄乎
|
5
yzbythesea 2021-10-28 14:15:31 +08:00
|
6
oldboy627 OP @sggggy chaosblade 阿里巴巴出品的,不知道以后会不会突然就...看文档没有做国际化,感觉只是国内用户用的多
|
7
oldboy627 OP @QAO 我们应用已经全部都跑在 k8s 上了,没有裸机的应用。你说的自动化我们已经完善了。 相比于 blade ,我也倾向于 chaos mesh ,但是 Litmus 似乎也还不错,有 redhat 等大厂的评价。 就想看看大家都怎么选型,生产中 /测试中有什么产品的实践方案。
|
8
oldboy627 OP @yzbythesea 名字就是叫 ChaosMesh
|
9
STRRL 2021-10-28 15:24:40 +08:00 4
还是看应用的场景吧,如果需要做 JVM 相关的 Chaos 那肯定首选 chaosblade; 如果是应用已经在 kubernetes 上, 而且更多的是做 Pod 那层的故障注入, 网络啦, IO 啦, CPU 内存压力啦等等, 那更推荐 Chaos Mesh 或 Litmus;
个人认为,Chaos Mesh 和 Litmus 最主要的区别还是在如何定义一个故障上,二者的风格不同;至于谁好那见仁见智了,建议可以都试试; 另外这几个项目都还处于比较初期的发展阶段,都在比较快速的迭代中,未来的要走的路还有很长; > 另外搞混沌工程,对这些工具的使用只是一部分,如何做好观测、恢复、自动化等都是需要考虑的 另外这个说的很对,基建比较好,混沌工程做起来也比较方便; 当然也可以先看看混沌工程,再去反观下自己的基建哪里做的不够; (利益相关: 俺是 Chaos Mesh Committer |
10
andj4cn 2021-10-28 23:42:04 +08:00
猴子军团整起来
|
11
lei2j 2021-10-29 09:46:54 +08:00
这名词感觉挺新颖
|
12
superhack 2021-10-29 11:55:19 +08:00
Litmus 相对完善,不过也是各种坑
|
13
oldboy627 OP @superhack 扫了一眼,Litmus 好像每一个 experiments 都要部署 rbac ,好像挺麻烦的
|
15
leeraya 2021-10-30 10:46:49 +08:00
k8s 就上 chaos mesh 吧。 之前用 chaos mesh 构建过数据库日报系统。定时跑 podkill, podfail 任务,抓日志,画图,每天生成数据库运行报告。用起来还可以的,文档也全。
|
16
yorelog 2021-11-08 17:32:21 +08:00
最近也在调研准备内部应用混沌工程。初步想法是 chaos mesh ,chaosblade 两个结合使用。
chaos mesh 本身也结合一部分 chaosblad 的功能进去了 如 jvm 注入 |