I’m thinking about starting a self hosting setup, and my first thought was to install k8s (k3s probably) and containerise everything.

But I see most people on here seem to recommend virtualizing everything with proxmox.

What are the benefits of using VMs/proxmox over containers/k8s?

Or really I’m more interested in the reverse, are there reasons not to just run everything with k8s as the base layer? Since it’s more relevant to my actual job, I’d lean towards ramping up on k8s unless there’s a compelling reason not to.

2 points

You can try casaOS.

https://github.com/IceWhaleTech/CasaOS

Its something like k8s. But it is easy to use and works very well with docker containers.

permalink
report
reply
0 points

I am more comfortable using Ansible and Terraform, so I find VMs more suited for me. Though for random nodejs or PHP apps, I do put them in postman containers and pods.

permalink
report
reply
1 point

also curious abt this

permalink
report
reply
3 points

Basically, it’s “why not both?”

So first, kubernetes is a different ball of wax than containers, and if you want to run it on one machine you can, but it’s really for running containers across a cluster of machines. I’m guessing you just generally mean containers so I’ll go with that.

Containers are essentially just apps running on a virtual os. Virtual machines are an OS running on virtual hardware. You can abstract both layers and have virtual hardware running an os that runs a virtual os for your containers, and nothing will really mind - in fact that’s kind of the way to do it if you have one big machine you need to run a bunch of services on. You might cut up a server into a Linux VM, a Windows VM, and a BSD VM, and run containers on each one. Or you might run 3 Linux VMs and have the containers for 3 different services split between them.

It really depends on what you’re hosting and trying to do for how exactly to go about it. Take for instance a pretty common self hosted stack:

Plex Radarr Prowlarr Deluge TrueNAS

Now you could install TrueNAS scale and run all of those as containers on it, and it would work ok, but TrueNAS scale isn’t really meant for managing a ton of containers right now. You could make a vm on it for each service and have them all talk to each other but then you’re probably wasting resources by duplicating the OS 5 times. Also, what if you want to run TrueNAS core instead of scale? Can you get everything else working in jails – maybe? – but it’ll probably be a pain.

Instead, you might install proxmox and pass through the drive controller, and set up one VM for TrueNAS core. Then you might make another VM for the arrs containers, and a third for Plex itself.

It gets you the best of both worlds. TrueNAS can run on BSD instead of Linux, your arrs are easy to deploy and update in containers that keep everything separated, and Plex is sequestered in a hardened os with read only access to everything else since it gets a port forwarded and is more of a security risk. Again that’s just one option though.

VMs get you a ton of really handy things like snapshots and for simple VMs, very easy portability between relatively similar hardware. I’ll probably get ruined for saying this but they’re also a security tool that you should probably keep in your belt. If someone manages to break out of a container and your files are just sitting there for the taking that’s not great. If someone manages to break into your VM and “the good stuff” is on another VM that’s another layer of security they have to break through.

Containers on the other hand use way fewer resources, especially ram - and are much easier to wrangle than many OSes for updates and config.

There’s really a lot of self hosted stuff that assumes you’re running docker and treats regular install as a kind of weird edge case, so you’ll probably run docker even if you don’t want to.

Kubernetes on the other hand I would argue isn’t really meant for self hosting where you probably have a one or two servers that you own. Its meant to deploy containers across various cloud servers in a way that’s more automated to manage. If you need storage in a kubernetes cluster you’ll probably use something like s3 buckets, not a hard drive.

If you want to learn it you can totally deploy it on a computer running a few VMs as nodes or with a few laptops / SBCs as a cluster, but if you just want the services to run on your server in the closet it’s a bit like using a sledgehammer to nail a chair back together. That’s why you don’t tend to see it talked about as much - it’s a bit of a different rabbit hole.

permalink
report
reply
4 points
*

If everything you want to run makes sense to do within k8s it is perfectly reasonable to run k8s on some bare-metal OS. Some things lend themselves to certain ways of running them better than others. E.g. Home Assistant really does not like to run anywhere but a dedicated machine/VM (at least last time I looked into it).

Regardless of k8s it may make sense to run some sort of virtualization layer just to make management easier. One panel you can use to access all of the machines in you k8s cluster from a console level can be pretty nice, and a Proxmox cluster would give you this. You can make a VM on a host that takes up basically all of the available RAM/CPU on it. Proxmox specifically has some built-in niceties with gluster (which I’ve never use, I manage gluster myself on bare metal) which could even be useful inside a k8s cluster for PVCs and the like.

If you are willing to get weird (and experimental) look into Rancher’s Harvester it’s an HCI platform (similar to Proxmox or vSphere) that uses k8s as its base layer and even manages VMs through k8s APIs… I played with it a bit and it was really neat, but opted for bare metal Ubuntu for my lab install (and actually moved from rke2 to k3s to Nomad to docker compose with some custom management/clustering over the course of a few years).

permalink
report
reply
3 points

Fwiw I’ve been running home assistant in a docker container for a couple years without any issues

permalink
report
parent
reply
2 points
*

Yeah, I think the problem comes if you don’t want to manually configure “Add-ons”. Using this feature is only supported on their OS or using “Supervised”. “Supervised” can’t itself be in a container AFAIK, only supports Debian 12, requires the use of network manager, “The operating system is dedicated to running Home Assistant Supervised”, etc, etc.

My point is they heavily push you to use a dedicated machine for HASS.

permalink
report
parent
reply
1 point

Yeah, I haven’t missed the HASS add-ons but that’s a good point

permalink
report
parent
reply

Yea I’ve been running “core” in docker-compose and not the “supervised” or whatever that’s called.
It’s been pretty flawless tbh.
It’s running in docker-compose in a VM in proxmox.
At first, it was mostly because I wanted to avoid their implementation of DNS, which was breaking my split-horizon DNS.

Honestly, once you figure out docker-compose, it’s much easier to manage than the supervised add-on thing. Although the learning curve is different.
Just the fact that your add-ons don’t need to go down when you upgrade hass makes this much easier.

I could technically run non-hass related containers in that docker, but the other important stuff is already in lxc containers in proxmox.
Not everything works in containers, so having the option to spin a VM is neat.

I’m also using PCI passthrough so my home theater/gaming VM has access to the GPU and I need a VM for that.

Even if they only want to use k8s or dockers for now, having the option to create a VM is really convenient.

permalink
report
parent
reply

Selfhosted

!selfhosted@lemmy.world

Create post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

Community stats

  • 4.8K

    Monthly active users

  • 3.6K

    Posts

  • 78K

    Comments