Chaos Mesh 是针对K8S的云原生混沌工程开源平台。 可以用它方便地模拟开发、测试、生产环境中可能出现的各种异常情况,发现系统中潜在的问题。 实验工作流 实验工作流,包括编排顺序或并行执行的故障注入实验,查看实验状态和结果,暂停实验,支持用YAML或Web UI定义和管理实验。 可视化操作 可视化操作,包括可以在Web UI上点击鼠标,定义实验的范围、故障注入类型和调度规则,最后能展示实验结果。 安全控制 安全控制,包括使用K8S原生提供的基于角色的访问控制功能,来管理故障注入的使用权限。还可以通过设置命名空间注解,来指定允许进行混沌实验的命名空间,进一步保障对混沌实验的控制。 使用K8S原生提供的基于角色的访问控制功能,来管理故障注入的使用权限。 劣势 只能在K8S集群上使用。否则,就只能使用针对节点进行故障注入实验的附带工具chaosd。 临时执行的实验会无限期地运行。
Chaos Mesh 是针对K8S的云原生混沌工程开源平台。 可以用它方便地模拟开发、测试、生产环境中可能出现的各种异常情况,发现系统中潜在的问题。 实验工作流 实验工作流,包括编排顺序或并行执行的故障注入实验,查看实验状态和结果,暂停实验,支持用YAML或Web UI定义和管理实验。 可视化操作 可视化操作,包括可以在Web UI上点击鼠标,定义实验的范围、故障注入类型和调度规则,最后能展示实验结果。 安全控制 安全控制,包括使用K8S原生提供的基于角色的访问控制功能,来管理故障注入的使用权限。还可以通过设置命名空间注解,来指定允许进行混沌实验的命名空间,进一步保障对混沌实验的控制。 使用K8S原生提供的基于角色的访问控制功能,来管理故障注入的使用权限。 劣势 只能在K8S集群上使用。否则,就只能使用针对节点进行故障注入实验的附带工具chaosd。 临时执行的实验会无限期地运行。
注:它们Pod标签都有app: nginx,service服务发现根据这个标签选择,version是为后面定义版本设置的
networking/virtual-service-reviews-test-v2.yaml virtualservice.networking.istio.io/reviews created 或者进行故障注入 destination: host: reviews subset: v1 如何headers的end-user 字段匹配了jason就走v2的reviews 接着我们看下如何做故障注入的
本文将介绍如何使用混沌工具对 Pod/Node 进行 CPU 负载故障注入,以达到指定的 CPU 负载百分比。 2. 参数 在进行 CPU 负载故障注入时,我们可以通过以下参数来控制: nice:指定 CPU 负载进程的 nice 值(静态优先级),取值范围为[-20, 19]。 实现原理 混沌工具在进行 CPU 负载故障注入时,主要通过以下方式实现: 启动 chaos_burncpu 进程,空跑 for 循环来消耗 CPU 时间片。 通过以上方法,我们可以轻松地对 Pod/Node 进行 CPU 负载故障注入,从而验证系统在不同负载下的表现,以及监控告警、流量调度、弹性伸缩等能力。 使用腾讯云混沌演练平台实施 CPU 高负载。
在K8S上部署的微服务,经常会依赖不受你控制的其他微服务。当两者之间的HTTP交互出现延迟或错误后,你的微服务能否按预期正常工作?应该做一个故障注入实验来检验一下。 如果在K8S上使用了Istio,那么恭喜你,你已经拥有了简单易用的混沌工程开源工具。 图片一句话介绍虽然Istio主要作为K8S服务网格,用于连接、保护、控制和观察服务,但在其流量管理功能中也支持故障注入。 可以使用现有的 Istio 功能(例如虚拟服务和路由规则)来选择故障注入目标。 还可以使用运行状况检查和 Envoy 统计数据来监控故障注入对系统的影响。 适用平台K8S适用场景如果已经使用了 Istio,那么这可以直接用它在集群上运行混沌实验,而无需部署或学习其他工具。 否则,仅仅为了这两种故障注入功能就部署 Istio ,就不值了。
Litmus 最初是 OpenEBS(K8S下存储系统) 的测试工具,后来发展成为知名的 Kubernetes 原生混沌工程开源平台。 创建者 MayaData 一句话介绍 LitmusChaos 是一个在故障创建与编排方面更胜一筹的K8S混沌工程开源平台,如提供故障注入实验库 ChaosHub,使团队能够以受控方式,引入故障注入实验来识别基础设施中的弱点和潜在停机隐患 可安排单次或 Cron定时故障注入场景。可以用例优先级标注故障注入实验。 可使用 Prometheus 数据源中的交错事件和指标实时监控故障注入实验的影响。 K8S多租户 Kubernetes 命名空间可用作 Kubernetes 上个人开发人员的完全托管环境。 适用平台 K8S 适用场景 对于开发人员:在应用程序开发过程中运行故障注入实验,作为单元测试或集成测试的扩展。
在这篇博文中,我将带领大家探索如何在服务网格中进行故障注入实验,分享Chaos Engineering的最佳实践,并深入研究服务网格如Istio中的故障注入功能。 引言 混沌工程不仅仅是故意制造故障,而是一种科学的方法,通过故障注入来发现系统中的潜在问题,并验证系统的弹性。 服务网格,作为微服务架构的通信层,为我们提供了强大的故障注入工具,帮助我们更好地进行混沌实验。 正文 1. 什么是混沌工程? 混沌工程是一种通过主动注入故障来验证系统健壮性的方法。 2.1 Istio的故障注入功能 Istio允许我们在服务间的通信中注入故障,如延迟、错误等。 3.3 运行实验 使用服务网格的工具,如Istio,进行故障注入。 3.4 分析实验结果 收集实验数据,分析系统在故障下的表现,找出潜在的问题。 4.
Litmus 最初是 OpenEBS(K8S下存储系统) 的测试工具,后来发展成为知名的 Kubernetes 原生混沌工程开源平台。 图片创建者MayaData一句话介绍LitmusChaos 是一个在故障创建与编排方面更胜一筹的K8S混沌工程开源平台,如提供故障注入实验库 ChaosHub,使团队能够以受控方式,引入故障注入实验来识别基础设施中的弱点和潜在停机隐患 可安排单次或 Cron定时故障注入场景。可以用例优先级标注故障注入实验。 可使用 Prometheus 数据源中的交错事件和指标实时监控故障注入实验的影响。K8S多租户Kubernetes 命名空间可用作 Kubernetes 上个人开发人员的完全托管环境。 适用平台K8S适用场景对于开发人员:在应用程序开发过程中运行故障注入实验,作为单元测试或集成测试的扩展。
一、为什么需要故障注入? 基础设施可靠性测试K8s/云平台故障恢复能力 节点宕机、Pod被杀、存储卷丢失 3. 数据层容灾演练验证DB/缓存故障时的数据一致性 主从切换、Redis OOM、慢查询 4. Traffic Control), Pumba 模拟丢包、延迟、带宽限制 系统层 Stress-ng, SysBench CPU/内存/磁盘压力测试 容器/K8s 理由 快速上手 + 开源免费 ChaosBlade 阿里开源,支持Java/Go/容器/Docker K8s 注入支付服务接口延迟(目标:payment-service Pod)blade create k8s pod-network delay \ --names payment-pod-xxx \ --
本文将介绍如何使用混沌工具对 Pod/Node 进行内存负载故障注入,以达到指定的内存占用百分比。腾讯云混沌演练平台故障动作:标准集群 Pod/普通节点-内存利用率高。 2. 参数 在进行内存负载故障注入时,我们可以通过以下参数来控制: percent:内存使用率,取值是 0 到 100 的整数,默认值为 100。此参数为可选。 实现原理 混沌工具在进行内存负载故障注入时,主要通过以下方式实现: ram 模式:启动进程 chaos_burnmem 不断申请内存,模拟主机/容器内存负载升高。 为了保护该进程在故障注入期间一直存在,不被杀死,可以打开 oomGuard 保护,降低该进程 oom-kill 权重,优先杀死其他进程。 设置高负载的内存故障注入后,可能会使得机器无法登入与控制,请谨慎使用。 cache 模式:通过挂载 tmpfs 来实现内存占用。
ChaosBlade可针对多达7个场景开展故障注入实验,但网上官方的中英文文档质量欠佳,内容缺失,真心没有站在一般用户的角度来写,只能通过运行blade命令的help了解究竟有什么功能。 图片 一句话介绍 ChaosBlade是阿里巴巴开源的针对7个检验软件系统稳定性场景的混沌工程故障注入开源工具:主机基础资源、CRI容器、K8S平台、Java应用、C++应用、阿里云平台、其他服务。 场景3:K8S平台 可注入故障包括向K8S平台内容器、node和pod注入故障。 场景4:Java应用 可注入故障包括代码缓存爆满,内存不足,增加延迟,返回特定值,动态执行脚本,抛异常等。 适用平台 主机,CRI容器,K8S平台,Java应用,C++应用,阿里云平台,其他服务。 适用场景 需要向主机、CRI容器、K8S平台、阿里云平台、Java应用和C++应用注入故障的场景。 优势 支持多达7个故障注入场景。 劣势 网上的中英文文档描述过于简略。每个功能往往就一句话。只能把工具装上,运行起来,通过help参数,逆向工程来发现有什么功能。
CI/CD 动态性 支持运行时动态调整 需要重新编译 复杂度 高(分布式同步、持久化) 低(内存状态、线程局部) 故障类型 多样(失败、延迟、损坏等) 主要模拟操作失败 • Ceph 风格:用“命名的故障注入点 • 3FS 的故障注入框架基于 概率触发 + 作用域管理 的设计,通过 folly::RequestContext 实现跨协程的配置传递。 3fs设计特点 1 声明式 API: 通过 FAULT_INJECTION_SET(概率, 次数) 声明故障注入范围,具体故障类型由业务代码决定 2 RAII 自动管理: 利用 C++ 的 RAII 模式 FAULT_INJECTION_SET(10, 5) 是一个用于故障注入测试的宏,它会在当前代码作用域内设置故障注入参数: FaultInjection.h:16 • 第一个参数 (10): 表示故障注入的概率为 , 它本身不指定具体的故障类型(网络、服务或其) 具体注入什么故障取决于使用它的代码位置: 虽然 Rename.cc 本身不直接调用 FAULT_INJECTION(),但在实际运行中,故障注入会影响:
本小节演示如何通过故障注入来测试应用的弹性。 1. 创建一个故障注入的规则来延迟来自jason用户的流量。 Istio的故障注入规则可以帮助您在不影响最终用户的情况下识别这些异常。 4. 发送一个针对jason用户故障注入的HTTP终止类型 $ kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml
Chaos Mesh® 是基于 K8s 的混沌测试平台,而对于部署在物理机上的应用来说,混沌测试同样重要。 这么好的工具当然想亲手试一试,动手的时候发现:没有 K8s 环境用不了! 这是因为 Chaos Mesh® 是云原生的混沌工程测试平台,专门为 K8s 设计的。 故障类型丰富:在物理机的不同层次、不同类型上都提供了故障注入的功能,包括进程、网络、JVM、压力、磁盘、主机等,且更多的功能在不断扩展中。 更多的故障注入功能 目前 Chaosd 提供了进程、网络、JVM、压力、磁盘、主机总共六大故障注入功能,但是仍然需要继续拓展。 后续我们计划将 Chaos Mesh® 在 K8s 环境支持的一些故障注入功能在 Chaosd 中实现,包括 HTTP、IO 等。
作者:Alex Leong 应用程序故障注入(failure injection)是混沌工程(chaos engineering)的形式之一,我们在其中人为地增加微服务应用程序中某些服务的错误率,以查看这对整个系统有什么影响 传统上,你需要在服务代码中添加某种类型的故障注入库,以便进行应用程序故障注入。值得庆幸的是,服务网格为我们提供了一种注入应用程序故障的方法,而无需修改或重新构建我们的服务。 这允许我们以一种与实现无关、跨服务网格工作的方式进行故障注入。 为此,我们首先部署一个只返回错误的新服务。 当然,故障注入是一个广泛的主题,还有许多更复杂的方法来注入故障,包括某些路由故障、只匹配特定条件的请求故障或在整个应用程序拓扑中传播单个“毒丸”请求。 这些类型的故障注入将需要比这篇文章所涵盖的更多的设定。 Linkerd是一个社区项目,由CNCF(Cloud Native Computing Foundation,云原生计算基金会)托管。
黄坚,腾讯云容器服务 TKE 后台开发工程师,主要负责 K8s 控制面相关研发工作。 彭芳,腾讯云容器产品经理,主要负责 TKE 平台的产品能力建设和商业化工作。 背景 被忽视的风暴眼:控制面的全局风险 K8s 的中心化架构和声明式管理模式,在带来高效运维的同时也引入了链式故障扩散的致命风险。 而 K8s 集群的控制面组件 Master 承载着“大脑指挥官”的功能,一旦控制面发生故障,其爆炸半径往往波及整个集群,业务停摆风险指数级飙升。 执行演练:演练流程以 Argo Workflow 进行编排,包括故障注入、维持故障注入、故障恢复等主要步骤。 流程介绍 本节通过对 kube-apiserver 发起大量的洪泛 list 请求来实现 kube-apiserver 高负载故障注入场景演练,如下为 kube-apiserver 高负载故障注入 Playbook
提供了多个应用多个故障的任务流程编排,故障演练流程的控制的功能; Saltstack,chaosblade-operator 提供了 chaosblade 的安装和卸载能力; 应用的资源分为 KVM 和 K8S 4.1 故障演练 通过故障注入来模拟故障发生是混沌工程的基础能力。 在这个阶段主要提供 3 种场景的故障注入,机器关机,OS 层的故障,以及 Java 应用的故障注入,在此基础之上我们还做了场景化的功能。 于是我们中间件的同学进行了二次开发,增加了 AsyncHttpClient, QRedis 故障注入相关的插件,同时也针对 HTTP DUBBO 增加了基于调用点的故障注入功能。 做了如下几个方案选型: 方案 说明 优势 劣势 chaosblade-operator 完全采用开源方案,Agent安装和策略注入都使用CRD的方式 贴近云原生,CRD比较完善 控制端需要重新开发一套对接K8s
,或者对云上/云下的目标进行管理以及注入故障,都有相应的部署方案可以满足 丰富的故障注入能力,云原生混沌工程 由于蚂蚁集团对攻防演练的高度重视,促成了大规模高频率的演练活动,进而推动了各种各样的故障注入能力建设 用户层(Client) 用户层主要是由 chaosmeta-platform 组件构成,其主要任务是降低用户使用的门槛,提供可视化界面,方便用户使用计划、编排、实验配置、实验记录详情、Agent管理(k8s 集群的pod/node、跨集群对象、非k8s的物理机/容器等)等平台功能。 当前版本的能力 当前版本发布了:用户界面、故障注入调度引擎、度量引擎、流量注入引擎、单机故障注入工具等组件 用户界面 提供实验编排能力,降低使用门槛(当前版本的界面暂未支持流量注入类型和度量类型节点); 故障注入能力 系统资源异常:CPU、内存、网络、磁盘、进程、文件等; 内核资源异常:fd、nproc等; JVM动态注入:函数调用延迟、函数返回值篡改、函数抛出异常等; 容器故障注入:杀容器、暂停容器,
何时需要故障注入测试 需要解决的问题 如今的软件系统就像搭积木,一个小组件出问题,整个系统都有可能受到牵连。 故障注入测试的核心目标,就是未雨绸缪,在问题发生之前,通过模拟各种故障,提前找到薄弱环节,从而增强系统的健壮性。 故障注入 vs. 混沌工程 故障注入测试和混沌工程有相似之处,但侧重点不同。前者主要是验证特定的故障场景,后者则更像是“随性破坏”,故意制造混乱,观察系统能否自行恢复。 Kubernetes 下的故障注入 随着 Kubernetes 成为云时代的主流平台,如何在 K8s 上进行故障注入测试,成了一个重要课题。 故障注入测试的最终目标,就是打造这样的系统,让它在面对各种突发问题时,依然稳如泰山。