Netflix Chaos Monkey Upgraded
techblog.netflix.com
Netflix Chaos Monkey Upgraded
1–10 of 89 posts
Re: Netflix Chaos Monkey Upgraded
#2This is awesome. Since Chaos Monkey now leverages spinnaker you can run it against clouddriver provider. Looking forward to trying this out with kubernetes. I believe spinnaker treats namespaces as regions. Eventually it would be cool to simulate masters or other entire federated clusters going down to test kubernetes scheduling resilience
Re: Netflix Chaos Monkey Upgraded
#3It looks like it's working too well. The site is unreachable for me.
Re: Netflix Chaos Monkey Upgraded
#4It looks like it's working too well. The site is unreachable for me.
It's up.
Re: Netflix Chaos Monkey Upgraded
#5Another useful tool is https://github.com/gaia-adm/pumba - like ChaosMonkey, but just for Docker containers. The coolest part for us was emulating networking problems between containers (packet loss, unavailability etc).
Re: Netflix Chaos Monkey Upgraded
#6I wonder what the reasoning was for having version 2 only terminate instances (vs burning up CPU, taking disks offline, etc.)? I assume it's something to do with what Chaos Monkey is NOT trying to solve (ie. eating up CPU is caught elsewhere by another system and out of scope for Chaos Monkey now). Just trying to think it through...
Re: Netflix Chaos Monkey Upgraded
#7It looks like it's working too well. The site is unreachable for me.
down : Secure Connection Failed
The connection to techblog.netflix.com was interrupted while the page was loading.
Re: Netflix Chaos Monkey Upgraded
#8Has anyone else deployed a Chaos Monkey in production?
I can imagine it would be a tough sell to the CEO. :)
Re: Netflix Chaos Monkey Upgraded
#9Re: Netflix Chaos Monkey Upgraded
#10I wonder what the reasoning was for having version 2 only terminate instances (vs burning up CPU, taking disks offline, etc.)? I assume it's something to do with what Chaos Monkey is NOT trying to solve (ie. eating up CPU is caught elsewhere by another system and out of scope for Chaos Monkey now). Just trying to think it through...
I would assume that terminating is easy via the AWS API, whereas some of the other things need a process on the instance. You shouldn't really be connecting to boxes directly over SSH if you do DevOps correctly, so maybe they blocked port 22 to enforce this.