gentele

Thanks for sharing! Just wrapped up a livestream about vind on youtube: https://www.youtube.com/watch?v=In8vzpKecLs

That's exactly the difference. You don't need to pay for codespaces and are locked into 1 cloud provider. You can use whatever cloud you want with DevPod

DevPod works with any IDE. We support VS Code (local and browser), pretty much the entire Jetbrains suite, and you can even connect via VIM :D

Thanks for sharing!

FF unfortunately does not support detecting the OS reliably...

No(t yet)

Civo is great!

Thanks for opening an issue! We'll definitely look into that. Would love to learn more about your experiences with DevSpace as well. If you're open to chatting, reach out via slack or via lukas [at] loft [dot] sh

Oh yeah, that would make it clearer! Thanks

Will definitely look into this. Thanks for reporting this!

Haha, spicy. We definitely don't want to overlook nix. It's a great tool. We do mean something different with "developer environment" in that context of this quoted sentence. I'm not sure if nix will help you much if you want to connect your VS Code to a remote VM or container to work inside of that environment. We'll work on rewording this though to make things clearer :)

Thanks for trying it! Can you open an issue on GH about this or join us on slack, so we can dig deeper into making this work for non-root podman with your input?

Don't worry. We'll be adding a server-side option for DevPod Desktop app to connect to for enabling thin-client/browser-based work but the cool thing is that this is not a requirement to use DevPod. It's more like Terraform and Terraform Cloud. You can run with Terraform and use it entirely client-only but you can also have server-side solution on top for specific things that just need central management.

That's correct. It uses the .devcontainer.json standard to define everything as code and it abstracts the cloud/infra and allows for an easy way to spin up a dev environment with a .devcontainer.json in any infra

Port-forwarding and using your local IDE is already working in DevPod today. We also added auto-port-forward where it watches what happens inside the container and then starts port-forwarding automagically.

File sync: That is a great idea. We got that in DevSpace already as you mentioned and we definitely think this could be super valuable in DevPod as well. Right now, a git push and then pull is required to get things from inside DevPod updated on local but with sync this would be even easier and faster.

It's a separate desktop app similar to docker desktop. DevPod is very, very lightweight though.

Adding devcontainer.json and then using DevPod with it should be pretty straight-forward for you. You can use docker-compose inside devcontainer.json if you want to reuse your existing setup.

Thanks! Glad to hear that

Thanks!

There are 3 main differences: 1) DevPod is based on GitHub/Microsoft's devcontainer.json standard while GitPod has their own file format 2) DevPod is client-only more like Terraform where the client creates/manages things directly using cloud credentials vs GitPod is a server-side solution to manage and provision dev workspaces 3) DevPod has a provider concept similar to Terraform that allows you to provision dev environments in ANY infra vs GitPod is mostly a hosted solution (they do have the option to host it yourself as well but it's usually you install it to one cloud and then provision in that same cloud vs DevPod is 1 client (no server, see point 2) and then you deploy the dev env in ANY cloud or even locally in Docker or local k8s)

Thanks! Sure thing. Happy to clarify on these two topics:

- Private git repos: They work out of the box because DevPod uses regular git to clone repos and authenticate with your git hosting provider. The desktop app injects a lightweight client into the workspace and then connects from your machine to the client to inject your git credentials into the workspace. This can also be disabled for untrusted or public workspaces but it's by default on because it allows you to `git pull/push` from within the workspace without any issues.

- Credentials for providers: If you use the AWS, GCP, DO, Kubernetes or any other remote provider to provision dev workspaces with DevPod, it requires that either a) you have the credentials on your local machine (e.g. already signed-in via AWS CLI or gcloud CLI or valid kube-context/kube-config for k8s) or b) you provide the credentials directly to DevPod when adding the provider (e.g. provide k8s service account token or gcloud/aws tokens). Option a) would be my recommendation because credentials are stored safely by the respective cloud provider CLIs rather than having to trust DevPod to store them safely for you.

In case of DevSpace (and likely other tools like that), it actually can create the deployment config (Helm chart) for you if needed.

Thanks! We eventually want to see vcluster as a CNCF sandbox project down the road.

Thanks! Getting a faster inner loop instead of abusing CI/CD for running tests before PRs are ready is definitely one of the reasons we built vcluster.

You could deploy the vcluster pod without the syncer. That would give you a k3s cluster without a scheduler. You can create deployments, pods, services etc. but no containers would actually be started. Of course, that means you still need one host cluster though for running the half-baked vclusters on.

Ephemeral clusters for dev and CI/CD is the main use case right now but due to the fact that the pods don't take a performance hit - as you already mentioned - because they are scheduled in the underlying cluster, vclusters can also be a very interesting concept for production workloads, effectively sharding your k8s cluster into logical clusters / control planes.

vcluster maintainer here. Right now, it is more about multiple vcluster running on the same Kubernetes cluster which addresses the multi-tenancy issues of Kubernetes. However, a single vcluster with multiple Kubernetes clusters to schedule workloads on is a super interesting idea as well. Federated clusters was a big topic a few years ago but it is very hard to solve.

Hi HN community! I'd love to show you vcluster - a virtual cluster technology for Kubernetes.

vcluster allows you to create k3s-based virtual k8s clusters that run on top of full-blown Kubernetes clusters. vclusters are lightweight and run inside a single namespace of the underlying host cluster.

********

Why vclusters?

1 - Because vclusters save a ton of cost: You can share resources from the underlying host cluster, e.g. use shared ingress controller. Instead of creating x new clusters, create x vclusters that run on one single cluster.

2 - Because vclusters are a better solution for soft multi-tenancy than using namespaces: Allows your tenants to get cluster-wide access (inside the virtual cluster obviously), so they can test RBAC or install and manage their own CRDs etc.

3 - Because vclusters add another layer of isolation in clusters. Unlike namespaces, vclusters have their own control plane (mainly API server and data store), so that all higher level resources only live in the vcluster (Deployment, StatefulSets, CRDs, ...) and they never reach the underlying cluster, which means the underlying cluster can be really "dumb" and easier to manage

4 - Because vclusters turn clusters into cattle: Spin them up in seconds, destroy them by deleting the underlying namespaces where the vcluster runs in and you get a clean state again. vclusters are super lightweight and low-overhead.

********

How to get started?

No server-side install required. You can deploy a vcluster with kubectl apply or helm install but the easiest option is to download the CLI binary and run:

```

vcluster create vcluster-1 -n host-namespace-1

vcluster connect vcluster-1 -n host-namespace-1

export KUBECONFIG=./kubeconfig.yaml

kubectl ... # Have fun using your vcluster

```

********

What do you think?

What do you think about the idea of virtual Kubernetes clusters? Could this be useful for you? What would need to be added to make it work for your use cases?

Any feedback is highly appreciated.

Direct link to the GitHub repository: https://github.com/kiosk-sh/kiosk

That is a very common flow today but re-building and re-deploying images on every change takes a lot of time and you cannot use modern dev features such as hot reloading (e.g. with nodemon).

With the DevSpace CLI, however, you can simply build and deploy once and every following code change will only lead to a code synchronization. The DevSpace CLI will sync your modified source code files straight to your containers running remotely inside a Kubernetes cluster. You can use hot reloading (e.g. with nodemon) and still build and run everything entirely on a remote Kubernetes cluster. Only when you change your Dockerfile, the DevSpace CLI will rebuild and redeploy your container images. This saves a lot of time during development.

I hope you will find the time to try it out and give us feedback on the project :)