Hacker News new | ask | show | jobs
by oneplane 2044 days ago
Again, what is it for? If you have a single server, what is K8S going to give you over say, a single static binary or a docker container?

K8S on a single node does nothing for you network-wise, you have no overlay network (because there is nothing to overlay) you have no ingress or egress (there is only 1 node so no matter what you 'configure' your ingress and egress will be that same node), and it's unlikely to have enough resources to do something like a full application deployment with some big helm chart.

While I agree that you can (ab)use K8S as a runtime and packaging format, all of those big benefits are removed when you are running it on 1 node, except perhaps the fact that you can talk to the apiserver and define your jobs/tasks/pods the same way. But even then you'd only do that locally, because 'testing' in a dev or staging env that doesn't match prod is going to give you non-representative results.

1 comments

Ever tried to host multiple apps on a single machine? Oh look, a custom Nginx config only one person understands. Oh look, some hacked up letsencrypt config only one person understands, etc etc.

> K8S on a single node does nothing for you network-wise

- Container IP auto-assignment

- Container security policy

- Container DNS management

- Ingress management ("custom Nginx config")

- "Environment that feels like a large network and doesn't change if moved to a large network"

What part of this is difficult to understand?

> Ever tried to host multiple apps on a single machine? Yep works fine. Has been for decades, even before containers existed. Guess what the sites-available and sites-enabled directories for apache and nginx are for.

> Oh look, a custom Nginx config only one person understands.

Just because you put it in a container doesn't mean it's no longer custom or that everyone suddenly understands it.

> Oh look, some hacked up letsencrypt config only one person understands, etc etc.

Plenty of people put their nasty hacks in containers and pod definitions and still nobody (or just 1 person) understands it. Packaging changes none of this; a dirty pod, container, VM image it's all still dirty.

> K8S on a single node does nothing for you network-wise > - Container IP auto-assignment

So does docker, or even an uncontainerized bridge interface

> - Container security policy

So does Docker, or a plain cgroup

> - Container DNS management Yep, that it does. But when you only have 1 node, what is the point?

> - Ingress management ("custom Nginx config")

Great, but besides moving complexity from your app to the infra it doesn't help at all on a single node. It actually gets worse: node goes down, everything goes down (app, fallback, load balancing, routing, security)

> - "Environment that feels like a large network and doesn't change if moved to a large network"

So unless you are doing some local development that you later on push to dev/prod, we're talking about feelings. Not much objective to say about that except that it exists.

> What part of this is difficult to understand?

All of it. Shoving complexity and responsibility around doesn't reduce it, and having people make bad software isn't less bad because of the runtime it runs on.

Kubernetes in prod is great, and the envs that go with it (like development and staging), sure. But when you run something in prod, and you need availability, scalability and a host of standardised facilities, then a single node or some magic 'it works by default' config is very far removed from real-world production.

We could argue this ad infinitum, K8s of course doesn't remove all proprietary elements from a solution but it is a huge step up. Speaking as an ex-Googler, it took over 10 years but I'm so happy the rest of the world finally has a standard like this, the world is a better place for it even though I at one point had to unlearn all my traditional sysadmin habits and immerse myself in an environment practising it successfully to finally understand.

Your original question was what is the point. These are the points. As for why not Docker, k8s network effects and strategy of its sponsors mean Docker is on a lifeline, everyone knows that.

Of course Docker is doomed ;-) We have CRI-O, gvisor etc. showing that it works fine without it as well. Someone implemented a OCI compatible image runner in bash using standard cgroups, with a bit of luck we'll end up calling containers 'containers' and images 'images' instead of using docker's brand name.

Also, I'm not saying that k8s is bad, or using k8s as a practical API definition of the platform to target when packaging and configuring applications; I was aiming at the 'boo hoo k8s is too hard' tagline every "simple" version seems to hold on to.

One could also install standard K8S and remove the taint and run pods locally, same result.