is where the author is just wrong:
- abstracts away ssh - makes it pretty unnecessary
- rbac multi tenancy
- better automations
- orchestating more than one cluster
- better infra as code
- provisions are as good as you make them, if you don't want them only use limits.
- large mind share, bitnami (was) great
I use k3s for my home network because it's simple and easy, thinking that k8s is overengineered just plain wrong - it's just different especially if you compare different versions of k8s designed for different things where for ex: k3s bundles csi, cni, ctl, ingress for you.
I actually struggle with compose ('orchestration' alternative) significantly more since it usually has complicated workarounds to missing features.
I have been running 5 k8s-flavored clusters for more than half a decade between 1 to 40 nodes.
And the docker swarm example didn’t even accomplish the same thing.
> The problem is that 99% of teams don't need any of those knobs.
I keep hoping for a Docker Swarm revival. It's the right size for small-to-medium-size deployments with normal requirements.
I think one of the killer features of k8s is how simple it is to write clients that manipulate the cluster itself, even when they’re running from inside of it. Give them the right role etc and you’re done. You don’t even have to write something as complete as an actual controller/operator - but that’s also an option too
Bind-mounting /var/run/docker.sock gives 100% root access to anyone that can write it. It's a complete non-starter for any serious deployment, and we should not even consider it at any time.
You don’t even need to be a mid-sized team to need stuff like RBAC, service mesh, multi-cluster networking, etc.
Claiming that kubernetes only “won” because of economic pressure is only true in the most basic of sense, and claiming it as a resume padder is flat out insulting to all its actual technical merits.
The multi-tenant nature and innate capabilities is part economics of it, but operators, extensibility, and platform portability across different environments are actual technical merits.
Claiming that autoscaling is optional and not required for most production environments is at best myopic.
It also greatly undersells the operational complexity that autoscaling actually solves, versus just the reactive script based solely on CPU. Metrics pipelines, cluster-level resource constraints, and pod disruption budgets.
As far as the repeated claim that it just “works”, great. Not working is more of a function of the application not the platform.
I dunno, this whole article frames kubernetes as a massive overhead and monolithic beast rather than the programmable infrastructure that it is.
It also tries to minimize many real world needs like multi-team isolation, extensibility, and ecosystem integrations
Author describes his context being a setup with two $83/year VPS instances - a scale so incredibly minuscule compared to typical deployments, that any of his arguments against one of the core cloud technologies fall flat.
Of course he doesn't need Kubernetes. It's fine.
Docker Swarm doesn't have the mindshare for effective hiring
> If you choose to not use the install script, you can run K3s simply by downloading the binary from our GitHub release page, placing it on your path, and executing it. https://docs.k3s.io/installation/configuration#configuration...
