这里有针对k8s的chaos功能么？ 我自己用go写了一个 about chaosblade HOT 18 CLOSED

是的。非常欢迎将你的 k8s chaos 集成到 chaosblade 中，你可以提交个 issue 和 pr。如果你还有其他问题，可以给我发邮件。

Yes. Very welcome to integrate your k8s chaos into chaosblade, you can submit an issue and pr. If you have other questions, you can send me an email.

from chaosblade.

@ycwdaaaa 我很想和做进一步的沟通，能否把你之前实现的 k8s 场景描述一下，或者代码仓库提供一下，我们讨论下如何整合？如果不方便公开的话，能否将相关信息发我邮箱？期待你的答复:-)

I really want to communicate with you further. Can you describe the kubernetes fault-injection you implemented earlier, or provide the code repository for discussing how to integrate? If it is not convenient to public, can you send me the relevant information to my mailbox? Looking forward to your reply :-) @ycwdaaaa

from chaosblade.

@xcaspar 我之前做的事情也比较简单， 模拟的都是运维故障。 只不过跟我们的产品环境耦合的比较紧。 除了要模拟故障之外，还要分析影响范围，自动恢复的时间，同时要求所有的测试都是自动化的，也就是故障触发了还要能恢复后继续下一个故障测试。所以一般都是一轮自动化测试中只定时触发一种事故，比如只定时随机的stop docker进程， stop后隔10分钟后触发恢复程序， 然后隔几分钟再随机挑一台机器stop docker进程。 一直到这次自动化测试结束。然后记录结果，统计信息。 然后启动下一轮自动化测试，定时触发下一个故障。

所以工具里基本上是有两个队列来控制事故的触发和恢复的。 通用队列用来存放传入的事故。 消费者拿出来触发后，根据策略放到另一个延迟队列里，这个延迟队列用来恢复故障的

from chaosblade.

@xcaspar 我之前做的事情也比较简单， 模拟的都是运维故障。 只不过跟我们的产品环境耦合的比较紧。 除了要模拟故障之外，还要分析影响范围，自动恢复的时间，同时要求所有的测试都是自动化的，也就是故障触发了还要能恢复后继续下一个故障测试。所以一般都是一轮自动化测试中只定时触发一种事故，比如只定时随机的stop docker进程， stop后隔10分钟后触发恢复程序， 然后隔几分钟再随机挑一台机器stop docker进程。 一直到这次自动化测试结束。然后记录结果，统计信息。 然后启动下一轮自动化测试，定时触发下一个故障。

所以工具里基本上是有两个队列来控制事故的触发和恢复的。 通用队列用来存放传入的事故。 消费者拿出来触发后，根据策略放到另一个延迟队列里，这个延迟队列用来恢复故障的

明白。你们目前实现的 kubernetes 混沌实验场景有哪些?

from chaosblade.

@xcaspar 我之前做的事情也比较简单， 模拟的都是运维故障。 只不过跟我们的产品环境耦合的比较紧。 除了要模拟故障之外，还要分析影响范围，自动恢复的时间，同时要求所有的测试都是自动化的，也就是故障触发了还要能恢复后继续下一个故障测试。所以一般都是一轮自动化测试中只定时触发一种事故，比如只定时随机的stop docker进程， stop后隔10分钟后触发恢复程序， 然后隔几分钟再随机挑一台机器stop docker进程。 一直到这次自动化测试结束。然后记录结果，统计信息。 然后启动下一轮自动化测试，定时触发下一个故障。
所以工具里基本上是有两个队列来控制事故的触发和恢复的。 通用队列用来存放传入的事故。 消费者拿出来触发后，根据策略放到另一个延迟队列里，这个延迟队列用来恢复故障的

明白。你们目前实现的 kubernetes 混沌实验场景有哪些?

暂时还比较简单， 就是杀pod， 停docker以及停kubelet，apiserver这种k8s组件。 接下来想实现容器内的故障，比如打满cpu。

from chaosblade.

@xcaspar 我之前做的事情也比较简单， 模拟的都是运维故障。 只不过跟我们的产品环境耦合的比较紧。 除了要模拟故障之外，还要分析影响范围，自动恢复的时间，同时要求所有的测试都是自动化的，也就是故障触发了还要能恢复后继续下一个故障测试。所以一般都是一轮自动化测试中只定时触发一种事故，比如只定时随机的stop docker进程， stop后隔10分钟后触发恢复程序， 然后隔几分钟再随机挑一台机器stop docker进程。 一直到这次自动化测试结束。然后记录结果，统计信息。 然后启动下一轮自动化测试，定时触发下一个故障。
所以工具里基本上是有两个队列来控制事故的触发和恢复的。 通用队列用来存放传入的事故。 消费者拿出来触发后，根据策略放到另一个延迟队列里，这个延迟队列用来恢复故障的

明白。你们目前实现的 kubernetes 混沌实验场景有哪些?

暂时还比较简单， 就是杀pod， 停docker以及停kubelet，apiserver这种k8s组件。 接下来想实现容器内的故障，比如打满cpu。

好的，”实现容器内的故障，比如打满cpu“ 我们内部做过一个版本，优化后对外开源。”停docker以及停kubelet，apiserver这种k8s组件“ 可以先接过来，你可以先看下 chaosblade 的代码，看是否好接入。有问题的话，你可以发相关信息到我邮箱 :-)

from chaosblade.

