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

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.