kubethanos kills half of your pods randomly to engineer chaos in your preferred environment, gives you the opportunity to see how your system behaves under failures.
Table of Contents
- Other Similar Projects
- Code of Conduct
kubethanos.yaml file for an example run. Here are the list of valid parameters:
--namespaces=!kubesystem,foo-bar // A namespace or a set of namespaces to restrict kubethanos --included-pod-names=<pod(s)_will_be_selected_if_pod_name_contains_this_string> --node-names=<pod(s)_will_be_selected_if_they_reside_in_given_node_names> --excluded-pod-names=<pod(s)_will_be_excluded_if_pod_name_contains_this_string> --master // The address of the Kubernetes cluster to target, if none looks under $HOME/.kube --kubeconfig // Path to a kubeconfig file --healthcheck // Listens this endpoint for healthcheck --interval // Interval between killing pods --dry-run // If true, print out the pod names without actually killing them. Defaults *FALSE* --ratio // ratio of pods to kill. Default is 0.5 --debug // Enable debug logging.
Pods to kill will be searched with a top-down approach. Node(s) first Pod(s) later.
Configure kubernetes readiness & liveliness probes to
Other similar projects
- Thanks to @linki chaoskube for giving me the idea and having written something with a broader scope.
- You are responsible for your actions. If you break things in production while using this software I cannot help you to restore the damage caused.
Any contributions are welcome! Please see the contributing file for details.
Code of Conduct
Please check the code of conduct page for efficient collaboration and communication.
This project licensed under MIT.