Hacker News new | ask | show | jobs
by monus 1740 days ago
‪That’s not an architecture diagram though, so it doesn’t represent the complexity at all.

I’m sure a troubleshooting map for bare linux server wouldn’t be less complicated than that.‬

4 comments

> I’m sure a troubleshooting map for bare linux server wouldn’t be less complicated than that.‬

Except your k8s runs on a Linux server, so this is just an addition. (Unless you're using a fully managed k8s cloud offering, but then you have an even bigger toubleshooting flowchart to navigate the provider's management interface: at least that's my experience with GKE, maybe Amazon and others are better)

> Except your k8s runs on a Linux server,

Wouldn't it be more likely in this case that the server is built from configs? Ansible or whatever

The troubleshooting for the Linux server side is "spin up a new one and delete the old one"

100% and one of the great things about k8s is that this diagram applies to essentially any application. Standardisation is awesome.
Proper standardization is awesome. De facto, corp-owned standarization not so much.
Unfortunately as a k8s user in the real world every container is slightly different and has numerous hacks in it to make it compatible with k8s in some way or another. So no.
This is an underappreciated point. I love k8s. I hate the shit people decide to do in k8s.

At a previous employer, we had a k8s cluster with a bunch of machines that were designed to a) load a filesystem kernel module inside the container (yes inside, not outside), b) mount /dev from the host in the container with Docker, and c) mount hard drives from the host /dev inside the container using the "mount" command.

In a twist that should surprise no one, those containers don't work well. And they failed to work in crazy, confusing ways for which there is no documentation to troubleshoot, because who in their right mind would do something like that?

I've had better luck in places that have a Platform as a Service team that owns the k8s infra. They generally have a lot more pushback to say "no, you're not going to do that on our cluster" which helps to tamp down some of the crazier ideas.

To be fair, the steps seem to map pretty well to the number of kubernetes resources you would need to create to do basic things like add a persistent disk, or get traffic to your application.
When I first saw it K8S reminded me a lot of systemd. I wouldn't be surprised if over the next few years each grow the features of the other.
That sounds logical as they kind of perform the same tasks with the difference being that systemd manages workloads on a single system and k8s manages workloads on a cluster.