Initial sketch of --exec #104
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a proposal to introduce alternative means of killing pods, outside of simply asking kubernetes to stop them. Specifically, it allows executing a shell command on a victim container; that shell command can then be a simple kill -9, a fork bomb, or any other means of destruction. There are, at least, two reasons why this is useful. First, it gives an option of more realistic failures. Simply deleting a pod is a rather kind way to stop a pod - in reality a pod is likely to go down in flames from lack of memory, segfaulting or instant hardware failure. This brings the chaos closer to reality. The second reason is that this helps test operators that directly manipulate pods, rather than rely on higher-level concepts like StatefulSets, Deployments and so on. In this case, the thing we want to test is the operators ability to realize a pod is severely broken, and to take appropriate action, depending on what software the operator is running in the failed pod.
|
@jakewins I'll have a look this week. |
|
@jakewins sounds like a good idea. How do you want to deal with containers that don't support the command you specify in |
|
I think that abstracting the chaos action it's a good idea. However, different containers might need different |
|
I merged this PR with master and did my best to make everything compile correctly. Conflicts mostly included
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proposal to introduce alternative means of killing
pods, outside of simply asking kubernetes to stop them.
Specifically, it allows executing a shell command on a victim
container; that shell command can then be a simple kill -9,
a fork bomb, or any other means of destruction.
There are, at least, two reasons why this is useful. First,
it gives an option of more realistic failures. Simply deleting
a pod is a rather kind way to stop a pod - in reality a pod is likely
to go down in flames from lack of memory, segfaulting or instant
hardware failure. This brings the chaos closer to reality.
The second reason is that this helps test operators that directly
manipulate pods, rather than rely on higher-level concepts like
StatefulSets, Deployments and so on. In this case, the thing we want
to test is the operators ability to realize a pod is severely broken,
and to take appropriate action, depending on what software the operator
is running in the failed pod.
Note: These code changes contain a TODO and no tests; I stopped when I'd verified it worked, so I wouldn't spend more effort than necessary in case this is rejected. If y'all are keen to accept this in some form, I'm super happy to polish it up and add appropriate tests.
Let me know what you think!
Closes #103