11–20 of 28 posts
How well is this suited to use in classes? We are searching for a good way to learn students cloud stuff (asw/azure/... but also kubernetes) without high $$$
Earlier quoted context omitted.
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.
But again, why not just deploy your microservice to a development namespace on a shared cluster? It's going to be the closest thing to production, with hopefully only a few flags changing.
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.
Earlier quoted context omitted.
But again, why not just deploy your microservice to a development namespace on a shared cluster? It's going to be the closest thing to production, with hopefully only a few flags changing.
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, sign…
Kubernetes supports resource requests and resources quotas to combat this. You should be protecting your production workloads this way anyway.
> In your shared cluster scenario you would be limited by the size of your cluster.
On the other, with a shared cluster, it makes sense to dedicate more resources to it, and share it across both developers and CI systems.
How well is this suited to use in classes? We are searching for a good way to learn students cloud stuff (asw/azure/... but also kubernetes) without high $$$
I'm the CTO of msb.com, we're building a k8s learning platform, and are now expanding into a larger ecosystem of adjacent technologies, from CI/CD pipelines to istio and such. We regularly spin up hundreds of clusters on demand which are free to use. Feel free to try out the platform at learn.msb.com or contact me at mislav @domain
I have been setting up something recently using k3s (more specifically k3d for k3s in Docker) and it seems great so far. I'm having to use k3d since I'm not in Linux but as soon as WSL2 is available then I can even get rid of the Docker part I think. 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 defin…
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…
> Krucible is an attempt to solve that problem. 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 d…
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.
Earlier quoted context omitted.
> Krucible is an attempt to solve that problem. 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 d…
From what I've seen reviewing k8s clusters some of the items in your "sensible measures" list aren't considered easy to manage and deploy. 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…
From my experience with companies that haven't done their organizational or engineering homework: half-assedly deploying Kubernetes ends generally ends up being an unmaintainable disaster.
One of the high-return-value aspects of k8s is having little clusters available to multiple tenants. Without this in place k8s really stops making, being too complex for its actual usecase - so you might be much better of using something simple like Nomad.
Earlier quoted context omitted.
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, sign…
> By having a dedicated Kuberntes cluster you reduce the blast radius. Kubernetes supports resource requests and resources quotas to combat this. You should be protecting your production workloads this way anyway. > In your shared cluster scenario you would be limited by the size of your cluster. On the other, with a shared cluster, it makes sense to dedicate more resources to it, and share it across both developers…
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.