import site.body

The Kardashev scale of containers

This Post is a draft of information that is being prepared for a rewrite of doger.io. It attempts to Categorize the different types of container solutions in a course grain manner in order to quickly convey they scope of management that the container solution provides.

'Containers' is a catch all term for a wide variety of technologies and implementations that are all operating at different levels of management. Understanding where a container implementation fits in terms of management and what your own requirements are in terms of this management makes it easier to discuss and compare solutions for your container deployment of contaienr implementation.

There are some clear indicators in terms of the scale of management and features that distinguish container implementations. The list below is an attempt to define these attributes to make classifying implementations consistent when discussing them. This scale below is based off the Kardashev scale used to classify galactic civilisatsionts and is worth reviewing if you are unfammilar with the original scale.

No attempt has been made to make a perfect scale, the relative values matter more and the topology of the decisions of any 2 solutions that are similar should be complex enough to warrant investigation by human hands and not mathematical methods.

It is important to understand your own requirements, A type 2 Solution is not Superior or better (for whatever metrics this implies) than a Type 1 for Type 1 style operations. Indeed there may be additional overhead associated with the management at the Scale of Type 2 that makes usage as a Type 1 solution less than ideal for day to day operations.

Container Scale

  • Type 0.5: Capable of starting an container, stopping and management of startup/shutdown is unimplemented (eg chroot).

  • Type 1: capable of starting/stopping a container (ie managing a server/managing its lifecycle).

  • Type 2: Program capable of managing several containers on a single machine (may fork off responsibility of lifecycle to a separate program, eg manager of managers).

  • Type 3: Program capable of managing containers across several machines (may fork off responsibility for a single machine to a separate program).

  • Type 4: Currently unknown and debatable if this level needs to be defined, it suggested that this be reserved for cross provider implementations (implementations that can manage several different container solutions eg AWS, GCE and an on premise Kubernauts implementation).

Additional Classifications

When composing the scale an attempt was made to avoid 'features' and focus on implementations 'reach' (trying to avoid the word 'scale' here as we are using it in 2 different contexts) however there are some features deserving of their own scale as they are both important to users and part of most implementations.

In an attempt to differentiate these features and their levels, different characters have been chosen and can simply be appended to the type above when used in normal conversation eg:

I was working with a type 3a- solution the other day, and while nice it was 
missing some functionality

The above statement quickly shows from its type code that while it is for managing a large number of systems, 2 of its other features are very restrained in their scope (in this case image management and security as defined below)

The First feature that is commonly seen along side containers is image management. It is very easy to divorce this responsibility from the container 'at scale'/lifecycle managment utility and have it only invoked once as part of setup. Some implementations delegate this responsibility to a separate program while others make it part of the utility or management daemon itself. As a significant number of articles that the author has seen have made very little distinction between this responsibility , there appears to be utility in giving it its own code for the purposes of quick identification and differentiation in discussions.

Image Provisioning Scale

  • Type A: Builds images from scratch each time.

  • Type B: Can Reuse existing images as is (ie cant mutate them, change files etc).

  • Type C: Can Reuse existing images and modify them according to instructions.

  • Type D: Can stitch together multiple images to form a cohesive final image (overlays).

Integrity of files has proven to be an aspect of containers that attracts a lot of attention. One aspect of container security that proves easy to class and has proven to be an issue in the past is one of signature verification in container images. A general scale for this aspect is provided below.

'Artifacts' as used below can mean different things in different contexts, a quick guide is provided below but is by no means authoritative (and in some contexts what does or does not apply may change). If in doubt please read twice and seek professional security expert advice.

Does include: * per container config files that represent the running container * Container Images * Metadata

Does not include: * Container management binaries * System wide configuration

Artifact Integrity Scale

  • Type -: Does not verify artifacts with signatures.

  • Type +: Verifies some or more artifacts with signatures.

  • Type #: Verifies all artifacts with signatures.

It would be easy to expand the type codes to cover more aspects however the problem space has high dimensionality. The above Categories have proven sufficient in categorizing the implementations on doger.io and at a glance explain how they are vary from each other.

This is a draft article for the final information that will appear at doger.io and as such Feedback is welcome via twitter or email (see doger.io for contact information). I hope to refine this into a useful scale that is referenced in discussion online.