[bionsystem]

None of those arguments make sense.

Uniformity ? Try deploying openbao inside kube, if kube decides to restart your pods, you're in for unsealing them at 3am, waking up everybody who owns a Shamir key. So bao stays out of the cluster, or pinned to certain nodes, defeating the purpose entirely. Also, with the ultra wide variety of tools at every layer of the stack, uniformity is a joke ; there are no 2 kube cluster deployment that are the same really.

Standardized knowledge ? The operating system is standardized knowledge. Any competent SRE should be able to login into a Linux box and figure out what's running there. And if you let your previous ops shadow it all you're just a pretty bad CTO.

Tracing who does what ? First of all anybody with admin access can run one time jobs just like anybody with sudo can run one time commands. That's like chapter 01 of the kube doc. Also again at the kube layer itself, below the helm chart, the ops who set that up or updates it can and will change stuff that breaks stuff.

Kube isn't necessarily bad and has it's purpose but it's not a product. It's like Linux, a complex piece of tech that requires a lot more knowledge than "just push this helm chart" to work.

[bakies]

Sounds like you had specific issues with openbap and your cluster provider. Whatever the tech stack it's all presented the same way and easily discoverable. Kubernetes is a cloud operating system- this is exactly the point about standardized knowledge.

[bionsystem]

I give a counter example to a general statement, in logic, it is enough to debunk the original statement. My point is, SOME things wouldn't run predictably inside the cluster (in that case without pinning to nodes, which the article says isn't necessary, and which in general defeats the purpose), so you'd need to run some things outside of it.

As per standardized knowledge, I can't see how somebody even proficient with kube, could jump into any app and troubleshoot bad behavior. Apps each have their quirks and subtleties, specific components that behave a certain way. The layers still exists, the kube cluster itself (which again has many component options at every layer of the stack ; hard to know them all), and the app (which will require at least some specialty knowledge).

If it's just about pushing helm charts we wouldn't need SRE anymore, just a CI.

[bakies]

The same way you're describing sysadmins knowing how to look at a linux system and understand what's going on. I feel exactly I can jump into any app and troubleshoot on k8s. And I draw on a lot on top of my previous sysadmin exp.

[bionsystem]

So you agree that it is not kube specific, then ?

[bakies]

The debugging? Not really. It comes from sysadmining. But k8s is a standardized way to deploy software amongst a fleet of machines. Which makes it easy to debug complex systems because I know how to access it all.