You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently, when creating a PodDisruptor, all pods that match the pod selector become targets of the subsequent fault injection(s).
However, there are cases in which it would be convenient to limit the fault injection to a subset of pods. For example
To simulate faulty instances in a deployment (typical of a canary release or rolling deployment)
To simulate an under-performing instance and validate if requests are correctly load-balanced
The initial idea, aligned with the design of the selector API could be to add a limit attribute to the pod selector, that allows defining a maximum number of pods to be selected. For example:
selector={select: {labels: {...}}limit: 1}
However, in some cases, a percentage of the pods could be more convenient (for example, when the number of replicas varies):
selector={select: {labels: {...}}limit: '20%'}
One open question in this proposal is how to limit the number of targets for a ServiceDisruptor, as it does not consider a selector.
Note: Having arguments that allow multiple types of values is not uncommon in Kubernetes (for example, disruptor budget) but this is not necessarily a requirement for the API, just an example of the concept.
The text was updated successfully, but these errors were encountered:
Presently, when creating a
PodDisrupto
r, all pods that match the pod selector become targets of the subsequent fault injection(s).However, there are cases in which it would be convenient to limit the fault injection to a subset of pods. For example
The initial idea, aligned with the design of the selector API could be to add a
limit
attribute to the pod selector, that allows defining a maximum number of pods to be selected. For example:However, in some cases, a percentage of the pods could be more convenient (for example, when the number of replicas varies):
One open question in this proposal is how to limit the number of targets for a
ServiceDisruptor
, as it does not consider a selector.Note: Having arguments that allow multiple types of values is not uncommon in Kubernetes (for example, disruptor budget) but this is not necessarily a requirement for the API, just an example of the concept.
The text was updated successfully, but these errors were encountered: