service流量
Kubernetes 之所以需要 Service，一方面是因为 Pod 的 IP 不是固定的（Pod可能会重建），另一方面则是因为一组 Pod 实例之间总会有负载均衡的需求。
Service通过 Label Selector实现的对一组的Pod的访问。
对于容器应用而言。
Kubernetes 提供了基于 VIP（虚拟IP） 的网桥的方式访问 Service，再由 Service 重定向到相应的 Pod。
service的类型：
ClusterIP：提供一个集群内部的虚拟IP以供Pod访问（service默认类型)
NodePort：在每个Node上打开一个端口以供外部访问，Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的，通过:NodePort的方式Kubernetes集群外部的程序可以访问Service。
LoadBalancer：通过外部的负载均衡器来访问。
====service实现原理：
两种方式
1.基于iptables规则来实现。但是当Pod数量过多时，成百上千条 iptables 规则不断地被刷新，会大量占用该宿主机的 CPU 资源。
2. 基于IPVS来实现，IPVS属于内核模块，所以把转发的操作放到内核态中，性能更好。
1. 基于iptables来实现的service
在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy(服务代理) 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式。
也就是说Service 是由 kube-proxy 组件，加上 iptables 来共同实现的。
通过iptables规则，是实现了serviec RR轮询的方式去访问后端的Pod。
2. IPVS模式
Kubernetes 的 kube-proxy 还支持一种叫作 IPVS 的模式
通过上面的讲解，你可以看到，kube-proxy 通过 iptables 处理 Service 的过程，其实需要在宿主机上设置相当多的 iptables 规则。而且，kube-proxy 还需要在控制循环里不断地刷新这些规则来确保它们始终是正确的。
不难想到，当你的宿主机上有大量 Pod 的时候，成百上千条 iptables 规则不断地被刷新，会大量占用该宿主机的 CPU 资源，甚至会让宿主机“卡”在这个过程中。所以说，一直以来，基于 iptables 的 Service 实现，都是制约 Kubernetes 项目承载更多量级的 Pod 的主要障碍。
而相比于 iptables，IPVS 在内核中的实现其实也是基于 Netfilter 的 NAT 模式，所以在转发这一层上，理论上 IPVS 并没有显著的性能提升。但是，IPVS 并不需要在宿主机上为每个 Pod 设置 iptables 规则，而是把对这些“规则”的处理放到了内核态，从而极大地降低了维护这些规则的代价。这也正印证了我在前面提到过的，“将重要操作放入内核态”是提高性能的重要手段。
IPVS 模块只负责上述的负载均衡和代理功能。而一个完整的 Service 流程正常工作所需要的包过滤、SNAT 等操作，还是要靠 iptables 来实现。只不过，这些辅助性的 iptables 规则数量有限，也不会随着 Pod 数量的增加而增加。
在大规模集群里，我非常建议你为 kube-proxy 设置–proxy-mode=ipvs 来开启这个功能。它为 Kubernetes 集群规模带来的提升，还是非常巨大的。
Kubernetes 的 Service 的负载均衡策略，在 iptables 和 ipvs 模式下，都有哪几种？具体工作模式是怎样的？
service 负载分发策略有两种：
RoundRobin：轮询模式，即轮询将请求转发到后端的各个pod上（默认模式）；
SessionAffinity：基于客户端IP地址进行会话保持的模式，第一次客户端访问后端某个pod，之后的请求都转发到这个pod上。