Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

petekeen.net

Post reply on HN
Print view View original

11–20 of 66 posts

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

#11

Post by randompartytime »

LaurensBER wrote: post #4
ocd wrote: post #3

I still don't know really what Kubernetes is for or why so many people outside specific environments are using it, but it's cool that you're using Ruby.

Kubernetes makes complex things (e.g blue/green deployment, auto-scaling, failover) possible irrespective of the underlying cloud/hardware with a good and standardized API. It's absolutely overkill for small teams and homelabs (I run a cluster myself) but an absolute godsend if you do need the advanced functionality.

>Kubernetes makes complex things (e.g blue/green deployment, auto-scaling, failover) possible

How?

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

#13

Post by Havoc »

Meanwhile I’m busy moving the other direction. More K8S.

Main motivation is that I’ve got a lot of compute and memory but it’s spread across many smaller devices. Meaningfully leveraging that requires a way to coordinate…

I do also have a classic Proxmox setup too though so can decide whether something should live in VM/LXC or k8s

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

#14

Post by pjmlp »

MisterKent wrote: post #7

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…

I got introduced to UNIX with Xenix, have used plenty of flavours including containers in HP-UX and Solaris before they became a thing in Linux, I have zero need to use Kubernetes at home.

In fact, I also have zero needs for it at work directly, as I have become an advocate for serverless and managed runtimes, unless there is really a business need to control the whole infrastructure, including the Kubernetes cluster directly.

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

#15

Post by pjmlp »

LaurensBER wrote: post #4
ocd wrote: post #3

I still don't know really what Kubernetes is for or why so many people outside specific environments are using it, but it's cool that you're using Ruby.

Kubernetes makes complex things (e.g blue/green deployment, auto-scaling, failover) possible irrespective of the underlying cloud/hardware with a good and standardized API. It's absolutely overkill for small teams and homelabs (I run a cluster myself) but an absolute godsend if you do need the advanced functionality.

Somehow we were doing that with deployment scripts and VM management tooling before Kubernetes became a thing, and without having to deal with YAML spaghetti.

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

#16

Post by chuckadams »

pjmlp wrote: post #15
LaurensBER wrote: post #4

Earlier quoted context omitted.

Kubernetes makes complex things (e.g blue/green deployment, auto-scaling, failover) possible irrespective of the underlying cloud/hardware with a good and standardized API. It's absolutely overkill for small teams and homelabs (I run a cluster myself) but an absolute godsend if you do need the advanced functionality.

Somehow we were doing that with deployment scripts and VM management tooling before Kubernetes became a thing, and without having to deal with YAML spaghetti.

Yes, and Kubernetes came around as another player in that ecosystem and became popular for a reason, largely so we didn't have to manage clusters with imperative non-idempotent scripts with no runtime introspection or self-healing. I've done light devops (lab scale, not enterprise) off and on since cfengine was a thing, and while I'm no fan of the explosion of YAML (there's a special place in hell for helm in particular for using text/template to generate yaml), I'll take the controller loop design any day over most of the alternatives. Just having a sane API alone is a godsend: you ever try scripting vSphere?

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

#17

Post by pjmlp »

chuckadams wrote: post #16
pjmlp wrote: post #15

Earlier quoted context omitted.

Somehow we were doing that with deployment scripts and VM management tooling before Kubernetes became a thing, and without having to deal with YAML spaghetti.

Yes, and Kubernetes came around as another player in that ecosystem and became popular for a reason, largely so we didn't have to manage clusters with imperative non-idempotent scripts with no runtime introspection or self-healing. I've done light devops (lab scale, not enterprise) off and on since cfengine was a thing, and while I'm no fan of the explosion of YAML (there's a special place in hell for helm in particu…

What sane API, for what Kubernetes runtime, in what version?

Because that is the thing, not only it is a YAML spaghetti, everything changes depending on the puzzle pieces.

I had to follow CNCF related podcasts only to be aware of what cool projects were changing Kubernetes all the time.

Thankfully nowadays I only care about managed containers, regardless how the hyperscalers do it, it is no longer my headache.

Never needed to deal with vSphere directly.

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

#18

Post by chuckadams »

pjmlp wrote: post #17
chuckadams wrote: post #16

Earlier quoted context omitted.

Yes, and Kubernetes came around as another player in that ecosystem and became popular for a reason, largely so we didn't have to manage clusters with imperative non-idempotent scripts with no runtime introspection or self-healing. I've done light devops (lab scale, not enterprise) off and on since cfengine was a thing, and while I'm no fan of the explosion of YAML (there's a special place in hell for helm in particu…

What sane API, for what Kubernetes runtime, in what version? Because that is the thing, not only it is a YAML spaghetti, everything changes depending on the puzzle pieces. I had to follow CNCF related podcasts only to be aware of what cool projects were changing Kubernetes all the time. Thankfully nowadays I only care about managed containers, regardless how the hyperscalers do it, it is no longer my headache. Never…

Kubernetes is built around a JSON API: those yaml files are just an encoding of the objects that it manipulates with fairly vanilla REST commands. You could actually use JSON in your manifests instead, it's a proper subset and all, though it's not going to help the verbosity. For that you need a better abstraction like Pulumi, cdk8s, Yoke, or even just good old Terraform/OpenTofu. Or just write your own, there's an openapi spec and clients in every language out there.

I'm hardly trying to pretend like I'm a hyperscaler: I usually run k3s on a single node, and most of the time I admin it "clickops" style with k9s, something I find much easier than most other management tools.

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

#20

Post by LaurensBER »

pjmlp wrote: post #15
LaurensBER wrote: post #4

Earlier quoted context omitted.

Kubernetes makes complex things (e.g blue/green deployment, auto-scaling, failover) possible irrespective of the underlying cloud/hardware with a good and standardized API. It's absolutely overkill for small teams and homelabs (I run a cluster myself) but an absolute godsend if you do need the advanced functionality.

Somehow we were doing that with deployment scripts and VM management tooling before Kubernetes became a thing, and without having to deal with YAML spaghetti.

Yes but Kubernetes takes these battle-tested scripts, and allow everyone to use them with a few lines of YAML ;)

I understand the dislike of YAML but a Kubernetes deployment is ~50 lines, if I had to build my own scripts with a similar feature set I don't think I would be able to get it down much more than that.

Post reply on HN