A Deployment, a CronJob, a Secret, etc.: those are the interfaces with Kubernetes. By extension, it is the interface with which you interact with the service (a cluster of machines) that your infra team maintains. (And they are the ones that need to understand how to maintain & operate Kubernetes.)
App devs need to learn the structure of those YAML interfaces. They are incredibly well documented, both in reference material and in example material.
And yet I find the same as the people above you in this thread: app eng have an absolute aversion to wanting to specify, in programmatic form, how to run their app. Yet, by definition, they're the only ones that know how to do that.
(That said, I have been known to reverse engineer applications enough to understand how they intend to be run, and then write the corresponding k8s YAML. This is an organizational anti-pattern, though.)
The YAML isn't complicated. What's complicated is that the set of data that comprises a process is inherently complicated: what user does it run as? what files does it need? what command to execute it? what env vars? etc. k8s's YAML does rather little abstracting over these.
(I sort of disagree with the "fire them" — rather, you need to ensure your onboarding trains them. But a lot of employers these days seem to do zip for training.)
They might very soon. https://archive.ph/YWp4O
K8s includes a lot of Unix. If you don't know what a user or perm is, or a mount point, you just blame k8s.
You have skipped over the Pod and ReplicaSet abstractions, and the Pod part is definitely not ignorable even in the most trivial case. The container part is probably more ignorable than the pod part, since pods are what actually gets exposed for most operations.
So if your developers can't learn this stuff...