What Do Docker EXPOSE and Kubernetes containerPort Actually Do?

The fields are also useful to integrations. Monitoring systems, deployment tools, and other automation may inspect `containerPort` or image metadata to infer intended ports. That does not guarantee that anything will scrape or route traffic automatically, though, so you should check the behavior of the specific tool.

Kubernetes is similar, but `containerPort` is not entirely useless documentation. A Pod’s network namespace already accepts traffic sent to the Pod IP; the application must be listening on the port. To make it reachable through a stable address or from outside the cluster, you normally create a Service, Ingress, or another Kubernetes networking resource. A Service can also use a named container port as its `targetPort`, for example mapping Service port 80 to a container port named `http`.

A useful mental model is that a container has its own Linux network namespace. There is no special gate that must be opened by EXPOSE or `containerPort`; a process simply binds to a socket, just as it would on a normal host. Routing, port publishing, firewall rules, and Kubernetes Services determine whether traffic from other networks can reach that socket.

For Docker, EXPOSE mainly records the port as image metadata. It does not publish the port or create a firewall rule. The application still has to listen on that port, and you publish it at runtime with something like `docker run -p 8080:8080`. Docker can also use EXPOSE as a hint with automatic publishing options such as `-P`, and tools can inspect the metadata.