5 ms·

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 us

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.

rockwotj 6y ago
What's the advantage of this over Minikube?
- BenElgar 6y ago
  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.
q3k 6y ago
> 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 developers, as long as you take sensible measures (ephemeral low-priv namespaces, podsecuritypolicies, networkpolicies, quotas, etc).
- BenElgar 6y ago
  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.
  - q3k 6y ago
    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.
    - BenElgar 6y ago
      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 6y ago
        > 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 6y ago
twblalock 6y ago
How do you think this compares with Kind, which seems to be the most popular way to spin up throwaway clusters?
nodesocket 6y ago
How do snapshots work? Is it simply taking snapshots of the underlying VM's or are you doing it at a Kubernetes resource level? 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.

rockwotj 6y ago

What's the advantage of this over Minikube?

BenElgar 6y ago
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.

q3k 6y ago

> 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 developers, as long as you take sensible measures (ephemeral low-priv namespaces, podsecuritypolicies, networkpolicies, quotas, etc).

BenElgar 6y ago
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.
- q3k 6y ago
  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.
  - BenElgar 6y ago
    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 6y ago
      > 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 6y ago

twblalock 6y ago

How do you think this compares with Kind, which seems to be the most popular way to spin up throwaway clusters?

nodesocket 6y ago

How do snapshots work? Is it simply taking snapshots of the underlying VM's or are you doing it at a Kubernetes resource level? 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.