Show HN: Kardinal–The lightest-weight Kubernetes dev environment in the world
github.com
github.com
In theory you could just use ingress and a special URL to deploy a single service as a special one-off deviation, but when you want to have an entire chain of services adjusted for a separate virtual environment that no longer works (unless you duplicate all services and rewrite all dependant service URLs for example).
you can even use ingress and special URL for multiple services in a one-off deviation, but things get really messy when you want to test state-level things too like db migrations.
besides making it more convenient to handle the chain of dependencies and duplicating all the services, we also want to make it easier to test db/state migrations and larger features without having to do an expensive e2e application deploy
Your project is probably going to be useful for some (who want it locally), and an inspiration for others (who want to build something similar but for their custom platform) as it can be pretty tricky in a world were we still have people doing things manually (i.e. running kubectl apply in production).
I was expecting something like kind. This is still useful, just not what the title made me think of, though fitting everything into the title is sometimes impossible.
environment is an incredibly overused word for devs. development environment might even mean IntelliJ, not a k8s cluster with your dev versions inside of it
been going back and forth a lot on how to make this more clear without introducing additional confusion
like the name though
in reality what you're doing with namespace-based deploys or telepresence is equally "lightweight" to what you're doing with 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
and thanks for the +1 on the name haha, we called it Kardinal because the goal is to deploy only "unique elements of your ephemeral environments" across the organization, i.e. number of services deployed equals the "cardinality" of service versions
How do you handle requests going from service A to B and then to database C vs A2 -> B -> C2?. How does service B know to route to a different database based on the version of A thats different?
we use trace headers to keep track of where the request originally came from to route it to the right database. it's transparent to service B as long as service B is properly propagating the request context from incoming request to outgoing requests