Well, we've all got to start somewhere, right?

But yeah, I'd personally recommend Docker for self-hosting. Kubernetes or Proxmox always end up being too much to handle for personal use - or even small to medium sized companies.

> Proxmox always end up being too much to handle

I've been running a 2-node Proxmox cluster for about 3 years with close to no maintenance. What's too much about it?

It gives me easy VM and LXC management and very easy declarative networking and firewalling. That alone makes it worth it for me.

Right, proxmox (like k8s) is a huge force multiplier for individuals trying to manage large/diverse surface areas. I run both for my own stuff at home (well k8s in the cloud, but its not work related) precisely because of the power it offers.

Yes they are complicated. Yes, they are still worth learning. And once you learn them they make a lot of sense to use when given the option.

I think OP is saying Proxmox isn't really that complicated compared to K8. I guess my perspective is warped since I know what I'm doing pretty well, but installing Proxmox and setting up some basic VMs or LXC containers (especially if you use the helper scripts) isn't that hard. Sure, there is still some added complexity, but I think that's more than offset by the ease of doing backups alone. Meanwhile, my experiences with K8s have all been mostly painful and I didn't really feel like I gained anything to offset the complexity versus just using Docker (for my personal use, obviously K8 makes sense at enterprise scale or if you use your homelab for learning).

I think it's good. K8s is well packaged (these days) and quite discoverable. I agree it's likely to throw up some problems, but it's great that it's possible.

I'll be honest, never learned it, worked up from network protocols, reached docker in terms of virtualization, and of course OS fundamentals.

But even in those 3 areas I haven't exhausted all the knowledge and features available.

So I'm just skeptical when someone is using k8s and hasn't mastered the fundamentals. How do they know whether they should be using a high level k8 feature or a low level os feature? Happened with docker a lot to me when I didn't know better, I was learning how to set memory limits on containers and reset policies instead of learning to do it on the OS level.

> reached docker in terms of virtualization

Except docker, on its own without something else in the stack, isn't Virtualization.

Docker is kernel virtualisation. Are you thinking of OS virtualisation, like a VM?

Docker does not virtualize the kernel, in fact the kernel version “inside” Docker is the same as the host.

Virtualization usually refers to OS/ device emulation in software. Docker uses kernel namespaces which is an entirely unrelated feature.

I find it funny how some obtuse devs are unable to use abstraction in software of all things.

Docker is OS-level virtualization. VMs are hardware virtualization. Different layers.

That isn't even true, you share your host kernel. There are parts of the kernel that aren't namespaced as well. The kernel keyring is probably the big one.

>That isn't even true

You are incorrect, this is true:

"OS-level virtualization is an operating system (OS) virtualization paradigm in which the kernel allows the existence of multiple isolated user space instances, including containers (LXC, Solaris Containers, AIX WPARs, HP-UX SRP Containers, Docker, Podman)..."[0].

>you share your host kernel

Kernel != OS

>There are parts of the kernel that aren't namespaced as well. The kernel keyring is probably the big one.

Immaterial.

[0] https://en.m.wikipedia.org/wiki/OS-level_virtualization

You can call it what you want but absolutely no one considers chroot virtualization in any meaningful sense. Nothing is being virtualized, containers are just regular processes on the host system.

"OS Virtualization" != "OS" "Virtualization"

1st of all yes, many people consider not only chroot to be virtualization (of the file system). Yes it is arguable as it is the birth of lightweight virtualization. But you were wrong in saying no one does.

https://papers.freebsd.org/2000/phk-jails/

https://youtu.be/hgN8pCMLI2U?si=CH-Fpyj16bEWDZzc

2nd containers go farther and virtualize network, and other resources.

>You can call it what you want

I call it as it is.

>but absolutely no one considers chroot virtualization in any meaningful sense.

Absolutely everyone who's knowledgable in virtualization considers chroot to be a type of OS-level virtualization.

>Nothing is being virtualized, containers are just regular processes on the host system.

Wrong, "...OS-level virtualization is an operating system (OS) virtualization paradigm in which the kernel allows the existence of multiple isolated user space instances..."

"OS Virtualization" == "OS " + "Virtualization"

It’s not virtualization, it’s namespaces. Docker makes use of Linux kernel features; started out with cgroups and now uses libcontainer. Each container is running in its own isolated(ish) namespace on the same host kernel.

It’s _very_ different technology than virtualization.

You don’t need docker to make a container on Linux (or Solaris for that matter).

>It’s not virtualization

You are incorrect, this is OS-level virtualization:

"OS-level virtualization is an operating system (OS) virtualization paradigm in which the kernel allows the existence of multiple isolated user space instances, including containers (LXC, Solaris Containers, AIX WPARs, HP-UX SRP Containers, Docker, Podman)..."[0].

>it’s namespaces. Docker makes use of Linux kernel features; started out with cgroups and now uses libcontainer. Each container is running in its own isolated(ish) namespace on the same host kernel.

Yes, OS-level virtualization.

>It’s _very_ different technology than virtualization.

Incorrect, this is a virtualization technology.

>You don’t need docker to make a container on Linux (or Solaris for that matter).

No one claimed otherwise.

[0] https://en.m.wikipedia.org/wiki/OS-level_virtualization

Not arguing this again, go edit the wikipedia article if you are so confident

OP here.

Of course I haven't mastered he fundamentals of K8s yet, I am just beginning to learn it.

Like you, I have been using docker for years, and to be honest it served me very well - and would probably continue to do so. But as a geek, I have a natural curiosity, sometimes just the curiosity of whether or not something can be done, and how it works, is enough justifications to do it.

As you probably read, this is in my home services. Which is where I am free to do exactly these experiments before I know the inns and outs of it.

Some of what I wrote in the blog post, I have already ditched. I am no longer hardcoding the ipv6 addresses from the pools, for example, but I still need to change my pool ip addresses if my ISP changes the range. I am not sure if my way is the correct one. I could do it manually, but what's the fun in that ?

There will be more blog posts as I learn, you be sure (there already is). I have more coming up, but one of my current projects will take a bit of time, as I have decided that writing a Unifi Operator for managing firewall rules is a better way to do it :)

Now, for home use? Whoever does that, write K8s Operators?

If you're on hacker news then you should understand that the goal isn't necessarily the result, it's the learning experience.

Probably he is not a newbie entirelly since he was able to run kebernetes.

Anyway I agree that there no point in using k8s for home stuff. Single instance of anything should be sufficient for any needs like that.

On the other hand maybe someone just like to tinker with technology.

Exactly (OP here).

The goal wasn't necessarily the result.

I like to tinker.

And well...my K8s cluster is only one node so far, so there's limits to what I can play with.

And please: No comments that K8s is overkill. I know, and I don't care :) There's things to learn from it, and that's good enough reason for me.

Running something complex at home to learn is definitely a good idea.