[dashwav]

TBF with a completely greenfield project and managed K8s (GKE or EKS) you can absolutely get a pretty well set up infra very quickly if you are willing to learn how to do so.

I often get the feeling a lot of the negativity comes (rightfully so) from trying to replicate a current existing project into kubernetes. This is true of almost any paradigm - try replicating a Java EE monolith into Erlang and you are going to have a lot of problems. The big thing to note is that starting a project on Erlang very well might solve the problems that a Java EE project ran into, but that is because they were able to solve them at the ground floor, and just popping a Java EE project with all of it's architecture into an Erlang project will probably end up in a worse spot.

I think that this is what often happens with k8s as well - if you or your company have a currently working implementation that isn't on k8s, of course you won't be able to just easily plop it into a k8s cluster and everything be all well and good, but I think the problem is that people are equating that issue with k8s itself, which is a completely different paradigm.

[solidasparagus]

> managed K8s (GKE or EKS) you can absolutely get a pretty well set up infra very quickly

And then tear your hair out when something doesn't work for some reason and root causing it requires learning a stupid number of layers. k8s is easy until it goes wrong.

[harpratap]

Isn't this the same for every software? How is debugging issues with Linux, NGINX, any complex framework any easier?

[Aeolun]

Well, for one thing, all logs are in /var/log.

If it doesn’t fail just right in kubernetes there might be no logs at all.

I’m thinking on particular about trying to mount filesystems into pods.

[lenkite]

Debugging k8s issues is like debugging a vast distributed monolith with a vague guesses on where the problem occurred.