Explain to me like I'm five Kubernetes and infrastructure as code

As an extension of my original post where I asked “Explain to me like I’m 5, why I should use Docker locally

Why should I take things “next level” and go learn and use a technology like Kubernetes, and apply it to infrastructure as code.

From my quick review of this topic, not only do I leverage Docker containers (or any container technology it seems) but I leverage Kubernetes, and something like helm to get my kubernetes setup up to par with what I have setup in my code. So far it seems like throwing more abstractions on top of abstractions, and seems like a lot to learn and kinda overkill.

So explain to me like I’m five the sort of benefits one would see using these sorts of technologies and problems they solve. (And potentially what kind of problems these introduce haha)

To answer every thing in a nutsell for you.
You don’t seem like an idiot and, seem to have done your reachers well enough to make a capble desision on your own.

As you are a Linux usser I am sure you mastered the art of finding alternatives for software programma’s. I get that you want to extend your reachers and want some second opinion here but, it seems like you are over thinking every thing here. Have some confidence here in yourself and just go for it. You can alway’s chance your software programma’s later onto.

It is. But. Say you have a large, complex application split into many parts over a network. All of those parts are individual containers. What you ideally want is

  • all those components to communicate: they will do this over network sockets, each with a port address.
  • if any of those parts fail, you want to restart them easily.
  • if any of those parts fail catastrophically and their internal state becomes corrupt, you want to completely blow them away and rebuild.
  • if something’s going slow or whatever, probs just blow it away and rebuild it.
  • for persistant storage, you probably want replication plus supervisor applications to monitor the storage for issues, so’s you can do the same thing: just blow it away if there’s a problem.
  • if you update the code for one of your containers, you want to completely blow the current version away and rebuild.
  • tl/dr is there problem? Kill the container and rebuild it (This is exactly the same principle as switching your computer (or your TV or microwave or whatever) off and on if there’s an issue). Just wipe everything to last good state, crash it, that’s how you get reliability

This raises several issues.

  • how do you manage inter-app communication?
  • how do you ensure that you can take down parts of this monstrosity without bringing down the whole system?
  • how do you, in a sane manner, build all of the apps correctly?
  • how do you safely and sanely take everything down in a controlled manner and boot everything back up?
  • if something does go down, how do you manage strategies for what else needs to be taken down or what else can stay up and running?
  • how do you share things that need to be shared (env vars maybe?) between your apps?
  • how do you view the collection of individual containers as one discrete thing?
  • if you rebuild, you gotta have a new port address. If you have a new port address, you lose communication with the rest of the overall system. How do you manage this problem dynamically?

(Note: caveat before I get asked for any technical details most all DevOps stuff makes me want to gouge my eyes out, so this just comes for a. working for a while with Kubernetes and b. using Erlang which basically works like a self-contained Kubernetes cluster. I myself have never built or configured any Ks stuff (despite very optimistically buying the Manning books on Docker & Kubernetes). That was all built and configured by the DevOps person I sat next to. I know how it hangs together but I never actually want to use it directly thx


Kubernetes is to whole clusters what Docker is to individual systems. I could go on, but @DanCouper already said it all better, and I’m in one of my more pithy/glib moods besides.

My current decision is to learn more about the technology as I know I don’t know enough to make an informed decision to commit myself to learning this sort of stuff. Heck at this point I’m on the fence that my current setup of using more PaaS offerings instead of “building my own platform” using Kubernetes. I half want people to convince me its a good idea to learn and use, and half want them to say “meh”.

As a dev that needs to play with ops, ops has to be pretty damn easy for me to go out and use and learn it, otherwise its just getting in the way. This doesn’t go for just Kubernetes, even if I’m a Linux user, I want things to be easy so I can focus on building the stuff, rather then supporting it.

But this post isn’t just about me, its about just getting a conversation about Kubernetes going for the average dev/person so anyone can jump in ask, or comment even if they have only a limiting understanding of the subject, odds are they still know more then a “five year old” haha

I’d say you’re better off playing with docker-compose before jumping straight into Kubernetes. K8S is almost a superset of it.