top | item 28442072

(no title)

monus | 4 years 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.‬

discuss

order

littlestymaar|4 years ago

> 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)

corobo|4 years ago

> 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"

necrobrit|4 years ago

100% and one of the great things about k8s is that this diagram applies to essentially any application. Standardisation is awesome.

capableweb|4 years ago

Proper standardization is awesome. De facto, corp-owned standarization not so much.

hughrr|4 years ago

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.

Aeolun|4 years ago

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.

ajb|4 years ago

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.

zorr|4 years ago

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.