Chaos Engineering/Fault Injection

[howardjohn]

What would you like to be added:

An API to inject faults into routes. Typically a fault may be a delay, an HTTP response, or others.

Why this is needed:

Fault injection / Chaos engineering is a somewhat common engineering practice to intentional introduce errors into the system to simulate disaster recovery and other reliability mechanisms.

Prior art:

• Istio

Slightly related to #2826

[shaneutt]

How do you see this being implemented, as a testing library that we provide to implementations or just an API?

[howardjohn]

No, just a HTTPRoute filter or policy. Like https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPFaultInjection, for example. Then users or tooling can utilize that to build a holistic chaos engineering strategy

[shaneutt]

No, just a HTTPRoute filter or policy. Like https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPFaultInjection, for example. Then users or tooling can utilize that to build a holistic chaos engineering strategy

Ok, just wanted to be sure. The API specification for this sounds good, but the reason I asked about test libs is that I wouldn't be opposed to discussing having some standard "Gateway API Fault Injection" tooling. 🤔

In any case, I'm supportive of further discussing and working towards a proposal here.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale