第二个容器和第一个容器共享网络命名空间。第一个容器是Netowrk Container，它不做任何事情，只是用来接管Pod 的网络。这样做的好处在于避免容器间的相互依赖，使用一个简单的容器来统一管理网络。

　　Pod 间的通信

　　Pod 间的通信使用的是一个内部IP，这个IP就是Network Container 的IP。

　　以dashboard 为例：

　　同一个Node 上的Pod 通过Veth 连接在同一个docker0 网桥上，地址段相同，原生能通信。但是不同Node 之间的Pod 如何通信的，本质是在网路上再架设一层overlay network 使容器的网络运行在这层overlay 网络上。现有的方案有Flannel,OpenVSwitch,Weave 等。本文Kubernetes 环境是采用Flannel。

　　Flannel 使用Linux 通用TUN/ TAP 设备， 并使用UDP 封装IP 数据包创建一个覆盖网络。它使用etcd 维护子网的分配和overlay 网络和实际IP 的映射。

　　下图是Flannel 的原理图：

　　Pod 到Service 通信

　　查看dashboard 的Service 的VIP(Virtual IP) 和后端Pod 的IP：

　　那么dashboard 就可以通过10.254.104.235来进行访问，执行iptables-save：

　　然后执行lsof –i:30250：

　　可以看到Kube-Proxy 进程监听在30250端口上，这个进程可以看做是Service 的透明代理兼负载均衡器，对于Service 的访问请求将被这个进程转发到后端Pod。

　　对于Pod 的变化会及时刷新。那么Service 就是在Pod 间起到中转和代理的作用。

　　下图中可以很好的反映整个流程：

　　当一个客户端访问这个Service 时，这些iptable 规则就开始起作用，客户端的流量被重定向到Kube-Proxy 为这个Service 打开的端口上，Kube-Proxy 随机选择一个后端Pod 来进行服务。

　　外部到内部的通信

　　Kubernetes 支持两种对外服务的Service 的Type 定义：NodePort 和LoadBalancer。

NodePort：在每个Node 上打开一个端口并且每个Node 的端口都是一样的，通过:NodePort 的方式，Kubernetes 集群外部的程序可以访问Service；

LoadBalancer:通过外部的负载均衡器来访问。

　　参考：

https://github.com/kubernetes/kubernetes/blob/v1.0.1/docs/design/networking.md