Container Network Instance
3 port settings in the service
The concepts of these ports are easy to confuse, 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 the service is exposed on the service’s cluster ip (virsual ip). Port is the service port which is accessed by others with cluster ip.
That is, the port here means: the port of the service exposed on the cluster ip, and <cluster ip>: port is the entry provided to the internal customers of the cluster to access the service.
nodePort
On top of having a cluster-internal IP, expose the service on a port on each node of the cluster (the same port on each node). You'll be able to contact the service on any<nodeIP>:nodePortaddress. So nodePort is alse the service port which can be accessed by the node ip by others with external ip.
First of all, nodePort is a way for kubernetes to provide customers outside the cluster to access the service entry (the other way is LoadBalancer), so <nodeIP>:nodePort is the entry for customers outside the cluster to access the service.
targetPort
The port on the pod that the service should proxy traffic to.
The targetPort is well understood. The targetPort is the port on the pod. The data coming from the port and nodePort finally flows through the kube-proxy to the targetPort of the backend pod and enters the container.
port, nodePort summary
In general, port and nodePort are both service ports. The former is exposed to the client access service within the cluster, and the latter is exposed to the client access service outside the cluster. The data coming from these two ports needs to flow into the targetPod of the backend pod through the reverse proxy kube-proxy, so as to reach the container on the pod.
When a client connects to the VIP 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 that 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 cases the client IP does get altered.
kube-proxy与iptables
当service有了port和nodePort之后，就可以对内/外提供服务。那么其具体是通过什么原理来实现的呢？奥妙就在kube-proxy在本地node上创建的iptables规则。
Kube-Proxy 通过配置 DNAT 规则（从容器出来的访问，从本地主机出来的访问两方面），将到这个服务地址的访问映射到本地的kube-proxy端口（随机端口）。然后 Kube-Proxy 会监听在本地的对应端口，将到这个端口的访问给代理到远端真实的 pod 地址上去。
kube-proxy会在nat表里生成4个chain，分别如上所示（主要是从容器出来的访问，从本地主机出来的访问两方面）。
创建service以后，kube-proxy会自动在集群里的node上创建以下两条规则：
KUBE-PORTALS-Container
KUBE-PORTALS-HOST
如果是NodePort方式，还会额外生成两条：
KUBE-NODEPORT-CONTAINER
KUBE-NODEPORT-HOST
KUBE-PORTALS-CONTAINER
主要将由网络接口到来的通过服务集群入口<cluster ip>:port的请求重定向到本地kube-proxy端口（随机端口）的映射，即来自本地容器的服务访问请求；
注：我认为，这种情况的网络包不可能来自外部网络，因为cluster ip是个virtual ip，外部网络中不存在这样的路由将该数据包发送到本机；所以该请求只能来自本地容器，从本地容器出来的访问，服务访问请求是通过本地容器虚拟网卡输入到本地网络接口的。
KUBE-NODEPORT-CONTAINER
主要将由网络接口到来的通过服务集群外部入口<node ip>:nodePort的请求重定向到本地kube-proxy端口（随机端口）的映射；即来自k8s集群外部网络的服务访问请求，可以来自本机容器，也可以来自其他node的容器，还可以来自其他node的进程；
KUBE-PORTALS-HOST
主要将该node本地进程通过服务集群入口<cluster ip>:port的请求重定向到本地kube-proxy端口（随机端口）的映射。
KUBE-NODEPORT-HOST
It mainly redirects the request of the node local process to the local kube-proxy port (random port) through the external entry <node ip>:nodePort of the service cluster.
kube-proxy reverse proxy
Whether it is through the cluster internal service entry <cluster ip>:port or through the cluster external service entry <node ip>:nodePort, the request will be redirected to the mapping of the local kube-proxy port (random port), and then to this kube- Access to the proxy port is proxied to the remote real pod address.
one example
another example
http://blog.csdn.net/xinghun_4/article/details/50492041