> And it will likely be buggy with all sorts of edge cases.

I have seen this view in corporate IT teams who’re happy to be “implementers” rather than engineers.

In real life, many orgs will in fact have third party vendor products for internal DNS and cert authorities. Writing bridge APIs to these isn’t difficult and it keeps the IT guys happy.

A relatively few orgs have written their own APIs, typically to manage a delegated zone. Again, you can say these must be buggy, but here’s the thing — everything’s buggy. Including k8s. As long as bugs are understood and fixed, no one cares. The proof of the pudding is how well it works.

Internal DNS in particular is easy enough to control and test if you have engineers (vs implementers) in your team.

> manage changes to load balancers … perl

That’s a very black and white view, that teams are either on k8s (which to you is the bees knees) or a pile of Perl (presumably unmaintainable). Speaks to interesting unconscious bias.

Perhaps it comes from personal experience, in which case I’m sorry you had to be part of such a team. But it’s not particularly difficult to follow modern best practices and operate your own stack.

But if your starter stance is that “k8s is the only way”, no one can talk you out of your own mental hard lines.