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