11–20 of 26 posts
sidenote: I noticed Istio (envoy actually) has some weird non-deterministic behavior when you hit pod resource limits (504 bad gateway, 0DC)
It's also such an interesting moment for you folks to show up on HN, I just shipped the first preview version of my Kubernetes operator(https://github.com/pier-oliviert/sequencer) that manages ephemeral environments. I can see some things that are similar with both our options as well as some things that are quite different.
Maybe if I had one question is: What made you go for Istio as the main network mesh?
Good luck with the launch!
Congratulations on shipping! I like how opinionated Kardinal is, which means it should work nicely for anyone who shares the same kind of infras vision as you. It's also such an interesting moment for you folks to show up on HN, I just shipped the first preview version of my Kubernetes operator( https://github.com/pier-oliviert/sequencer ) that manages ephemeral environments. I can see some things that are similar wi…
Nothing too specific on choosing Istio, but it seemed like a popular and battle-tested option to start the implementation with. Kardinal is a fairly young project (about 2 months old), and we expect it to adopt more "service mesh backends" in the future.
I'm kind of new to the k8 world, can I ask how this compares to the approach taken by Tilt?
That said, the timing of your question is perfect since we are about to push a Tilt integration that allows you to create an isolation flow and use Tilt to hot-reload and update that flow in-place! :)
How is this different from vcluster? In fact vcluster has no dependency on Istio which I think is a huge detriment to kardinal. We use cilium so the istio requirement becomes a non starter for us.
Regarding how Kardinal compares with vcluster, both aim to provide multitenancy within a single Kubernetes cluster, but they approach it differently.
vcluster is designed to offer a full Kubernetes experience to each tenant, including their own API server, control plane, and other Kubernetes-level components. This makes vcluster an excellent choice if you need strong isolation or want to test Kubernetes-specific features like custom CRDs or operators.
Kardinal, on the other hand, focuses on application-level multitenancy rather than providing the full Kubernetes stack to each tenant. This makes Kardinal lighter-weight and more efficient if you're primarily concerned with deploying and testing application-level changes.
Looks great. Unfortunately, I have no desire to manage Istio in my clusters. Would be interested one alternative methods are available.
As far as I understand Kardinal manages Istio for you.
unfortunately, this tool assumes full coverage with k8. but let's say you have an external pub/sub solution and your services are decoupled. that's a pretty low bar. sidenote: I noticed Istio (envoy actually) has some weird non-deterministic behavior when you hit pod resource limits (504 bad gateway, 0DC)
[1] https://github.com/kurtosis-tech/neondb-plugin [2] https://neon.tech/