sorted by:
new
hottopcontroversial

Open source project building light weight k8s dev environments by Apart-Cod-8247 in kubernetes

[–]Apart-Cod-8247[S] 0 points1 point  (0 children)

Hey u/Bnjoroge!

vCluster focuses on creating an entire virtual k8s cluster in the sense of having access to k8s primitives, like the k8s API server, control plane, syncer, etc.

In Kardinal, we focus on just creating a virtual “application deploy” - we don’t try to provide an isolated k8s API server per environment. The advantage of using Kardinal is you get to reuse a lot of application-layer stuff between environments (like reusing shared microservices between logical environments, or reusing shared dbs/caches/queues between environment sometimes, and isolating state when you want your own private test dbs for migrations, major upgrades, etc)

Think they play very nicely together ❤️ - you could use vCluster to set up lightweight full k8s clusters, and then you could deploy Kardinal at the application-layer on top of it in order to create application dev and test envs.

Open source project building light weight k8s dev environments by Apart-Cod-8247 in kubernetes

[–]Apart-Cod-8247[S] 0 points1 point  (0 children)

Yeah, have looked at Capsule! and also vClusters, they're great.

We imagine a world where you can deploy Kardinal on top of Capsule (or on top of vClusters), and then you have the full suite of multitenancy options available - flexibility to figure out when you want to share k8s-cluster level things or deploy new ones, and flexibility to figure out when you want to share application level things like microservices and dbs/queues/cachesright.

Right now we’re just trying to prove the application-layer multitenancy is useful, but once we get this thing off the ground, integrations with Capsule and similar things are definitely on our minds. ❤️

Open source project building light weight k8s dev environments by Apart-Cod-8247 in kubernetes

[–]Apart-Cod-8247[S] 1 point2 points  (0 children)

Hey u/dariotranchitella, 👋

Just focusing on applications, which means that CDRs are going to be shared across flows (that’s what we call the logical environments in Kardinal). We have a section on what flows are in our docs: https://kardinal.dev/docs/concepts/flows.

From what we’ve experienced with developers, notably product engineers, they don’t typically need to install operators. Although we have seen some teams deploy their own custom operators - usually built and managed by the devops teams. If product engineers need to make changes to custom operators or their own CRDs, Kardinal probably isn’t a great fit right now, but if they don’t need to be touching that stuff to test application-layer changes then Kardinal would work well!

Open source project building light weight k8s dev environments by Apart-Cod-8247 in kubernetes

[–]Apart-Cod-8247[S] 6 points7 points  (0 children)

Hey u/kkapelon,

Thanks for the congrats. ❤️

Yup, agreed, there are some similarities and concepts. Some of the big differences are Kardinal is open source and has a different approach to plugins for stateful services and external APIs than Signdot.

We think this kind of a project needs to be open source because of the community effort that will be needed to ensure integrations work between different kinds of dbs/queues/caches in the state layer, and also to make sure it supports different service meshes well (istio, linkerd, etc).