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.
For me, this was always ops smell - why do devs need to spin up k8s clusters? As long as you're not working on some low-level k8s features (your own operator, or testing cluster-wide resources, or developing k8s components themselves), then why not use a 'real' cluster for testing? k8s multitenant/process isolation is definitely good enough for semi-trusted users like developers, as long as you take sensible measures (ephemeral low-priv namespaces, podsecuritypolicies, networkpolicies, quotas, etc).
In particular good RBAC design, that doesn't end up leaking information across namespaces, PSPs that are flexible enough for developers but strict enough to prevent privesc and strong network policies present challenges.
For those, less mature, organizations, a solution like this might present an easier option.
I think it's reasonable for everyone to have their own cluster if their day-to-day work involves developing cluster-scoped resources. Admission webhooks, service meshes, CNI plugins, etc.
I agree that most people have too many clusters, using them to separate batch and interactive jobs or staging and production jobs. Generally, computers are expensive and manually scheduling jobs to clusters reduces utilization, so it costs a lot of money. It also gives you less operational flexibility, like being able to throttle batch jobs to scale up interactive jobs.
Also, can you describe the performance (cpu / memory) of the clusters? Obviously if I am running lots of pods that have:
resources:
requests:
memory: 512Mi
cpu: 500m
Allocated, could run into problems if the underlying servers don't have enough cpu / memory.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.
I like the idea of having a developer be able to play entirely with their own local infrastructure to get as close to production as possible.
A hosted service will definitely make this less painful but once you get up to speed with k3s then I doubt there is anything faster than using it.
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 ben@usekrucible.com.