-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does chaoskube really kill the pods? #103
Comments
This is a very good question. I also assumed that chaoskube was killing the pods. I think killing a pod instead of terminating it is be the best option, because "graceful shutdowns" rarely happen on production environments :) Would it be possible to at least include a flag to choose the behaviour you want (kill vs terminate)? I'm thinking about adding a configurable |
@ljanatka @palmerabollo I agree. There's already a pull request for it by @jakewins: #104. It would help me a lot if you would also have a look and leave some feedback. |
@ljanatka I just fixed it in case you want to give it a try again. |
@linki Hi, we finally got to give it a try. |
@ljanatka Thanks for checking it out! |
@linki Hi, was my test enough to merge this "hardkill" feature into new version of chaoskube? When do You expect the new version to be released? |
@ljanatka I'm not sure. I want to refactor it a bit before merging and I have a work-in-progress branch for it. @jakewins has a fork of chaoskube where this is merged. You could try using it in the meantime. |
Hi @linki from the release notes it seems that chaoskube now can "hardkill" the pods. However I did not find any switch that would activate this feature. Or is the hardkill now implemented as default kill method? Thanks! |
Hi @ljanatka, https://github.com/linki/chaoskube/releases/tag/v0.12.1 extracted the current strategy into a separate object behind an interface in order to make it easier to add more ways to terminate a pods. The actual "termination-by-kill" termination strategy from the original PR hasn't been ported over yet. |
It's been quite awhile now since this feature was requested and I see some refactoring was done. Is there any chance this could be looked at again soon? |
Hi Martin,
I am currently working on a project where we are trying to improve reliability of our software via using chaos engineering (but, unfortunately, have a very little experience with it). Currently, our software runs on Azure/Kubernetes.
We found chaoskube as a promising tool to help us, but we found out, that it's behavior is different than expected. In the description of chaoskube, there is an information that it kills the pods, so I created a hypothesis about what will happen when one of our pods will just be dealing with a request when it is killed (there should be an error response and next requests should be processed by the other pod). When I started the experiment, the pods were killed but no error occured.
Then one of my colleagues looked in the source code of chaoskube and found out, that the pod is not killed (i.e. force killed instantly), but rather terminated (if I got it correctly, then by using this approach, the pod finishes dealing with it's current task and then "dies" peacefuly).
Is this really how chaoskube works?
We are learning more about chaos every day, but there is a lot of knowledge that we need to gain.
Since my hypothesis was probably wrong, I would be really graceful for any advice about what other chaos experiments is chaoskube suitable for.
Thank You,
Ladislav
The text was updated successfully, but these errors were encountered: