容器网络实例

服务中的3个端口设置

这几个port的概念很容易混淆，比如创建如下service：

[plain] view plain copy

1. apiVersion: v1
2. kind: Service
3. metadata:
4. labels:
5. name: app1
6. name: app1
7. namespace: default
8. spec:
9. type: NodePort
10. ports:
11. - <strong>port: 8080
12. targetPort: 8080
13. nodePort: 30062</strong>
14. selector:
15. 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.

即，这里的port表示：service暴露在cluster ip上的端口，<cluster ip>:port 是提供给集群内部客户访问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.

首先，nodePort是kubernetes提供给集群外部客户访问service入口的一种方式（另一种方式是LoadBalancer），所以，<nodeIP>:nodePort 是提供给集群外部客户访问service的入口。

targetPort

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

targetPort很好理解，targetPort是pod上的端口，从port和nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort上进入容器。

port、nodePort总结

总的来说，port和nodePort都是service的端口，前者暴露给集群内客户访问服务，后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPod，从而到达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

主要将该node本地进程通过服务集群外部入口<node ip>:nodePort的请求重定向到本地kube-proxy端口（随机端口）的映射。

kube-proxy反向代理

不管是通过集群内部服务入口<cluster ip>:port还是通过集群外部服务入口<node ip>:nodePort的请求都将重定向到本地kube-proxy端口（随机端口）的映射，然后将到这个kube-proxy端口的访问给代理到远端真实的 pod 地址上去。

一个例子

另外一个例子