网络模型
在Kubernetes⽹网络中存在两种IP
- Pod IP: Pod IP 地址是实际存在于某个⽹网卡, (可以是虚拟设备)上的
- Service Cluster IP: Service Cluster IP它是⼀一个虚拟IP，是由kube-proxy使⽤用Iptables规则重新定向到其本地端⼝口，再均衡到后端Pod的。
基本原则
每个Pod拥有唯一的IP（IP per Pod），而且假定所有的pod都在⼀一个可以直接连通的、扁平的⽹网络空间中
这个Pod IP被该Pod内的所有容器共享，并且其它所有Pod都可以路由到该Pod。
你可曾注意到，你的Kubernetes节点上运行着一些"pause"容器？它们被称作“沙盒容器（sandbox containers）"，其唯一任务是保留并持有一个网络命名空间（netns），该命名空间被Pod内所有容器共享。通过这种方式，即使一个容器死掉，新的容器创建出来代替这个容器，Pod IP也不会改变。这种IP-per-pod模型的巨大优势是，Pod和底层主机不会有IP或者端口冲突。我们不用担心应用使用了什么端口。
Pod
同一个主机上的Pod，因为都分配了一个veth，插入了主机的root network namespace，共享了一个netns，并且同在docker0网桥上，所以能够通信。
不同主机上的Pod，通过主机路由表来转发数据。需要满足2个条件： 1、Pod的IP不不能冲突； 2、将Pod的IP和所在的Node的IP关联起来，通过这个关联让Pod可以互相访问。
Pod和Service
Pod会创建和销毁，所以Pod的IP不会固定。所以Kubernetes引进了Service.
Service是一个抽象的实体，Kubernetes在创建Service实体时，为其分配了一个虚拟的IP，当我们需要访问Pod里的容器提供的功能时，我们不直接使用Pod的IP地址和端口，而是访问Service的这个虚拟IP和端口，由Service把请求转发给它背后的Pod.
Kubernetes在创建Service时，根据Service的标签选择器（Label Selector）来查找Pod，据此创建与Service同名的EndPoints对象。当Pod的地址发生变化时，EndPoints也随之变化。Service接受到请求时，就能通过EndPoints找到请求转发的目标地址。
Kube-proxy
Kube-proxy是一个简单的网络代理和负载均衡器，它的作用主要是负责Service的实现，具体来说，就是实现了内部从Pod到Service和外部的从NodePort向Service的访问。
实现方式：
userspace是在用户空间，通过kuber-proxy实现LB的代理服务，这个是kube-proxy的最初的版本，较为稳定，但是效率也自然不太高。iptables是纯采用iptables来实现LB，是目前kube-proxy默认的方式。
在这种模式下，kube-proxy监视Kubernetes主服务器添加和删除服务和端点对象。对于每个服务，它安装iptables规则，捕获到服务的clusterIP（虚拟）和端口的流量，并将流量重定向到服务的后端集合之一。对于每个Endpoints对象，它安装选择后端Pod的iptables规则。
