Live data from Hacker News

Show HN: Kardinal – Building light-weight Kubernetes dev ephemeral environments

kardinal.dev

1–10 of 26 posts

Re: Show HN: Kardinal – Building light-weight Kubernetes dev ephemeral environments

#3

Maybe I am misunderstanding the value prop but how does this compare to namespaces?

Hey siliconc0w,

namespace-based deploys (or telepresence too) is equally "lightweight" to Kardinal. it's just that (at least in our phrasing), those don't quite constitute a separate "environment" as state is shared between any developers working at the same time

Kardinal matches those approaches in terms of light-weightedness, but offers state isolation guarantees too (like isolation for your dbs, queues, caches, managed services, etc). so in comparison to "ephemeral environment" approaches that give state isolation, we do believe we're doing this in the most lightweight way possible by implementing that isolation at the layer of the network request rather than by duplicating deployed resources

Re: Show HN: Kardinal – Building light-weight Kubernetes dev ephemeral environments

#4
Man this brilliant and goes straight to test it with my development workflow. Namespace isolation was always PITA,but full isolation would require a dedicated clusters so having a best of both solution really changes the game for lean and cost effective continues delivery.

As for value prop, maybe emphasize multi tenancy a bit more as this has the most cost saving potential at scale.

Re: Show HN: Kardinal – Building light-weight Kubernetes dev ephemeral environments

#5
Not gonna lie. I designed a system that looks exactly like this. However, the plugin system was an operator instead of annotating a service which is kinda cleaner but it still felt dirty. A better approach is having a service registry to track the versions, values and clusters where this has been pushed but that means you needed a different API or extend the k8s API and deal with the whole auth/authz system.

I think the biggest hurdle to implement a solution like this is your application MUST be a 12 factor app which sadly is not the case from what I've seen. Many devs hardcode values when shipping their code and containers which make it really difficult to add nodes to a DAG. Had this change, SDLC testing would be waaay easier.

In the same space, labeling of all services is a thing. As you are annotating it can be tracked but if you had different gateways or destination routes or other things that need to be tweaked at the mesh level, it could be daunting to track it. In my case, I ensure the whole mesh representation of a version could be tracked by a label so if you had a app=vote1,version=release-4,feature=shiny you could track the shiny components across the whole cluster.

Another hurdle is you are tied to a service mesh implementation. Istio is ok but it can be a beast. It also constraints your org to implement other networking alternatives which is something we wanted to explore.

I do like the project uses Nix =).

Re: Show HN: Kardinal – Building light-weight Kubernetes dev ephemeral environments

#6

Man this brilliant and goes straight to test it with my development workflow. Namespace isolation was always PITA,but full isolation would require a dedicated clusters so having a best of both solution really changes the game for lean and cost effective continues delivery. As for value prop, maybe emphasize multi tenancy a bit more as this has the most cost saving potential at scale.

Thanks for the kind words marvin-hansen, if you get a chance to test it out--would love to hear what you think or if you have any questions!

Re: Show HN: Kardinal – Building light-weight Kubernetes dev ephemeral environments

#8
post #6

Man this brilliant and goes straight to test it with my development workflow. Namespace isolation was always PITA,but full isolation would require a dedicated clusters so having a best of both solution really changes the game for lean and cost effective continues delivery. As for value prop, maybe emphasize multi tenancy a bit more as this has the most cost saving potential at scale.

Thanks for the kind words marvin-hansen, if you get a chance to test it out--would love to hear what you think or if you have any questions!

For sure, probably test it over the weekend. I've dealt with k8s virtualization before and as a result, my current system uses contextual auto configuration for all it's services which makes it very easy to lift it from one kubernetes context to another, or even a docker only environment as it's often the case with CI.

However my primary challenge is chronic cluster under utilization after having rewriten the bulk of the system in Rust. Therefore virtualizating the cluster makes the most sense. I think Google Cloud conducted a study that found that the bulk, like 75%, of their K8s customer over provision by a wide margin. So there is definitely a market for cluster virtualization and even more so for multi tenancy.

Post reply on HN