Presently the tests for pod and service disruptors use one of the following approaches:
Use a fake kubernetes client that simply creates objects but does not emulate their behavior (for example, the execution of a pod) because it does not contain any control plane
A test cluster (using kind or k3s) that runs a completely functional control plane and workers, emulating cluster nodes using containers
However, the node disruptor is intended to affect the "physical" nodes of a cluster by consuming resources, disrupting the network traffic, or executing other actions (e.g. rebooting the node).
All these actions are hard to emulate in test clusters. For example, setting memory and CPU resources to be allocated to each "node".
Therefore, we need a strategy for running tests on a "real": cluster that allows to to measure the impact of the disruptions in terms of resource usage, network traffic, and other possible effects.
Presently the tests for pod and service disruptors use one of the following approaches:
However, the node disruptor is intended to affect the "physical" nodes of a cluster by consuming resources, disrupting the network traffic, or executing other actions (e.g. rebooting the node).
All these actions are hard to emulate in test clusters. For example, setting memory and CPU resources to be allocated to each "node".
Therefore, we need a strategy for running tests on a "real": cluster that allows to to measure the impact of the disruptions in terms of resource usage, network traffic, and other possible effects.