@xcaspar 我之前做的事情也比较简单， 模拟的都是运维故障。 只不过跟我们的产品环境耦合的比较紧。 除了要模拟故障之外，还要分析影响范围，自动恢复的时间，同时要求所有的测试都是自动化的，也就是故障触发了还要能恢复后继续下一个故障测试。所以一般都是一轮自动化测试中只定时触发一种事故，比如只定时随机的stop docker进程， stop后隔10分钟后触发恢复程序， 然后隔几分钟再随机挑一台机器stop docker进程。 一直到这次自动化测试结束。然后记录结果，统计信息。 然后启动下一轮自动化测试，定时触发下一个故障。
所以工具里基本上是有两个队列来控制事故的触发和恢复的。 通用队列用来存放传入的事故。 消费者拿出来触发后，根据策略放到另一个延迟队列里，这个延迟队列用来恢复故障的

明白。你们目前实现的 kubernetes 混沌实验场景有哪些?

暂时还比较简单， 就是杀pod， 停docker以及停kubelet，apiserver这种k8s组件。 接下来想实现容器内的故障，比如打满cpu。

好的，”实现容器内的故障，比如打满cpu“ 我们内部做过一个版本，优化后对外开源。”停docker以及停kubelet，apiserver这种k8s组件“ 可以先接过来，你可以先看下 chaosblade 的代码，看是否好接入。有问题的话，你可以发相关信息到我邮箱 :-)

恩， 有时间我看一下，是不太好接， 我这的代码跟公司环境耦合的太厉害。 顺便问一下， 容器内的burn cpu 的实现是用什么方式？ 我之前都习惯了用dd来做。

from chaosblade.

@xcaspar 我之前做的事情也比较简单， 模拟的都是运维故障。 只不过跟我们的产品环境耦合的比较紧。 除了要模拟故障之外，还要分析影响范围，自动恢复的时间，同时要求所有的测试都是自动化的，也就是故障触发了还要能恢复后继续下一个故障测试。所以一般都是一轮自动化测试中只定时触发一种事故，比如只定时随机的stop docker进程， stop后隔10分钟后触发恢复程序， 然后隔几分钟再随机挑一台机器stop docker进程。 一直到这次自动化测试结束。然后记录结果，统计信息。 然后启动下一轮自动化测试，定时触发下一个故障。
所以工具里基本上是有两个队列来控制事故的触发和恢复的。 通用队列用来存放传入的事故。 消费者拿出来触发后，根据策略放到另一个延迟队列里，这个延迟队列用来恢复故障的

明白。你们目前实现的 kubernetes 混沌实验场景有哪些?

暂时还比较简单， 就是杀pod， 停docker以及停kubelet，apiserver这种k8s组件。 接下来想实现容器内的故障，比如打满cpu。

好的，”实现容器内的故障，比如打满cpu“ 我们内部做过一个版本，优化后对外开源。”停docker以及停kubelet，apiserver这种k8s组件“ 可以先接过来，你可以先看下 chaosblade 的代码，看是否好接入。有问题的话，你可以发相关信息到我邮箱 :-)

恩， 有时间我看一下，是不太好接， 我这的代码跟公司环境耦合的太厉害。 顺便问一下， 容器内的burn cpu 的实现是用什么方式？ 我之前都习惯了用dd来做。

用什么方式实现 CPU 满载都可以，比如 openssl。chaosblade 的实现见 burncpu.go。

重点是，对运行中的容器（业务容器，没有 chaosblade 工具）如何做。

from chaosblade.

“重点是，对运行中的容器（业务容器，没有 chaosblade 工具）如何做。”

请问你是怎么把故障注入到容器中的呢？ 很多业务模块没有golang环境， 你是怎么让你构建故障的脚本在容器中生效的呢？

from chaosblade.

“重点是，对运行中的容器（业务容器，没有 chaosblade 工具）如何做。”

请问你是怎么把故障注入到容器中的呢？ 很多业务模块没有golang环境， 你是怎么让你构建故障的脚本在容器中生效的呢？

目前基础资源的故障程序不需要 golang 的环境，直接将工具 copy 到目标容器内执行。

from chaosblade.

目前基础资源的故障程序不需要 golang 的环境，直接将工具 copy 到目标容器内执行。

能请教一下基础资源故障程序在哪么~ 我想要学习学习

from chaosblade.

目前基础资源的故障程序不需要 golang 的环境，直接将工具 copy 到目标容器内执行。

能请教一下基础资源故障程序在哪么~ 我想要学习学习

https://github.com/chaosblade-io/chaosblade-exec-os

from chaosblade.

这里好像还是需要golang环境的代码呢？

from chaosblade.

这里好像还是需要golang环境的代码呢？

是的，代码编译需要安装 golang，编译后运行无需 golang 环境。

from chaosblade.

哦 哦 明白了~

from chaosblade.

能再请教一个问题么， 我看模拟网络延迟是用tc来做的。 为什么不用更简单的Netem 来模拟网络事故呢？ 这里是有什么原因需要tc更强大的队列分类功能么？

from chaosblade.

能再请教一个问题么， 我看模拟网络延迟是用tc来做的。 为什么不用更简单的Netem 来模拟网络事故呢？ 这里是有什么原因需要tc更强大的队列分类功能么？

指定端口、IP过滤

from chaosblade.

@ycwdaaaa I will close the issue. If you have new questions, please open a new issue. Thank you.

from chaosblade.