Containerization (Docker, in this case) packages up dependencies into a working piece of code that can theoretically be deployed with the same operational results in dev, staging and production. It can be very useful if multiple services have dependencies that would otherwise conflict with each other if all installed on the same base operating system. Containers are faster to start up than virtual machines and can have less overhead. Their images are typically smaller than their VM counterparts. Most folks don't likely need the default overlay network it creates and can simply use --net=host to treat their container as yet another service.
Kubernetes is orchestration of containers / services and overlay networks. It certainly can be overly complex and should only be used if your application can be wrapped up in that layer of orchestration. One size does not fit all. In other words, taking a complex set of applications from your IT org and throwing them into K8's can be non trivial and can lead to complexity / fragility as a service. You have to research this topic completely and first understand your goals of how you are going to tie all your services together.
The ability to rapidly enable local testing for dev teams (and new hires).
Imagine you have a team implementing a mysql infrastructure but it won't be done for 2 months. The developers need to start coding using this mysql infrastructure ASAP.
Using Docker, you can just pull a mysql image and have your dev teams develop locally using this image as their app's backend.
You could also deploy that mysql image onto a dev server - now you have instantly enabled the dev teams to start working against an infrastructure that won't be ready for another 2 months.