vcluster VS devpod

Kubernetes? You mean the container orchestration system where they forgot to add Multi-tenancy? And no namespaces are not Multi-tenancy...

https://www.vcluster.com/

Whats the difference between this and vcluster (https://github.com/loft-sh/vcluster)?

Yep, as we see it they compliment each other quite well. DevPod takes your workspace to the cloud and DevSpace let's you develop against your Kubernetes cluster - potentially the same one you used to start your workspace.

Internally we use both in our development setup, spinning up remote workspaces using DevPod, installing DevSpace and kind into the devcontainer, then using DevSpace to develop against the cluster. See the vcluster setup[1] as an example

[1]https://github.com/loft-sh/vcluster/tree/main/.devcontainer

The tenants are internal dev teams so yeah maybe not. I was considering multi-tenanting different environments isolated at the kube layer with vCluster and have the vCluster pods running in Kata containers giving maximum isolation but still having a single management cluster. Ideally also avoiding the need to buy a second set of hardware for a dev environment

Vcluster

Looks interesting. How does this solution compare to vcluster?

sounds like the best option for you , is a tool called VCluster by loft ( https://www.vcluster.com/) , this way you can install as many k8s cluster as you want in the same k8s host cluster , those cluster share workers nodes and networking, but each has a separated "api server" , so it looks like you have a dedicated cluster with their own namespaces and tools . take a look at the docs to get a better understanding and how they work.

We're about to run a PoC with vcluster for isolated sandboxes, this might be relevant to you too

I think namespaces, RBAC and network policies are sufficient to partition users from the same organisation. I would investigate the use of vcluster ig you want to give your users even more isolation and capability (such as installing CRDs)

Depends on the use case. Namespaces provides soft isolation (so it means they share same Apiserver, PV's and global resources such as CRD's), but can be restricted with network policies. So it means, there's still potential in breaking other namespaces if you change PV's or CRD's which are used by other namespaces. Multi-Cluster solution can provide full isolation, but its also really expensive in resource consumption and maintenance/management effort. If namespaced-isolation isnt enough for your use case, you can consider vclusters (https://www.vcluster.com/)

When you push your code to Github, you can develop the app using codespace and it will automatically set up an online development environment for you. Other tools will make your life easier when developing using a dev container e.g. DevPod.

DevPod is that new kid in town that works on the same standard of devcontainers.json that Codespaces uses but is on the infrastructure of your choice and is open source. The project was just launched this May and has gathered more than 5.3K stars in this period. The advantage is the lower costs (around 5-10 times cheaper than cloud VMs) with auto-shutdown.

For students, unless there are allocated server resources with network access, it SHOULD/MUST scale down to one local offline ARM64 node (because school districts haven't afforded containers on a managed k8s cloud for students at scale fwiu, though universities do with e.g. JupyterHub and BinderHub [4] and Colab).

For Chromebook sysadmins, Instructors, and Students learning about how {Linux*, ChromiumOS, Android, Git, Bash, ZSH, Python, and e.g. PyData Tools supported by NumFOCUS} are developed, for example;

When you git commit to a git branch, and then `git push` that branch to GitHub, and create a Pull Request, GitHub Actions runs the (container,command) tasks defined in the YAML files in the .github/workflows/ directory of the repo; so `git push` to a PR branch runs the CI job and the results are written back as cards in the Pull Request thread on the GitHub Project; saving to the server runs the (container,command) Actions with that revision of the git repo.

Somewhat-equivalent GitOps CI Continuous Integration workflows (without Bazel or Blaze or gtest or gn, or GitHub Enterprise or GitHub Free due to the kids' intererests) that might be supported at least in analogue by Education and Chromebooks: k8s with podman-desktop in a VM, Gitea Actions (nektos/act; like Github Actions), devpod

devpod: https://github.com/loft-sh/devpod :

> Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use any cloud, kubernetes or just localhost docker. (with devcontainer.json, like Github Codespaces)

devcontainer.json is supported by a number of tools; e.g. VScode, IntelliJ,: https://containers.dev/supporting

repo2docker has buildpacks (like Heroku and Google AppEngine).

repo2docker buildpacks should probably work with devcontainer.json too?

repo2docker docs > Usage > "REES: Reproducible Execution Environment" describes what all repo2docker will build a container from: https://repo2docker.readthedocs.io/en/latest/usage.html

jupyterhub/repo2docker builds a Dockerfile (Containerfile) from git repo (or a Figshare/Zenodo DOI) that minimally has at least an /environment.yml and /example.py (and probably also at least a /README.md to start with), and installs a current, updated version of jupyter notebook along with whatever's in e.g. /environment.yml per the REES spec. [1][2][3]

[1] repo2docker/buildpacks/base.py: https://github.com/jupyterhub/repo2docker/blob/main/repo2doc...

[2] "Make base_image configurable" https://github.com/jupyterhub/repo2docker/commit/20b08152578...

[3] repo2docker/buildpacks/conda/environment.py-3.11.yml:

Also see https://devpod.sh/ which has had quite a lot of exposure on HN recently.

For these reasons, I believe most developer environments should prioritize developer experience over fidelity. Tools like Containerized development environments and cloud emulators can strike the right balance and there’s no surprise that we see increased activity around devcontainers, and similar solutions.

Have you considered devcontainers?

Its use results in carrying entire development environments with you, while not cluttering your host OS.

Using DevPod (https://devpod.sh/) ypu are not locked into Visual Studio or Visual Studio Code, but you can use whatever tool you want.

IMO this kind of setup will provide a much better DX than running a bunch of VMs eating away the resources of your laptop.