Google admits Kubernetes container tech is too complex

Re:Google admits Kubernetes container tech is too complex by diarrhea on Friday February 26, 2021 @05:22AM (#26273296)

A friend of mine is a contributor to k8s itself, and of course, this all comes incredibly easy to them. Following their recommendation, I gave it a shot for my single-person, single-node (!) homelab, all without using MicroK8s, k3s or similar.

After a week of almost full-time work, I threw in the towel. Admittedly, I also had to learn concepts like reverse proxies alongside, too, so I was by no means well-equipped to begin with.

Yet, tossing together some docker-compose.yml files and "managing" them with a Python script has worked very well. Kubernetes really scarred me in that sense, and I am healed! Also, Caddy has helped me in actually enjoying configuring the webserver.

[ Parent | on HN ]

Re:Google admits Kubernetes container tech is too complex by dilyevsky on Saturday February 27, 2021 @06:05PM (#26289010)

Wait so running a kubeadm init and then removing a master taint took you whole week to figure out? How long ago was that?

[ Parent | on HN ]

Re:Google admits Kubernetes container tech is too complex by diarrhea on Sunday February 28, 2021 @04:20AM (#26291917)

No, setting up ingress did. Couldn't get reverse-proxying to work.

[ Parent | on HN ]

Re:Google admits Kubernetes container tech is too complex by dilyevsky on Sunday February 28, 2021 @04:55PM (#26297467)

Ah ok. For a single node homelab setups I just throw everything on hostNetwork, second choice is NodePort (if there are port conflicts). In general k8s ingress on baremetal requires deeper understanding of its network design

[ Parent | on HN ]

Re:Google admits Kubernetes container tech is too complex by randomswede on Monday March 01, 2021 @04:23AM (#26300988)

I would (probably) spin up an ingress-controller on ports 80 and 443, using hostNetwork, then use Ingresses from then on (and as it's a single-node cluster, just create a wildcard DNS A record, and possibly an anchor for other CNAMEs to point at (depending on DNS server) pointing at the IP said ingress-controller is running on).

Does mean that anything that upsets the ingress controller is an outage, but for experimentation, that's probably OK.

[ Parent | on HN ]

Re:Google admits Kubernetes container tech is too complex by ahoka on Friday February 26, 2021 @06:07AM (#26273560)

Yeah, of course running random docker compose files and containers from the internet and blissfully exposing your mongodb or whatnot service unsecured to the whole world seems like an easy, non-complicated alternative. Kubernetes has a few shitty defaults, like exposing a service account for all pods by default or allowing to mutate pod image tags, but most of the functionality it provides is a must have when you actually care about your SLA. Rolling updates with health check and configured back-off time? Separate ingress for OAM and live traffic with automatic HTTPS, etc? I could go on.

[ Parent | on HN ]

Re:Google admits Kubernetes container tech is too complex by diarrhea on Friday February 26, 2021 @12:26PM (#26277286)

Are you having a bad day?

I am talking about a homelab, a single server at home, for home use. It's much safer now, with Docker compose, because I understand it and I wrote the core exposed part's configuration, the Caddyfile, myself, manually. I know exactly what's exposed, and it's exactly right the way it is!

The remaining risk comes from the services themselves having security holes, but k8s has that very same risk.

[ Parent | on HN ]