charts

Mostly the answer is "if you want to do it all yourself, go for it"; Things like this, and especially Kubernetes, are about creating a common and agreed upon language for infrastructure - both patterns and specific "off the shelf" applications It's very nice to be able to start a Proof of Concept data pipeline with `helm install incubator/kafka` (https://github.com/kubernetes/charts/tree/master/incubator/k...) And likewise the common language/interface creates opportunities for wider coverage and easier adoption in tooling for monitoring, autoscaling, smart routing (see "service mesh"es), etc. You may not need all of k8s functionality immediately but it's the agreed upon common core for modern distributed systems functionality And to everyone's credit it's also being done pretty much as modularly and extensiblely as we could hope for

For figuring out how to write pod and service specs - I really like looking at the Helm Charts source code: https://github.com/kubernetes/charts/tree/master/stable (Helm aims to be a package manager for kubernetes, and its packages are called Charts)

Kubernetes is a more robust tool and has a great community around it. For example https://github.com/kubernetes/charts. You can launch any of these applications in one line https://github.com/kubernetes/charts/tree/master/stable https://github.com/kubernetes/charts/tree/master/incubator and then very easily tweak them.

Yes! KubeApps.com is a running public instance of Monocular that indexes the official Kubernetes charts repositories (https://github.com/kubernetes/charts). To find out more about Monocular, here are some blog posts: - https://engineering.bitnami.com/2017/02/22/what-the-helm-is-... - https://deis.com/blog/2017/building-a-helm-ui/

This is a really great post, excited to give the OAuth 2 auth a try. FWIW, an easier way to get started with the NGINX Ingress and kube-lego services is using the official Helm[1] Charts for them (https://github.com/kubernetes/charts/tree/master/stable/ngin... and https://github.com/kubernetes/charts/tree/master/stable/kube...). [1] https://github.com/kubernetes/helm

I think Helm [1] looks promising in this regard. Helm "charts" are templates that generate Kubernetes manifests. To install a chart, you provide values (for which there are defaults). For example, here [2] is the chart for PostgreSQL. The default values are in values.yaml, and the templates for each manifest are in the templates folder. Conceptually, this even cleaner than Docker Compose, because there's zero data that isn't specific to your install: Everything else defaults to a pre-defined default. So in the same way that the official PostgreSQL Docker image is general-purpose, you can define a completely general-purpose chart that can be used by anyone. You customize it by providing overrides. The only downside is that you still end up with Kubernetes manifests. It's not an abstraction, it's an automation tool. [1] https://helm.sh [2]

With 16 x 8TB drives, we are talking about 64TB usable space after erasure coding. Minio is designed to serve the needs of a single tenant - 64TB is usually much bigger than a single tenant's needs. However you often see 100s of thousands of such tenants in a cloud like environment. Making a single large PB sized volume where the disks and nodes are managed like a blackbox by the filesystem is quite scary to us at Minio. Any crash means we blew up all the tenants at once. 1000s of individual Minio tenants means, we know when we add the million'th minio instance, it is not any more complex than the first instance of Minio. Provisioning with k8s [1], mesos [2] or other external orchestration tools is better than Minio's own resource management system. When it comes to the applications, objects are just represented as URLs. Some data sitting