If Docker containers are like the individual players in a orchestra, Kubernetes is the Conductor.

Here's the Wikipedia description: Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation.

Kubernetes is for big systems. For a simple web server, one might deploy a single Docker container with an HTTP server written in Go. That's what I do, because I'm small and my needs are simple. But what if (God forbid) I started getting millions of hits per minute? How would I handle such a thing?

In ancient times (2010), I'd probably set up a rack of Linux servers running Nginx, web content perhaps served from a database or three, and a hardware load balancer like F5, while monitoring traffic and scaling as needed by adding hardware in the dinosaur room.

How things have changed. Today, I'd set up an account with AWS, Google, Rackspace, Cloudfare, etc., populate a virtual Linux box with Docker containers, and set up Kubernetes to manage the resources, including load balancing. It can do much more though, like spinning up more containers as needed and tearing them down again.

My own needs for Kubernetes are limited to daydreams of grandiosity, except to learn, play and try things out. There is a nice little tool called Minikube that is made just for local use, and I love playing with it.

At the time of this writing, I'm setting up an HP Enterprise ProLiant blade server that I picked up on the surplus market dirt cheap. It has two Intel Xeon CPUs and 72GB of memory and a RAID controller, so it's not your average pee cee. My plan is to install Linux (probably Arch) with KVM and Qemu, and use it for virtual machines of various types. This will give me a chance to make better use of Kubernetes, among other things.

Stay tuned for updates.

Would you like to work with me using Kubernetes? Let me know.