首先，要理解K8s的用处其实是容器的编排和管理

flannel到底做了什么？

flannel组建一个大二层扁平网络，pod的ip分配由flannel统一分配，通讯过程也是走flannel的网桥。
每个node上面都会创建一个flannel0虚拟网卡，用于跨node之间通讯。所以容器直接可以直接使用pod id进行通讯。
跨节点通讯时，发送端数据会从docker0路由到flannel0虚拟网卡，接收端数据会从flannel0路由到docker0。

为什么会有Service？

如果Pod是一组应用容器的集合，那Service是不是就没有意义了，他的意义在于当应用服务需要做负载、需要做全生命周期的跟踪和管理时就体现出来了，所以Service是一个抽象的概念，它定义了Pod逻辑集合和访问这些Pod的策略。
一个非常常见的场景，当一个Pod因为某种原因停止运行了，kubelet根据deployment的需求重新启动一个新的Pod来提供之前Pod的功能，但是flannel会给这个新的Pod分配一个新的IP，这会带来很大的Effort，应用服务的很多配置项都需要调整，如果有了Service呢，这就不是问题，看下Service的运行原理。

 

KubeProxy的实现模式

这张图解释了Service的运行机制，当Service A创建的时候，Service Controller和EndPoints Controller就会被触发更新一些资源，例如基于Service中配置的Pod的selector给每一个Pod创建一个EndPoint资源并存入etcd，kube-proxy还会更新iptables的chain规则生成基于Service的Cluster IP链路到对应Pod的链路规则，接下来集群内的一个pod想访问某个服务，直接cluster ip:port即可基于iptables的链路将请求发送到对应的Pod，这一层有两种挑选pod的算法，轮询(Round Robin)和亲和度匹配(Session Affinity)。当然，除了这种iptabels的模式，还有一种比较原始的方式就是用户态的转发，Kube-Proxy 会为每个 Service 随机监听一个端口 (Proxy Port)，并增加一条 IPtables 规则。从客户端到 ClusterIP:Port 的报文都会被重定向到 Proxy Port，Kube-Proxy 收到报文后，通过 Round Robin (轮询) 或者 Session Affinity（会话亲和力，即同一 Client IP 都走同一链路给同一 Pod 服务）分发给对应的 Pod。

当然，新版本的k8s开始基于ipvs来替换iptables了，但是形式和iptables是类似的。
概念图可以参看：

UserSpace

这是最原始的方式，参看下图：

Iptables

 

Ipvs

IPVS是 LVS 项目的一部分，是一款运行在 Linux Kernel 当中的 4 层负载均衡器，性能异常优秀。使用调优后的内核，可以轻松处理每秒 10 万次以上的转发请求。目前在中大型互联网项目中，IPVS 被广泛的用于承接网站入口处的流量。