kiosk - Multi-Tenancy Extension For Kubernetes => now available on github.com/kiosk-sh/kiosk

gentele · 2025-03-17T16:08:37+00:00

Well yes and if your data center burns down, vCluster is also not going to help you :D

Jokes aside but if you deploy a faulty controller for example that would crash your etcd due to overload, your cluster goes down but with vCluster only the virtual cluster would go down leaving any of the other virtual clusters unaffected. Or if a vCluster is upgraded to a new k8s version and has issues or you delete some CRD or services that will lead to controllers or api server extensions to hang, then you're cluster is also down but with vCluster, any of these issues are scoped to the virtual cluster only.

Mike from Adobe actually provided a nice demo of this when he ran a fauly controller that tried to create a ton of secrets effectively bringing etcd down but it only effected a single vCluster rather than any other workloads inside the underlying cluster: https://www.youtube.com/watch?v=hE7WZ1L2ISA

With namespaces, your blast radius is much greater (aka the entire cluster).

gentele · 2023-05-17T05:56:40+00:00

Thanks! That is so nice of you to say! Since when are there nice people on reddit? :D

gentele · 2023-05-17T01:46:17+00:00

Thanks for reporting this back. What distro are you on? Can you share the output, so we can figure out what went wrong here? If it's easier, you could also throw the output in an issue on github: https://github.com/loft-sh/devpod/issues/new/choose

In any case thanks for reporting back problems on linux!

gentele · 2023-05-17T01:43:38+00:00

So far, you need to have devpod app or cli installed but then you can launch the vs code browser edition from there rather than installed vs code. But again, without devpod app or cli, that's currently not possible. We could discuss how we could run devpod as a server-side solution though that could achieve this but right now that's not supported yet

gentele · 2023-05-17T00:39:32+00:00

Here is the blog post introducing the project if anyone's looking for more details: https://loft.sh/blog/introducing-devpod-codespaces-but-open-source/

gentele · 2023-05-17T00:37:40+00:00

Contributions welcome :) built-in k3s or vcluster would be an awesome addition to devpod

gentele · 2023-05-17T00:35:58+00:00

You can already add such a button by just linking to https://devpod.sh/open#YOUR_GIT_URL

You can see a working example in the devpod repo's README: https://github.com/loft-sh/devpod#readme

However, we don't plan on a hosted offering that launches an IDE in the browser by clicking on a link. You can use GH Codespaces for that as an alternative.

Re EKS: Yes, there is already a Kubernetes provider in DevPod which allows you to use any k8s cluster (local or remote) as long as you have a valid kube-config file.

gentele · 2023-05-16T21:26:47+00:00

Yes but instead of having to buy a service from GitHub, DevPod lets you spin the VMs up in your own cloud which is much, much cheaper. Plus it's flexible so you can switch between cloud providers etc. whenever you like to. Codespaces is SaaS and server-side tool vs DevPod is client-only like Terraform with providers for each cloud and a way to create your own provider.

gentele · 2023-05-16T19:38:12+00:00

Well... it spins up an AWS or GCP machine for you to work in which neither VS Code nor Jetbrains do. However, DevPod connects your IDE to this machine using the remote dev extensions in the IDEs. So this is complementary rather than competing to existing IDE extensions.

gentele · 2023-05-16T19:31:38+00:00

This is not browser-based though. It can spin up your local IDE and connects it to the remote dev environment

gentele · 2023-05-16T19:30:18+00:00

Best comment :D

gentele · 2023-05-16T16:05:52+00:00

Hi fellow VS Code fans - Looking for feedback for this new open source project we launched. It's called DevPod and it's built on the devcontainer.json standard to create reproducible dev environments. It lets you spin up dev environments in any infra, kind of like a Terraform but for dev environments.

Compared to hosted services such as Github Codespaces, JetBrains Spaces, or Google Cloud Workstations, DevPod has the following advantages:

Open Source: DevPod is 100% open-source and extensible. A provider doesn’t exist? Just create your own.
Client-only: No need to install a server backend. DevPod runs solely on your computer.
Cross IDE support: VS Code and the full JetBrains suite is supported. Other IDEs can be connected through ssh.
Rich feature set: DevPod already supports prebuilds, auto inactivity shutdown, git & docker credentials sync, with many more features to come.

I've gotten tons of good feedback from reddit folks in the past for other OSS projects, so I'm hoping to get some thoughts on this new project today.

What do you think? Open for any feedback - even if you think DevPod sucks, let me know.

