[skboosh]

A major problem I've seen using Kubernetes is it's difficult to bring up an entire cluster from scratch, play with it and tear it down. So I wrote Sugarkube [1] which lets you launch an ephemeral cluster, install all your applications into it (including creating any dependent cloud infrastructure) and tear it down again. This means each dev can have their own isolated K8s cluster that's in parity with production. And you can release the same code through different environments. In fact your prod environments can become ephemeral too - instead of doing complicated in-place upgrades you could spin up a sister cluster, direct traffic to it and then tear down the original. Or you could spin up a cluster to test the upgrade before repeating it in your live environment.

Based on my own experience I believe ephemeral clusters can solve a huge number of problems dev teams face using Kubernetes.

Sugarkube currently supports launching clusters using Minikube, EKS and Kops and we'll be adding provisioners for GKE and Azure in future. Sugarkube also works with existing clusters, so you can use it deploy your applications. It's a sane way of managing how to ship infrastrucuture code (e.g. Terraform configs) with your applications that need them.

Sugarkube also supports parameterising applications differently per environment - you could almost view it as something like Ansible but that was written with Kubernetes in mind. And it's in Go so it's way faster than Ansible (an early POC was actually written in Ansible and it was very slow).

I've just finished intro tutorials for deploying Wordpress to Minikube [2] and EKS [3]. I'd be keen to hear feedback. We just tagged our first proper release earlier this week and it's ready to try now.

[1] https://docs.sugarkube.io/introduction/ephemeral-clusters/

[2] https://docs.sugarkube.io/getting-started/tutorials/local-we...

[3] https://docs.sugarkube.io/getting-started/tutorials/dev-web/

[vitalus]

I definitely agree with you - my team switched to an "ephemeral cluster" model which allows us to very quickly spin up an entirely new cluster and drain traffic to it as needed.

It's something that we've ended up implementing on our own with a lot of Terraform, but that's had its own obstacles and is something of a small maintenance burden. I'll be taking a look at sugarkube!

[skboosh]

Awesome. If you need any help or if anything's unclear please get in touch: https://www.sugarkube.io/#contact-us

Thanks!

[nhoughto]

Not quite the same, but good for CI jobs

https://github.com/bsycorp/kind

[swsieber]

Oh my - there are two distinct k8s bootstrapping projects named "kind" :(

https://github.com/kubernetes-sigs/kind/

[mcstafford]

This sounds like one of those "Why didn't somebody do this sooner?" moments.

TYVM

[MrBuddyCasino]

Not sure I understand. Do you mean local dev clusters? Because that is trivial to do using K3S/minikube/kind.

[skboosh]

No, more than that. To Sugarkube, the actual type of cluster (minikube, EKS, Kops) is just an implementation detail. Actually, when you think about it, even the region you deploy in or your cloud provider are really just an implementation details. Provided your applications are portable you could create a local minikube cluster that just includes the subset of stuff from your cluster that you care about for whatever you're working on. E.g. imagine you're in an ops team, and the ops cluster runs monitoring stuff and Jenkins, you could create a local cluster just running Jenkins and its dependencies (e.g. tiller, cert-manager, etc.). This is possible because Sugarkube understands your application's dependencies [1].

But the cool thing is that you could then go to the cloud whenever you wanted to. If you have some hard dependency on some cloud infrastructure, you could just use Sugarkube to spin up an isolated dev cluster on EKS for example. The EKS dev cluster could look the same as your prod cluster in terms of versions of software installed, but just use fewer, smaller EC2s, and again, perhaps just running a subset of the applications in your overall ops cluster.

Once you've developed in isolation, you could then deploy to a staging cluster which could again have been brought up - either just for this task, or more likely at the start of the day/week. Finally you could then promote your updated version of Jenkins into your prod cluster. For major upgrades to the prod cluster you could use Sugarkube to spin up a brand new sister cluster and then start to gradually migrate prod traffic over to it. Once all the traffic is going to your new cluster, just tear down the old one. If there's a problem, back out by sending all traffic back to the old cluster. Of course this last ability depends on something at the perimeter like Akamai (I think AWS have something similar?), and is a lot easier if your state is outside the cluster (e.g. in hosted databases, S3, etc.) but it'd be doable.

On projects I've worked on I've seen so many problems that basically came down to long-lived clusters where someone set them up a year ago and left/forgot how they worked. Or because performing upgrades was a nightmare they weren't done, etc. 100% automation of ephemeral clusters just solves all those problems.

[1] https://docs.sugarkube.io/concepts/kapps/dependencies/