Why do we need a port/containerPort in a Kuberntes deployment/container definition?

Question

When I define e.g. a deployment in Kubernetes there is a section with a list of containers and each of them contains an array of ports, e.g.:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

Now the documentation here explicitly says it does not affect connectivity:

List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Cannot be updated.

Now it seems it does not really affect anything and is only informational, but what does that really mean, where is that used?

I have found one use of that is that if port defines a name, it can be referenced from a service by that name.

Is that it or there are some other uses for this specification?

Independency

That's it. For documentation. – Meridethmeridian

Answer 1

As you quote the documentation,

List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Cannot be updated.

the purpose of defining the containerPorts is purely for documentation. It is only used by other developers to understand the port that the container listens to. Kubernetes borrows this idea from docker which does the same with EXPOSE command as mentioned here.

Numeral

it seems like containerPort isn’t purely informational if it has a name, and that name is used as the targetPort by a Service? – Papaya

Answer 2

(I know you mention services in your question but i just want to give some examples of what it looks like.)

If you define a service it can use the name of your container port to reference that port value.

For example, this is your pod definition:

apiVersion: v1
kind: Pod
metadata:
  name: some-pod-name
  labels:
    app: some-label-name
spec:
  containers:
    - name: some-container-name
      image: some-container-image
      ports:
        - containerPort: 8080
          name: some-image-http

Later when you define a service definition, instead of specifying a targetPort as a port number you can instead reference the containerPort name:

apiVersion: v1
kind: Service
metadata:
  name: some-service-name
spec:
  selector:
    app: some-label-name
  ports:
  - port: 4080
    protocol: TCP
    targetPort: some-image-http #this will use port 8080 as defined in the pod.

See the documentation for this here.

Financial

Answer 3

One of the examples where this is being used by 3rd party products is istio and kiali

For a more definitive solution, you could have these endpoints (like /health or /metrics) exposed on a different port and server than your main application, and to not declare this port in your Pod’s container definition as containerPort. This way, the requests will be completely ignored by the Istio proxy, as mentioned in Istio documentation (at the bottom of that page).

Shannon