No, the abstraction of a container involves not only namespace isolation, but also access to a certain quantity of resources to process and exchange information within and across namespaces.
So, pointing out “extra tools” (kuztomize) to ease difficulties with yet a new abstraction (k8s) is not really the way. You are just convincing yourself that your tool of choice can really solve everything.
Ideally, standard builtin tools should be easier to use, understand, and be less buggy by means of better opiniated solutions, just like some programming languages work for people who never coded before.
A container only knows about what's going on inside it though. If you want to hook those resources up with peers in a decoupled way, that requires an abstraction on top, preferably declarative, or else you faced with a substantial amount of manual (and thus costly and error-prone) management.
We could argue the merits of yaml and I'll happily concede it's not ideal, but the complexity isn't going away and the tools to manage it are pretty standard.
So, pointing out “extra tools” (kuztomize) to ease difficulties with yet a new abstraction (k8s) is not really the way. You are just convincing yourself that your tool of choice can really solve everything.
Ideally, standard builtin tools should be easier to use, understand, and be less buggy by means of better opiniated solutions, just like some programming languages work for people who never coded before.