And a service configuration, ingress, other networking, persistent volumes, a mechanism for updating deployed applications, management of the nodes (even with a managed service like EKS or other cloud solutions), logging, roles, security, etc. If you're a developer and all you have to worry about is one deployment spec, thank your devops team for making your life easier. Kubernetes is great for making the dev team's life easier, but someone did a lot of work to make it that easy for you.

Still need to maintain the cluster though, and boy does it require some fun maintenance. Kubernetes is more than just a distributed docker image scheduler, you also need to install and maintain basic dependencies like the pod networking implementation (a whole virtual IP space!!), DNS, loadbalancing, persistent volumes, monitoring, etc etc. Maybe your cloud provider sets it all up for you, but you're not going to escape having to debug and fix issues with that stuff, whether they be show stopping bugs or performance-impacting inconveniences like higher latency.

You'd weep if you see an actual deployment yaml. What documentation provides is something minimal, and that's very long for something minimal.

Also, self-healing can create interesting problems which are fun to trace, debug and understand.

"Before you begin, make sure your Kubernetes cluster is up and running."

I'm expecting you are getting downvoted because of your assumptive and dismissive statement. The type of deployment you are suggesting is overkill to apply k8s as there is minimal to no orchestration.

Either you’re so good with k8s and are clueless about how rare that expertise is, or more likely, you’re so clueless of how complex and fickle k8s can be if configured wrong but you’re not even aware that you don’t know.

I’ve seen actually decent engineers (maybe they’re not decent?) bring down prod because they accidentally Kubectl deploy’ed from their command line.