<p>What is the relationship between EXPOSE in the dockerfile and TARGETPORT in the service YAML and actual running port in the Pod ?</p>

<p>In my dockerfile</p>

<pre><code>expose 8080
</code></pre>

<p>in my deployment</p>

<pre><code>ports:
  - containerPort: 8080
</code></pre>

<p>In my service</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
 name: xtys-web-admin
spec:
 type: NodePort
 ports:
  - port: 8080
    targetPort: 8080
 selector:
  app: xtys-web-admin
</code></pre>

<p>In my pod</p>

<pre><code>kubectl exec xtys-web-admin-7b79647c8d-n6rhk -- ss -tnl
State      Recv-Q Send-Q        Local Address:Port          Peer Address:Port 
LISTEN     0      100                       *:8332                     *:*     
</code></pre>

<p>So, in the pod actually running 8332( from some config file).
my question is how does it still works ? it works,but i doubt it, someone can clarify it?</p>

<p>In the Dockerfile, <code>EXPOSE</code> is documentation by the image creator to those running the image for how they have configured the image. It sets metadata in the image that you can inspect, but otherwise does not impact how docker configures networking between containers. (Many will confuse this for publishing a port on the host, which is very different than exposing the port. Publishing a port in docker actually creates a mapping to allow the container to be externally accessed.)</p>

<p>The value of <code>containerPort</code> is a runtime equivalent of <code>EXPOSE</code> to expose a port that was not specified in the image. This, again, is documentation only, but may be used by other tooling that inspects running images to self configure. I've mostly seen this used by reverse proxies that default to the exposed port if you do not specify a port to connect.</p>

<p>It is possible for someone to configure an image to listen on a different port number than the image creator documented in their <code>EXPOSE</code>. For example, the nginx image will document that it listens on port 80 with it's default configuration, but you could provide your own <code>nginx.conf</code> file and reconfigure it to listen on port 8080 inside the container instead (e.g. if you did not want to run nginx as root).</p>

<hr>

<p>Now for the service side:</p>

<p>The value of <code>targetPort</code> in a Kubernetes service needs to refer to the port the running container is actually listening on. Typically this is the same as the exposed port, but if you reconfigure your application like in the example above, you would set <code>targetPort</code> to 8080 instead of 80.</p>

<p>The vaule of <code>port</code> in a Kubernetes service is the port the service itself listens on. For inter-container communication, you need to connect on this port, and it will often be the same as the <code>targetPort</code> to reduce confusing.</p>

<p>Lastly, the value of <code>nodePort</code> in a Kubernetes service is the port published on the nodes for you to externally access your container. By default, this goes in the ephemeral port range starting at 30000.</p>
