Supergiant's docs suggest they are using Kubernetes but have their own mechanism for utilising Amazon EBS as persistence. Kubernetes already has such functionality[1], so it seems unclear what functionality they have added on top of Kubernetes.

I am however pleased that more people are considering using a traditional SAN (or SAN like service) for data persistence in containers as opposed to migrating actual data volumes.

[1] http://kubernetes.io/docs/user-guide/volumes/#awselasticbloc...

So our main focus with Supergiant is to optimize the hardware cost under your Kubernetes cluster. Our initial goal at qbox.io was to lower our hosting costs for our customers. Kubernetes was the obvious choice for us. We ended up over time writing so many augmentations to the vanilla Kubernetes build, that we ended up with a "plugin" for Kube we called Supergiant. This is what we ended up releasing to the wild. Under Supergiant, normal Kubernetes is still in play, as a matter of fact, you can use the CLI to “import” an existing Kube and deploy the Supergiant core to it. The CLI can also be used to manage (install, delete) Kubernetes clusters for you, even if you have no intention of using Supergiant.

As to your specific comment about storage augmentation from vanila Kubernetes. We needed to run stateful DB type apps (Elasticsearch) which require persistent storage for each node in the cluster. This is doable in vanilla Kube, but requires a weird setup with multiple replication controllers. (The Kubernetes team is currently working to get past this limitation.) This can be time consuming and not very easy to understand for a user less experienced with Kubernetes. Our augmentation basically allows you to specify a Supergiant component (collection of services, RCs, and pods) with a volume blueprint. When you increase the number of instances of your component, (Elasticsearch cluster nodes.) the Supergiant API will take care of all the replication controllers, and volume mounts. Our work around volumes is less about being a huge feature, and more about our approach to fixing a tough concept in Kubernetes.

I read the article and the linked blog and I still can't tell what this has over plain Kubernetes deployed on AWS -- what am I missing?

> Storage for applications deployed on Supergiant is allocated on high-availability arrays, however, it does not use Kubernetes' persistent volumes. Currently available on AWS, Supergiant uses Amazon's Elastic Block Store (EBS) so that volumes can move freely around the cluster.

Kubernetes has EBS support, right? What does Supergiant do better here?

Hi, please refer to the response above to "jamescun". While we do slightly augment a few features of Kubernetes, our main focus is lowering hardware cost, and providing an additional approach to understanding Kubernetes objects.(In an easy way, for new Kubernetes users.) We will be creating additional blog posts over the next few days to describe how we do this. A very advanced user may be totally comfortable using vanilla Kubernetes. Please let me know if you have more questions. Our slack channel is also listed on our website, and we would love to hear your feedback :-)

Kubernetes has a "PetSet" proposal that looks like it has some overlap with Supergiant.

See https://github.com/kubernetes/kubernetes/issues/260 For the details, but the gist (as I understand it) is to support applications that depend on state and ordinal identification of nodes. So for example, a PetSet will keep a master database node and it's persistent data together.

I still have to read more about this but shouldn't mounting EBS to docker container as external volume (using -v docker flag) give us similar effect?

Also, who handles application based conflicts when two same 'component' containers try to write on same volume (as they are exactly the same just replicated). I hope I am not being naive.

So, Kubernetes will not allow more then one pod (Collection of containers) to mount the same persistent volume (* in most cases, exceptions with some types of network storage.) Supergiant goes a step further and automatically ensures that multiple managed pods are provided with storage based off of a volume blueprint. This is all to say, that Kubernetes, and Supergiant automate the "-v" operation for you. Very useful when spinning up thousands of containers, then herding the cats..

I see him deploy one etcd container and claim he has deployed an etcd cluster. Is that a cluster of 1 or am I missing something?