虽然Envoy sidecar/proxy为在Istio上运行的服务提供了大量故障恢复机制,但测试整个应用程序端到端的故障恢复能力依然是必须的。错误配置的故障恢复策略(例如,跨服务调用的不兼容/限制性超时)可能导致应用程序中关键服务持续不可用,从而导致用户体验不佳。
Istio启用协议特定的故障注入到网络中,而不是杀死pod,延迟或在TCP层破坏数据包。我们的理由是,无论网络级别的故障如何,应用层观察到的故障都是一样的,并且可以在应用层注入更有意义的故障(例如,HTTP错误代码),以锻炼应用的弹性。
运维人员可以为符合特定条件的请求配置故障。运维人员可以进一步限制应该遭受故障的请求的百分比。可以注入两种类型的故障:延迟和中止。延迟是计时故障,模拟增加的网络延迟或过载的上游服务。中止是模拟上游服务的崩溃故障。中止通常以HTTP错误代码或TCP连接失败的形式表现。
有关详细信息,请参阅Istio的流量管理规则。