> I know you wanted to "choose boring tech" to just run some containers. The people advocating for boring tech generally aren't interested in containers. You can just run programs.
Containers are just statically-linked programs for the rest of us.
Dear friend, you have built a Kubernetes (2024)
21–30 of 183 posts
Re: Dear friend, you have built a Kubernetes (2024)
#22The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…
Claude Code has essentially fixed this perpetual annoyance for me. Doesn't matter if it's a hacked up deploy.sh that mixes sed, envsubst and god knows what or a non-idiomatic Helm chart that was perpetually on my backlog to fix... today I just say "make this do this thing and also fix any bash bugs along the way" and it just does it. Its effectiveness for these thousand-little-cuts type DevOps tasks is underrated IMO.
Now the actual CI/CD/thing-doers tools that all suck... I'm still stuck with those.
Re: Dear friend, you have built a Kubernetes (2024)
#23PREACH!
I run K8s at home. I used to do docker-compose - and I'd still recommend that to most people - but even for my 1 little NUC with 4vcpu / 16Gi Homelab, I still love deploying with K8s. It's genuinely simpler for me.
If anyone's looking for inspiration, my setup:
* ArgoCD pointed to my GitLab repos
* GitLab repos contain Helm charts
* Most of the Helm charts contain open-source charts as subcharts, with versions set like (e.g.) `version: ~0` - meaning I automatically receive updates for all major version until `1`
* Updating my apps usually consists of logging into the UI, reviewing the infrastructure and image tag updates, and manually clicking sync. I do this once every few months
My next little side project: Autoscaling into the cloud (via a secure WireGuard tunnel) when I want to expand past my current hardware limitations
Re: Dear friend, you have built a Kubernetes (2024)
#24Earlier quoted context omitted.
How do you handle cleanups and hooks? The best way to do helm, at least for me, seems to be about limiting its use to simple templating use cases; if you end up needing an if, you've probably done something terribly wrong.
Seems to be a case of the XY problem. What do you need cleanups and hooks for?
Cleanups: I want to do a `helm uninstall` and have all the manifests go away at once instead of looking around for N different resources.
Hooks: I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster (at places I've worked, the CI cluster and K8s cluster were completely separate).
Re: Dear friend, you have built a Kubernetes (2024)
#25IMO, Kubernetes isn't inevitable, and this seems to paint it as such. K8s is well suited to dynamically scaling a SaaS product delivered over the web. When you get outside this scenario - for example, on-prem or single node "clusters" that are running K8s just for API compatibility, it seems like either overkill or a bad choice. Even when cloud deployed, K8s mostly functions as a batteries-not-included wrapper around…
> K8s is well suited to dynamically scaling a SaaS product delivered over the web
It’s well suited to other things as well, people are just in denial about some of them.
“I need to run more than two containers and have a googleable way to manage their behavior” is a very common need.
Re: Dear friend, you have built a Kubernetes (2024)
#26This is obviously slightly exaggerated, but I do feel like this whenever people dismiss Kubernetes as either too complicated or not needed. The response I always got when suggesting Kubernetes is "you can do all those things without Kubernetes" Sure, of course. There are a million different ways to do everything Kubernetes does, and some of them might be simpler or fit your use case more perfectly. You can make diffe…
Honestly the main problem is people using k8s for something that's like... a database, and an app, and maybe a second app, that all could be containers or just a systemd service.
And then they hit all the things that make sense in big company with like 40 services but very little in their context and complain that complex thing designed for complex interactions isn't simple
Re: Dear friend, you have built a Kubernetes (2024)
#27The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…
If few lines of scripting is your problem you shouldn't be programming
Re: Dear friend, you have built a Kubernetes (2024)
#28Criticisms of Kubernetes generally come from a few places: - People who would prefer their way of doing this, whether that's deployments on VMs, or use some sort of simpler cloud provider. I had the same opinion a few years ago, but have kind of come to like it, because I can cleanly deploy multiple applications on a cluster in a declarative fashion. I still don't buy the "everything on K8s", and my personal setup is…
Another case: People who want to run workloads that are inherently incompatible with Kubernetes networking model. For example: * For some cursed reasons you want to make sure every single one instance of a large batch job see just one NIC in its container and they are all the same IP and you NAT to the outside world. Ingress? What ingress? This is a batch job! * Like the previous point, except that your "batch job" s…
You can configure k8s so pod to pod networking works just fine so I'm not even sure what complaint here is
Re: Dear friend, you have built a Kubernetes (2024)
#29I somehow feel that it's actually the opposite. It should be "Dear kubernetes user, you have just built a shell".
Re: Dear friend, you have built a Kubernetes (2024)
#30Criticisms of Kubernetes generally come from a few places: - People who would prefer their way of doing this, whether that's deployments on VMs, or use some sort of simpler cloud provider. I had the same opinion a few years ago, but have kind of come to like it, because I can cleanly deploy multiple applications on a cluster in a declarative fashion. I still don't buy the "everything on K8s", and my personal setup is…
Another case: People who want to run workloads that are inherently incompatible with Kubernetes networking model. For example: * For some cursed reasons you want to make sure every single one instance of a large batch job see just one NIC in its container and they are all the same IP and you NAT to the outside world. Ingress? What ingress? This is a batch job! * Like the previous point, except that your "batch job" s…
That is indeed a weirdly cursed requirement. Why? Black box of legacy stuff? A system that was never designed to be run in multiple does so if all the nodes think they’re the same machine? Defeating a license restriction?