Chaos Mesh 如何助力 Apache APISIX 提高系统稳定性
Apache APISIX 是一个高性能、可扩展的微服务 API 网关。它是 Apache 软件基金会的顶级项目之一,为全球数百家公司提供服务,处理其关键任务流量,包括金融、互联网、制造、零售和运营商。客户包括美国宇航局、欧盟数字工厂、中国移动和腾讯。
随着社区的发展,Apache APISIX 的功能会更频繁地与外部组件交互,从而使我们的系统变得更加复杂并增加了出错的可能性。为了识别潜在的系统故障并建立对生产环境的信心,我们引入了混沌工程的概念。
在这篇文章中,我们将分享如何使用 Chaos Mesh® 来提高的系统稳定性。
痛点
Apache APISIX 每天处理数百亿个请求。在这个级别,用户注意到了几个问题:
场景#1:
在 Apache APISIX 的配置中心,当 etcd 和 Apache APISIX 之间出现意外的高网络延迟时,Apache APISIX 还能正常过滤转发流量吗?
场景#2:
当 etcd 集群中的某个节点出现故障,集群仍能正常运行时,该节点与 Apache APISIX admin API 交互报错。
虽然 Apache APISIX 已经通过持续集成(CI)中的单元测试、端到端(E2E)和模糊测试覆盖了很多场景,但还没有覆盖与外部组件的交互场景。如果系统出现异常,例如网络抖动、硬盘故障、进程被杀等,Apache APISIX 能否给出相应的错误信息?它能否继续运行或自行恢复正常运行?
为什么我们选择 Chaos Mesh
为了在我们的产品投入生产之前测试这些用户场景并发现类似的问题,我们的社区决定使用 Chaos Mesh 进行混沌测试。
Chaos Mesh 是一个云原生的 Chaos Engineering 平台,针对 Kubernetes 上的复杂系统提供全方位的故障注入方法,涵盖 Pod、网络、文件系统甚至内核中的故障。它帮助用户发现系统中的弱点,并确保系统能够抵抗生产环境中的失控情况。
与 Apache APISIX 一样,Chaos Mesh 也有一个活跃的开源社区。我们知道一个活跃的社区可以确保稳定的软件使用和快速迭代。这使得 Chaos Mesh 更具吸引力。
如何在 APISIX 中使用 Chaos Mesh
混沌工程已经超越了简单的故障注入,现在形成了一个完整的方法论。为了创建混沌实验,我们确定了应用程序的正常运行或“稳定状态”应该是什么。然后我们注入潜在的问题,看看系统如何响应。如果问题使应用程序脱离稳定状态,我们会修复它们。
现在,我们将通过我们提到的两个场景向您展示我们如何在 Apache APISIX 中使用 Chaos Mesh。
场景#1
我们使用以下步骤部署了混沌工程实验:
-
我们找到了衡量 Apache APISIX 是否正常运行的指标。在测试中,最重要的方法是使用 Grafana 来监控 Apache APISIX 的运行指标。我们在 CI 中从 Prometheus 中提取数据进行比较。在这里,我们使用每秒路由和转发请求 (RPS) 和 etcd 连接作为评估指标。我们分析了日志。对于 Apache APISIX,我们查看了 Nginx 的错误日志,以确定是否有错误以及错误是否符合我们的预期。
-
我们在对照组中进行了测试。我们发现 create route 和 access route 都成功了,我们可以连接到 etcd 并记录 RPS。
-
我们使用网络混乱添加了 5 秒的网络延迟,然后重新测试。这次 set route 失败, get route 成功,etcd 可以连接,RPS 和之前的实验相比没有明显的变化,实验符合我们的预期。
场景#2
我们在对照组中进行了与上述相同的实验后,我们引入了 pod-kill 混沌并重现了预期的错误。当我们随机删除集群中的少量 etcd 节点时,APISIX 有时可以连接到 etcd 有时不能,并且日志打印了大量连接拒绝错误。
当我们删除 etcd 端点列表中的第一个或第三个节点时, set route 正常返回一个结果。但是,当我们删除列表中的第二个节点时, set route 返回错误 connection refused.
。
我们的故障排除表明,Apache APISIX 使用的 etcd Lua API 是按顺序而非随机选择端点的。因此,当我们创建一个 etcd 客户端时,我们只绑定了一个 etcd 端点。这导致了连续失败。
在我们修复了这个问题之后,我们在 etcd Lua API 中添加了健康检查,以确保不会将大量请求发送到断开连接的 etcd 节点。以及增加了 etcd 集群完全断开连接时的回退检查,避免大量报错冲爆日志。
未来的计划
在端到端模拟场景中运行混沌测试
在 Apache APISIX 中,我们手动识别系统弱点以进行测试和修复。和在开源社区一样,我们在 CI 中进行测试,所以我们不需要担心 Chaos Engineering 的故障半径对生产环境的影响。但测试无法覆盖生产环境中复杂而全面的应用场景。
为了覆盖更多的场景,社区计划利用现有的 E2E 测试来模拟更完整的场景,进行更随机、覆盖范围更大的混沌测试。
向更多 Apache APISIX 项目添加混沌测试
除了为 Apache APISIX 寻找更多漏洞外,社区还计划为更多项目添加混沌测试,例如 Apache APISIX Dashboard 和 Apache APISIX Ingress Controller。
向 Chaos Mesh 添加功能
当我们部署 Chaos Mesh 时,一些功能暂时不受支持。例如,我们不能选择一个服务作为网络延迟目标或将容器端口注入指定为网络混乱。未来,Apache APISIX 社区将协助 Chaos Mesh 添加相关功能。
推荐
随手关注或者”在看“,诚挚感谢!
- 供应链攻击:保护软件供应链的 6 个步骤
- Docker 安全最佳实践和备忘单
- 2021 OWASP Top10 有什么新变化?
- 解决 K8s 落地难题的方法论提炼
- 我们如何通过升级文件系统节省数百万 SSD 成本
- 为什么云中的容器可以成为攻击者的天堂
- 如何诊断内存泄漏|有趣的垃圾回收
- Java容器化参数配置最佳实践
- DNS 故障诊断及问题分析示例
- 我是如何完成从 Scala 到 Go 过渡的?
- 为什么以及如何从命令行使用 containerd
- Golang标准库和外部库的性能对比
- 什么是标准容器(2021 版)
- 限制K8S Pod 磁盘容量使用的 3 种方法
- 基于网络抓包实现K8S中微服务的应用级监控
- 单元测试最佳实践|如何避免常见陷阱?
- Chaos Mesh 如何助力 Apache APISIX 提高系统稳定性
- 星巴克不使用两阶段提交
- 关于服务兼容性设计一点思考
- BeyondProd:云原生安全的一种新方法