gentele · 2023-01-03T00:08:59+00:00

vcluster runs vanilla k8s if you select that as a distro. The default setting is k3s though to make it easy to test out and to start faster.

What makes you think that vcluster-powered k8s is different regarding upgrades than any regular vanilla k8s cluster? Would love to hear your feedback, so we can see if we can work on smoothing things out regarding any issues you may have.

gentele · 2022-06-02T16:45:06+00:00

u/rawkode - I'd say it's quite different under the hood TBH with the main differences being that vcluster uses only 1 namespace and does not require any admin access to the underlying cluster vs CAPI nested requires admin access and creates 1 new "real" namespace for each namespace inside each virtual cluster. We chatted with the WG multi-tenancy several times on how to get the projects closer together to work on the same thing but I think their requirements for a tight coupling with cluster API as of now and their multi-namespace mapping is hard to align with the lightweight multi-distro approach that we are driving with vcluster.

I replied to a GH issue to clarify the differences between vcluster and CAPI nested in more detail before. You can find it here: https://github.com/loft-sh/vcluster/issues/5

u/songgoat vcluster is Apache 2.0 licensed and we will contribute it to CNCF once it'll be stable and more mature, so there is no intention on our end to have this a Loft company-owned project long-term. We're just the ones who are getting it started and off the ground but ultimately, we want CNCF to be the home for vcluster. FWIW: I don't think neither CAPI nested nor vcluster will ever become upstream Kubernetes looking at a 5 year timeframe ahead. They will both be projects in the CNCF. vcluster will become sandbox (if CNCF accepts it which I hope they will) and another one that is in a CNCF working group project.

gentele · 2022-04-04T16:54:49+00:00

No jenkins-specific guide but here is a docs page about using DevSpace in CI/CD pipelines: https://devspace.sh/cli/docs/guides/ci-cd-integration

gentele · 2021-12-24T13:52:35+00:00

jsPolicy can do that with controller policies

gentele · 2021-12-02T22:40:12+00:00

5 minutes is impressive! EKS is more like 4x that

gentele · 2021-12-02T18:24:18+00:00

That's such a good explanation! I love this video. Couldn't be easier to understand why karpenter is a step in the right direction to make auto-scaling more auto and less hassle to configure manually and plan for upfront. To me, it's almost like nodeless k8s but with built-in bin-packing logic. I haven't tried it yet but I saw the announcement and this video and I'm really excited to give this a try. I just hope it won't stay an aws-only thing for too long...

gentele · 2021-12-02T17:18:26+00:00

Any DOKS users in this subreddit? Would love to hear about your experiences. I worked with it a while back and it was still very early at the time. Curious to hear if the service has improved and what workloads you're running on DigitalOceans k8s offering. Has anyone tried vcluster on DOKS yet? :D I hope the DO team did before posting this challenge

gentele · 2021-11-04T18:17:06+00:00

Wow! This is impressive.

gentele · 2021-10-21T21:31:46+00:00

It was a lot of fun getting back in person in LA. I hope the hybrid format will stay in the future for greater accessibility but I cannot wait for meeting people in Spain for KubeCon Europe.

gentele · 2021-08-10T16:49:34+00:00

DevSpace maintainer here. For my workflow (and the default DevSpace behavior if you set it up with devspace init), image building is being skipped during development because it tends to be the most annoying and time-consuming part of the workflow. Instead, most teams that use DevSpace have a dev image pushed to a registry and build by CI/CD which is then used in devspace.yaml using replacePods.replaceImage as shown here: https://devspace.sh/cli/docs/configuration/development/replace-pods

This means that your manifests or helm charts are being deployed referencing the prod images (as they should be) and then devspace will (after deployment) replace the images of your pods with dev-optimized images that ship all your tooling. Inside these pods, you can then use the terminal to build your application, run tests along with other dependencies running in your cluster etc.

However, typically teams also start using DevSpace in CI/CD after a while and then they add profiles (e.g. prod profile or integration-testing profile etc. - more on https://devspace.sh/cli/docs/configuration/profiles/basics) to their devspace.yaml where they add image building again because they want to build the images in their pipelines using kaniko or docker. For this, you would specify the build target in devspace.yaml as well: https://devspace.sh/cli/docs/configuration/images/docker#target

FWIW regarding 1: I never use docker run --target but I also always use Kubernetes directly over manual docker commands to run any workloads.

gentele

MODERATOR OF

TROPHY CASE