Comparative analysis of port, target port and node port in Kubernetes, and kube-proxy agent

Container Network Instance
3 port settings in the service

These port concepts are easily confusing, such as creating the following service:

APIVERSION:V1
kind:service
metadata:
  Labels:
    name:app1
  name:app1 namespace:default
Spec:
  type:nodeport
  ports:
  -<strong>port:8080
    targetport:8080
    nodeport: 30062</strong>
  selector:
    name:app1

Port

The port that's exposed on the service ' s cluster IP (virsual IP). The port is the service port which was accessed by others with cluster IP.

That is, the port here indicates that the service is exposed to ports on the cluster IP,<cluster ip>:p ort is the portal that is provided to the cluster's internal customers to access the service. Nodeport

On top of have a cluster-internal IP, expose the service on a port in each node of the cluster (the same port on each no DE). You'll be able to contacts the service on any<nodeip>:nodeportaddress. So nodeport are alse the service port which can be accessed by the node IP by others with external IP.

First, Nodeport is a way for kubernetes to provide access to service portals to the cluster's external clients (another way is loadbalancer), so <nodeip>:nodeport Is the portal that is provided to external clients of the cluster to access the service. Targetport

The port on the pod, the service should proxy traffic to.

Targetport is well understood, Targetport is the port on the pod, and data coming from port and Nodeport eventually goes through kube-proxy into the back-end pod's targetport and into the container. Port, Nodeport summary

In general, both port and Nodeport are ports of service, the former exposed to customer access services in the cluster, and the latter exposed to client access services outside the cluster. Data coming from both ports requires a reverse proxy kube-proxy into the targetpod of the back-end pod, thereby reaching the container on the pod.

When a-client connects to the VIP of the iptables rule kicks in, and redirects the packets to the serviceproxy ' s own port (Random port). The service proxy chooses a backend, and starts proxying traffic from the client to the backend. This means so service owers can choose any port they want without risk of collision. the same basic flow executes when traffic comes in through a nodeport or through a loadbalancer, though in those The client IP does get altered. Kube-proxy and Iptables

When the service has port and Nodeport, it can provide services internally/externally. So what is the specific principle to achieve it. The secret is kube-proxy the iptables rule created on the local node.

Kube-proxy maps access to this service address to a local kube-proxy port (random port) by configuring Dnat rules (from container access, from local host access). The kube-proxy then listens on the local port, and accesses the port to the remote real pod address.

Kube-proxy will generate 4 chain in the Nat table, as shown above ( mainly from the container access, from the local host access two aspects ).

After the service is created, Kube-proxy automatically creates the following two rules on node in the cluster:
Kube-portals-container
Kube-portals-host
If you are Nodeport, you will generate an additional two:
Kube-nodeport-container
Kube-nodeport-host
Kube-portals-container

The mapping of the local Kube-proxy port (random port), that is, the service access request from the local container , will be redirected by the service cluster entrance <cluster ip>:p ORT request, which comes from the network interface.

Note: I think that this kind of situation of the network packet can not come from the external network, because the cluster IP is a virtual IP, the external network does not exist such a route to send the packet to the native, so the request can only come from the local container, from the local container access, The service access request is entered into the local network interface through the local container virtual network card. Kube-nodeport-container

The mapping of the local Kube-proxy port (random port) is redirected by the arrival of the network interface via the service cluster external portal <node Ip>:nodeport, that is , the service access request from the K8S cluster external network can come from the native container. It can also come from other node containers and from other node processes ;
Kube-portals-host

The node local process is primarily redirected to the local kube-proxy port (random port) mapping through the service cluster portal <cluster ip>:p ort request.
Kube-nodeport-host

The node local process is primarily redirected to the local kube-proxy port (random port) mapping through the service cluster external portal <node ip>:nodeport request. kube-proxy Reverse Proxy

Whether through the cluster internal service Portal <cluster ip>:p ort or through the cluster external service Portal <node Ip>:nodeport requests are redirected to the local kube-proxy port (random port) mappings. The access to this Kube-proxy port is then given to the proxy to the remote real pod address.

An example

Another example

Welcome to discuss together