Google, Red Hat Work on a Way for Kubernetes to Run Containers Without Docker

What we collectively refer to as "containers" and software like Docker are just tools that take advantage of various facilities provided by the OS which allow one to isolate/restrict various resources like CPU, memory, network, visibility of other processes, filesystem access, fs layering and namespacing, provide traffic shaping, etc.

These isolation features go back a really long time in various OS's, but only in the last few years have they seen mass adoption, which, alas is running a bit ahead of any effort to make it a formal standard or anything even close to that.

And so the way you would create a "container" on Linux is very different from the way you'd do that on FreeBSD or Solaris or Windows. Docker was one of the first pieces of software to facilitate that on Linux (where it was and still is far from trivial), along with the whole docker image dockerhub ecosystem, etc. But ultimately what Docker does amounts to the right commands (or system calls) done, and you can have the same effect without Docker (there's even a nice Docker talk on youtube somewhere that shows how to do what Docker does without it from the command line).

IMHO in the developer community at large few people care to understand the operating system intimately, and even fewer people know stuff like cgroups or the tc command on Linux, and that's primarily why Docker is so popular - you don't need to know any of it.

I think it'd be nice if people stopped using "Docker" and "container" interchangeably, and if a set of tools emerged which would be more part of the OS distribution and less a separate concept/brand/company/whatever and was more or less uniform across, at least the Un*x-like OSs.

Since this has turn into a generic "What's up with containers" post:

What is wrong with LXC/LXD/Juju by Ubuntu?

I haven't used that latter two (I haven't taken the time to learn them) but LXC is a breeze. Set up a bridge on a host, and start creating containers! Isolated, with resource management capabilities available. LXD is the orchestration at scale component.

It's Linux specific, and it's more of a lightweight VM than a one-click-app like Docker images seem to be. Maybe that's the difference.

LXC is great, I agree. Some of Docker's big win is from its composability of images. If appc/rkt can do this (do they already?), I think they will capture a lot of Docker's momentum.

> These isolation features go back a really long time in various OS's, but only in the last few years have they seen mass adoption, which, alas is running a bit ahead of any effort to make it a formal standard or anything even close to that.

Also containers really didn't get very secure until Google started upstreaming various patches and updates to the kernel's cgroups[0].

The way docker runs containers is very different than then the way (I assume) Google does it. In a strange twist a fate Google did a lot of he grunt work to make containers safe and useable but then a another tool came to market and made containers ubiquitous.

[0] https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.t...

2015: stateless Ruby on Rails web pods and sidekiq pods inside Kubernetes. Redis and Postgres provided by AWS Elasticache and Postgres. The single cluster served two customer facing apps and a single, centralized authentication for users that supports both apps.

This was K8S 1.1, before DaemonSet and PetSet.

On the production machines, I ended up provisioning two different node types -- one with burst cpu shares and one with fixed cpu shares. I had to use node labelling. The web workers were sensitive to spikes in traffic and the background workers ate up all the available cpu, and shouldn't be shared with the web workers.