The reason behind using pod rather than directly container is that kubernetes requires more information to orchestrate the containers like restart policy, liveness probe, readiness probe. A liveness probe defines that container inside the pods is alive or not, restart policy defines the what to do with container when it failed. A readiness probe defines that container is ready to start serving.

So, Instead of adding those properties to the existing container, kubernetes had decided to write the wrapper on containers with all the necessary additional information.

Also, Kubernetes supports the multi-container pod which is mainly requires for the sidecar containers mainly log or data collector or proxies for the main container. Another advantage of multi-container pod is they can have very tightly coupled application container together sharing the same data, same network namespace and same IPC namespace which would not be possible if they choose for directly using container without any wrapper around it.

Following is very nice article on this:

https://www.mirantis.com/blog/multi-container-pods-and-container-communication-in-kubernetes/

Hope this gives you brief idea.

While a pod might usually be one container, it's very useful for them to not be. Specifically most of the design for Pods originated in Borg, the internal Google container management tool. It had a similar system called "allocs" and over time they found them useful for what we now call "sidecar containers", smaller support services that assist the main container with things like logging, metrics, network support, etc. You can check out more about the history of Kubernetes features from Borg at https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/.