[BenElgar]

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.

[q3k]

> 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 and CI systems.

[BenElgar]

> 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.

[nrmitchi]

There are certain things that just can't be tested while scoped to a namespace; many CRDs are a good example of that. If your service rollout contains a CRD, an it is rolled out to the same cluster as production, you are going to impact production.