Unless you have multiple systems, I don't think k8s will yield much benefit over plain docker.

I think it depends on your scale. If homelab stuff docker is awesome IMO.

I, personally, haven't done a whole lot of VM work but I do run a metric ass-ton of containers. I can spool up servers in docker compose on absolutely dogshit hardware and have it run serviceably. Also, the immutability of the container OS is really nice for moving things around and/or getting them set up quickly.

VMs are often imperative and can be quite easy and familiar to setup for most people, but can be harder or more time-consuming to reproduce, depending on the type of update or error to be fixed. They have their own kernel and can have window managers and graphical interfaces, and can therefore also be a bit resource heavy.

Containers are declarative and are quite easy to reproduce, but can be harder to setup, as you'll have to work by trial-and-error from the CLI. They also run on your computers kernel and can be extremely slimmed down.

They are both powerful, depends how you want to maintain and interface with them, how resource efficient you want them to be, and how much you're willing to learn if necessary.

What I did is install proxmox on the bare metal, setup a vm in which I put the containers.

Proxmox itself stays (almost) completely stock. The only changes I've made to it were to add the NUT client package so it could gracefully shut down if my NUT server indicates that the UPS is running out of power during an outage.

In your VMs you can do whatever. Setup OMV, or a stock Ubuntu or Debian vm and install your services on the VM or use Docker/Podman. Setup Fedora CoreOS or IoT vms and host all your services in Podman containers.

The great thing about Proxmox is you can do snapshot backups which take mere moments to complete. Then pass those off to a NAS where they can survive a irreparable loss of your Proxmox server.

You can also spin up new vms as needed to just try to fuck around with new techs or just a new way of setting up your home lab. It gives you a ton of flexibility and makes backing stuff up way easier.

Another great thing you can do is if 3 years down the line you are looking to replace your server hardware with some newer or more powerful stuff you can just add the new device as a node to the cluster. Then you can migrate all your existing VMs over to your new hardware and decommission your old one with very little to no downtime on anything.

It depends on your use case and what you are trying to achieve.

You do not need k8s (or k3s...) to use containers though. Plain old containers could also suffice, or Docker Swarm if you need some container orchestration functionality.

Trying to learn k8s would be a good reason to use k8s though :)

Container processes are just ordinary linux processes, so they don't need extra overhead (cpu and ram reservation) to run, which means your machine can run more of them. If you have a machine with 32GB of ram, can probably run 15 VMs with 2GB of ram each where the actual app running inside the VM might only consume about 50% of the VM ram, or you can run them as container and they all would just consume 15GB of ram, leaving you extra to run more containers. I found this to be ideal for self hosting because all apps are your personal apps so interprocess isolation is not as important compared to running in public cloud.

I personally really, really like (Docker) containers and I host most of my stuff with it, on a Raspberry Pi and on (free tier) Oracle Cloud VPS's. I also plan to (re)install Proxmox on a spare old laptop and run some stuff in VMs on that (namely Home Assistant) and might try a NixOS server too.

So really, use both. Use the right tool for the job. And you can also run containers in VMs and even use Ansible to configure everything with playbooks, allowing you to re-run said playbooks when things go wrong.

Personally I always use containers unless there is a good reason to use a VM, and those reasons do exist. Sometime you want a whole, fully functional OS complete with custom kernel, in that situation a VM is a good idea, sometimes a utility only comes packaged as a VM.

But absent of a good reason, containers are just better in the majority of cases

Just to add my two cents: When I started out I thought I'd need a datacenter, with 10 Gig connectivity and a lot of storage. Turns out, a Raspberry Pi 4 8GB would've been sufficient for the things I actually use.

My recommendation would be therefore to start minimalistic and build up according to your needs from there. Start with a Raspberry PI and Docker or use a used Micro SFF and go up from there, this advice would've saved me a lot of money and electricity.

I use proxmox for the sole benefit of just spinning up a VM of choice without having to deal with usb-sticks, etc.

From there I just run everything with Docker containers, via Portainer.

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).

My backup solution is rsync and so I really like docker-compose since it usually means there is zero config for restoration of backups on a new computer besides installing docker-compose (which is usually one line on the terminal).

Containers, unless you have a specific need for a VM.

With a VM you have to reserve resources exclusively. If you give a VM 2gb of ram, then that's 2gb of ram that you can't use for other things, even if the guest OS is using less.

With Containers, you only need as many resources as the process inside the container requires at the time.

Why not do both ? As I understand it, to do kubernetes clusters, you must have at least 3 hosts. They don’t need to be 3 different physical hosts: they could be VM (hosted on Proxmox).

Proxmox also having a very strong implementation of ZFS, then it could be used as the storage « host », and it gives you also the option to do snapshots of the VM (and the storage pool), as well as replication/etc.

Why not both?

Like many others here, I went with Proxmox as the base host. But most of my services are Docker containers , running in a "dockerVM" on top of Proxmox.

Having Proxmox as the base is just so flexible, which is very handy for a homelab.

• For instance I set up a VM with Wireguard back when Wireguard had only just been merged in to the mainline kernel, without affecting the other
• You can have separate VM for docker testing, and docker production
• You can run multiple VMs for multiple Kubernetes hosts, to try it out and get your feet wet without affecting the "production" containers
• If you get additional servers, you can just migrate those Kubernetes VMs
• You can run Windows VM should you need, and BSD (and thus pfSense/opensense or TRUE AS)
• You can run a full graphical environment if you want
• Proxmox has easy setup for firewalls for each VM
• I have a VM running a legacy bare metal system (from the same server now running proxmox) that I've been slowly de-commissioning piece by piece

Por que los dos?

Debian hypervisor with raidz2 hosting vms, the main ones being 1 main freebsd host with 20 jails containing 1-2 apps each, and 1 main debian vm hosting things that are too much of a pain in the ass to get running on freebsd, so it hosts 5 docker containers.

Rocks my world.

Not a proxmox pro by any means, but it can do both VMs and containers. I have a few VMs for various Linux distros to play around with. I also have one dedicated VM for all my security related tools.

Stuff like PI hole, jellyfin, logstash, etc. dont really have any need for a full OS, so a container works perfectly. Plus having a full OS with several things running on it makes it more difficult if you just need to restart one service

I started doing everything in VMs but over time realized some things were better to maintain as containers

If it's relevant for your job, go for k8s. The more you tinker with it, the more knowledge you'll accumulate. Is it the optimal solution for a self hosting setup? Well, it depends but most probably not.

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.

Why not use both? I have PVE installed on all of my hosts and then use k3s/docker in VMs. If there ever is anything you don't want to or just can't deploy as a container (e.g. opnsense, hassio, truenas, windows [for whatever reason you might have]), you can just spin it up as a VM and not worry about adding and maintaining another physical machine

K8s are more complex than containers using proxmox. If you are up for the challenge sure go crazy.

I'd suggest looking into k8s. It's definitely a bit more complex on the start, but so much more power once you get to the details. VMs you don't share the base OS layer and the hardware, you have to pre-define the resources you need per app in a more constrained manner, while containers can move freely in their little sandbox to pickup whatever it needs.

It is also much easier to manage replicas, upgrades, scale and a bunch of other things once you are using containers and an orchestrator like Kubernetes. Let me know if you need any help/insights. I've been trying to post more videos/answers about things that could be complicated.

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.