In the ordinary course of events, Pods can be stopped accidentally. Then, the IP of the Pod can be changed. When we expose the port for a Pod or a Deployment, we create a Kubernetes Service that acts as a proxy or a load balancer. Kubernetes would create a virtual IP, which receives the request from clients and proxies the traffic to the Pods in a service. Let's review how to do this:

1. First, we would create a Deployment and expose it to a Service:

$ cat nodeport-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodeport-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nodeport-svc
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
$ kubectl create -f nodeport-deployment.yaml
deployment.apps "nodeport-deploy" created
service "nodeport-svc" created

2. At this moment, check the details of the Service with the subcommand describe:

$ kubectl describe service nodeport-svc
Name:                     nodeport-svc
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=nginx
Type:                     NodePort
IP:                       10.101.160.245
Port:                     <unset>  8080/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  30615/TCP
Endpoints:                192.168.80.5:80,192.168.80.6:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

The virtual IP of the Service is 10.101.160.245, which exposes the port 8080. The Service would then dispatch the traffic into the two endpoints 192.168.80.5:80 and 192.168.80.6:80. Moreover, because the Service is created in NodePort type, clients can access this Service on every Kubernetes node at <NODE_IP>:30615. As with our understanding of the recipe Working with Services in Chapter 2, Walking through Kubernetes Concepts, it is the Kubernetes daemon kube-proxy that helps to maintain and update routing policy on every node.

3. Continue on, checking the iptable on any Kubernetes node:

// Take a look at following marked "Chain"
$ sudo iptables -t nat -nL
...
Chain KUBE-NODEPORTS (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/nodeport-svc: */ tcp dpt:30615
KUBE-SVC-GFPAJ7EGCNM4QF4H  tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/nodeport-svc: */ tcp dpt:30615
...
Chain KUBE-SEP-DIS6NYZTQKZ5ALQS (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  192.168.80.6         0.0.0.0/0            /* default/nodeport-svc: */
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/nodeport-svc: */ tcp to:192.168.80.6:80
...
Chain KUBE-SEP-TC6HXYYMMLGUSFNZ (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  192.168.80.5         0.0.0.0/0            /* default/nodeport-svc: */
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/nodeport-svc: */ tcp to:192.168.80.5:80
Chain KUBE-SERVICES (2 references)
target     prot opt source               destination
...
KUBE-SVC-GFPAJ7EGCNM4QF4H  tcp  --  0.0.0.0/0            10.101.160.245       /* default/nodeport-svc: cluster IP */ tcp dpt:8080
...
KUBE-NODEPORTS  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ADDRTYPE match dst-type LOCAL
...
Chain KUBE-SVC-GFPAJ7EGCNM4QF4H (2 references)
target     prot opt source               destination
KUBE-SEP-TC6HXYYMMLGUSFNZ  all  --  0.0.0.0/0            0.0.0.0/0            /* default/nodeport-svc: */ statistic mode random probability 0.50000000000
KUBE-SEP-DIS6NYZTQKZ5ALQS  all  --  0.0.0.0/0            0.0.0.0/0            /* default/nodeport-svc: */
...

There will be a lot of rules showing out. To focus on policies related to the Service nodeport-svc, go through the following steps for checking them all. The output on your screen may not be listed in the expected order:

1. Find targets under chain KUBE-NODEPORTS with the comment mentioned nodeport-svc. One target will be named with the prefix KUBE-SVC-. In the preceding output, it is the one named KUBE-SVC-GFPAJ7EGCNM4QF4H. Along with the other target KUBE-MARK-MASQ, they work on passing traffics at port 30615 to the Service.
2. Find a specific target named KUBE-SVC-XXX under Chain KUBE-SERVICES. In this case, it is the target named KUBE-SVC-GFPAJ7EGCNM4QF4H, ruled as allowing traffics from "everywhere" to the endpoint of nodeport-svc, 10.160.245:8080.
3. Find targets under the specific Chain KUBE-SVC-XXX. In this case, it is Chain KUBE-SVC-GFPAJ7EGCNM4QF4H. Under the Service chain, you will have number of targets based on the according Pods with the prefix KUBE-SEP-. In the preceding output, they are KUBE-SEP-TC6HXYYMMLGUSFNZ and KUBE-SEP-DIS6NYZTQKZ5ALQS.
4. Find targets under specific Chain KUBE-SEP-YYY. In this case, the two chains required to take a look are Chain KUBE-SEP-TC6HXYYMMLGUSFNZ and Chain KUBE-SEP-DIS6NYZTQKZ5ALQS. Each of them covers two targets, KUBE-MARK-MASQ and DNAT, for incoming and outgoing traffics between "everywhere" to the endpoint of Pod, 192.168.80.5:80 or 192.168.80.6:80.

One key point here is that the Service target KUBE-SVC-GFPAJ7EGCNM4QF4H exposing its cluster IP to outside world will dispatch the traffic to chain KUBE-SEP-TC6HXYYMMLGUSFNZ and KUBE-SEP-DIS6NYZTQKZ5ALQS with a statistic mode random probability of 0.5. Both chains have DNAT targets that work on changing the destination IP of the packets to the private subnet one, the one of a specific Pod.