
Supergiant.io – Container Platform for Stateful Applications - elsalgo
https://www.infoq.com/news/2016/05/supergiant-container-platform
======
jamescun
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...](http://kubernetes.io/docs/user-
guide/volumes/#awselasticblockstore)

~~~
m1johns
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.

------
soamv
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?

~~~
m1johns
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 :-)

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

See
[https://github.com/kubernetes/kubernetes/issues/260](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.

------
asadlionpk
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.

~~~
m1johns
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..

------
confusedjs
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?

