The documentation has some useful explanations:

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.

Think of such as the unit of “deployment”—And excuse the abuse of terminology here, since deployment itself is a very well defined and precise concept in k8s as well, namely another type of workload. Pods are classified as a workload.

A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. A Pod's contents are always co-located and co-scheduled, and run in a shared context. A Pod models an application-specific "logical host": it contains one or more application containers which are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.

So that’s one part of the answer you’re looking for: a pod models a “logical host” where you can assemble fairly-fully-functional applications (“microservices” if you want, that do 1 basic thing, but do it well) out of one or several containers together.

I like to think of this as some form of composition but brought up to the application level via patterns such as sidecar and adapter. Similar to how you implement cross-cutting concerns in DDD, such as logging, by abstracting them and providing a generic implementation that ought to work the same when used by any class (“attached” to any main container) albeit some wiring work being required. It is precisely that PodSpec that wires these containers up.

As well as application containers, a Pod can contain init containers that run during Pod startup. You can also inject ephemeral containers for debugging if your cluster offers this.

Continues supporting the analogy I gave above to composition in OOP/DDD.

The official documentation continues adding more explanations along those lines.

In terms of Docker concepts, a Pod is similar to a group of Docker containers with shared namespaces and shared filesystem volumes.

Lastly, when you want to run a container in Kubernetes (necessarily through a pod) via kubectl run be careful you are not overriding the container entrypoint/command-args:

When you override the default Entrypoint and Cmd, these rules apply:

• If you do not supply command or args for a Container, the defaults defined in the Docker image are used.
• If you supply a command but no args for a Container, only the supplied command is used. The default EntryPoint and the default Cmd defined in the Docker image are ignored.
• If you supply only args for a Container, the default Entrypoint defined in the Docker image is run with the args that you supplied.
• If you supply a command and args, the default Entrypoint and the default Cmd defined in the Docker image are ignored. Your command is run with your args.