BenElgar

Cool! Small bit of feedback: typing each character adds an entry to the browser's history which seems a bit excessive. Might consider using replaceState over pushState.

Why do you include Social Security in the list of things that won't be eliminated? I'm not American but in my understanding UBI would almost completely eliminate Social Security, along with putting a big dent in the need for Medicare and Medicaid.

That's not UBI though, that's a negative income tax.

Author here. At the last two companies I've worked at we really needed—and didn't have—a solution for spinning up throwaway Kubernetes clusters that we could use for testing and development. Krucible is an attempt to solve that problem.

Krucible replaces minikube/kind[0] with faster, cloud-hosted Kubernetes clusters that are easier to spin up from inside of CI/CD environments and that don't consume a large amount of local resources.

Happy to answer any questions!

[0] Or whichever other Kubernetes provider you use for testing and development

> Kubernetes supports resource requests and resources quotas to combat this. You should be protecting your production workloads this way anyway.

That's certainly good advice and would significantly reduce the likelihood of issues but it doesn't handle all cases. For instance it's not particularly easy to quota network bandwidth.

Ultimately all of these problems are likely solvable—we just think that Krucible is easier, simpler and safer.

There are definitely some use cases where having a local-to-your-machine development environment is more suitable but, as you say, Krucible is easier to set up and comes with features that just running k3d doesn't, like snapshots. Our experience is that ensuring that developers are all running in the same environment is pretty valuable by itself.

By having a dedicated Kuberntes cluster you reduce the blast radius. For instance, if you roll out a new version of your services that unexpected consumes a significant quantity of resources, if you were running that on your production cluster that could interfere with your production workload.

In a similar vein, if you have 10 or even 100 end-to-end test suites, with Krucible you could run them all in parallel, significantly reducing the time taken, without fear of them impacting each other. In your shared cluster scenario you would be limited by the size of your cluster.

I think Krucible could be very helpful for you here. Each student could sign up for a Krucible account and spin up up to 25 free clusters. Should be plenty for teaching purposes.

You could also prepare a cluster with a certain configuration in advance, snapshot it and then create new clusters from that snapshot so that all students could quickly get started with a Kubernetes cluster in a given state.

Get in touch and I'd be happy to help you get things set up. Email is [email protected].

Really it depends what you're testing and deploying. For instance, if you're developing a new microservice, it's helpful to be working with the same service discovery mechanism that is running in your production cluster. When you're testing, presumably you also want to ideally test any Kubernetes changes that you make before you deploy to your production servers. Krucible is ideal for that.

Krucible is hosted, so you're not running a VM that's consuming resources and that you have to manage—spinning up Minikube from within a CI environment isn't necessarily the easiest of tasks. With Krucible it's just a single API call to create a Kubernetes cluster. This also allows you to parallelise your test suite easily as you can spin up as many clusters as you need at the same time.

The snapshots feature is also a big differentiator: you can set up a cluster, take a snapshot and then share that with your team so that you're all running identical Kubernetes clusters.

Author here. At the last two companies I've worked at we really needed—and didn't have—a solution for spinning up throwaway Kubernetes clusters that we could use for testing and development. Krucible is an attempt to solve that problem.

We've just released a really cool feature called Snapshots that allows you to image a running Kubernetes cluster, including the state of all applications, and then create new clusters from that image. It's great for creating consistent development environments or quick starting test environments.

Happy to answer any questions people might have.