Live data from Hacker News

Rebuilding My Homelab with Compose, Ruby, IPv6, and No Kubernetes

petekeen.net

61–66 of 66 posts

Re: Rebuilding My Homelab with Compose, Ruby, IPv6, and No Kubernetes

#61

Lot of kubernetes hate here, which is surprising. I run a little 3 node cluster and besides the hardware issues I had (long story), it has been rock solid and dead easy to setup. Talos + longhorn + fluxcd (optional), is super nice. And everything beyond that is additive and just works within the ecosystem. If anything, it helped keep my stuff alive during all the hardware issues a lot longer. I think like 5-6 years a…

> All the enterprisey stuff makes it feel a lot more complex than it really is. Kubernetes is not PaaS. It is a low level container orchestrator. But people start by thinking of it as a ready-made PaaS and then keep on trying to make it closer to that vision by continually slapping random plugins on it. In corporate environments, incompetence is the norm. Every kubernetes deployment in such places ends up relying on…

Right.

If you are used to docker compose and don't care about redundancy or authoring your own stuff. Just setup storage and then use helm install. It feels like an app store at that level.

Grow from there as needs arise.

Re: Rebuilding My Homelab with Compose, Ruby, IPv6, and No Kubernetes

#62
post #2

Hey, author here. This is a piece about moving away from kubernetes and toward something that I can actually maintain as a solo person who has a life outside of k9s. It's not really intended to be "anti-kubernetes", more like "kubernetes really is too hard for my purposes". IMO the best change that I've made has been to give deterministic IPv6 addresses to every container and then using those for ingress. I'm curious…

The honest answer to your question about where the line is: it's when you start writing your own health checks, restart logic, and deployment orchestration on top of compose. That's the tipping point where you're maintaining infrastructure instead of just running apps.

We built Miren for exactly this middle ground. Push to the cluster, it handles image building, TLS, and deployment on any Linux server. No Dockerfile, no compose, no Kubernetes. Autoscaling is on by default. It's not that Kubernetes is wrong, it's that there should be something between compose scripts and a full cluster.

We're actively working on ways of deploying already ready services in docker files to the cluster, which would probably be what you're looking for initially unless the cluster you're doing a lot of development on the cluster.

Re: Rebuilding My Homelab with Compose, Ruby, IPv6, and No Kubernetes

#63
post #62
post #2

Hey, author here. This is a piece about moving away from kubernetes and toward something that I can actually maintain as a solo person who has a life outside of k9s. It's not really intended to be "anti-kubernetes", more like "kubernetes really is too hard for my purposes". IMO the best change that I've made has been to give deterministic IPv6 addresses to every container and then using those for ingress. I'm curious…

The honest answer to your question about where the line is: it's when you start writing your own health checks, restart logic, and deployment orchestration on top of compose. That's the tipping point where you're maintaining infrastructure instead of just running apps. We built Miren for exactly this middle ground. Push to the cluster, it handles image building, TLS, and deployment on any Linux server. No Dockerfile,…

Why did you use AI to write this?

EDIT: Only moderate snark intended.

Re: Rebuilding My Homelab with Compose, Ruby, IPv6, and No Kubernetes

#64
post #55
post #53

Earlier quoted context omitted.

If that works for you, great!

Agree! There are a ton of people out there that are happily running k8s on their homelab and there is absolutely nothing wrong with that. I tried it and found it was just too much for me.

Tbf I do the exact same thing at work and love doing abstractions that "technically" makes maintainence easier. Kubernetes fortunately is extremely automatable.

Re: Rebuilding My Homelab with Compose, Ruby, IPv6, and No Kubernetes

#65

I did the same move as you away from k8s to plain proxmox containers and VMs. Professionally i do work with k8s, and see the benefits of it (not always, but i see the use cases), but in my homelab it was consuming a lot of energy. Just dropping the whole k8s, made me save 1 kw energy when idle... I guess mainly because of the active API, shifting workload from different workloads and the whole machinery that happens…

I would have assumed that observability components (Prometheus, etc) dwarf the control plain when it comes to activity. At least with not extremely dynamic workloads. And you mention that it was due to shifting workloads. If the demands are static, nothing should shift in my experience?

Yes, well I am not sure why, but my nodes, kept pushing load from node a, to node b, then back to a. Maybe updates, new certificates, or trying to optimize usage, etc..

Re: Rebuilding My Homelab with Compose, Ruby, IPv6, and No Kubernetes

#66

I did the same move as you away from k8s to plain proxmox containers and VMs. Professionally i do work with k8s, and see the benefits of it (not always, but i see the use cases), but in my homelab it was consuming a lot of energy. Just dropping the whole k8s, made me save 1 kw energy when idle... I guess mainly because of the active API, shifting workload from different workloads and the whole machinery that happens…

Proxmox is merely Debian with some fancy curtains. I'm sort of fascinated by this social belief it is something more than that. Although I agree with your sentiment, I'd rather be on XCP-ng or IncusOS as the foundation for containers. I don't believe sacrificing immutability in the host is an improvement over k8s for stability and maintenance.

> Proxmox is merely Debian with some fancy curtains. I'm sort of fascinated by this social belief it is something more than that.

You can always reduce anything to "its just linux". But the glue around, the good updates, the stability, the great integration with ceph, make the whole difference..

Post reply on HN