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