K8S Service有这么几种类型：ClusterIP，NodePort和Load Balancer。其中，ClusterIP是默认类型，自动分配集群内部可以访问的虚IP——Cluster IP。NodePort为Service在Kubernetes集群的每个Node上分配一个端口，即NodePort，集群内/外部可基于任何一个NodeIP:NodePort的形式来访问Service。因此NodePort也成为“乞丐版”的Load Balancer，对于那些没有打通容器网络和主机网络的用户，NodePort成了他们从外部访问Service的首选。LoadBalancer类型的Service需要Cloud Provider的支持，因为Service Controller会自动为之创建一个外部LB并配置安全组，K8S原生支持的Cloud Provider就那么几个：GCE，AWS。除了“外用”，Load Balancer还可以“内服”，即如果要在集群内访问Load Balancer类型的Service，kube-proxy用iptables或ipvs实现了云服务提供商LB（一般都是L7的）的部分功能：L4转发，安全组规则等。
K8S Service创建好了，那么如何使用，即如何进行服务发现呢？K8S提供了两种方式：环境变量和域名。
环境变量即Kubelet为每个Pod注入所有Service的环境变量信息，形如：
图15
这种方式的缺点是：容易环境变量洪泛，docker启动参数过长影响性能甚至直接导致容器启动失败。
域名的方式是，假设Service（my-svc）在namespace（my-ns）中，暴露名为http的TCP端口，那么在K8S的DNS服务器会生成两种记录，分别是A记录：域名（my-svc.my-ns）到Cluster IP的映射和SRV记录，例如：_http._tcp.my-svc.my-ns到一个http端口号的映射。我们会在下文Kube-dns一节做更详细的介绍。
前文提到，Service的load balancer模块有iptables和IPVS实现。下面会一一进行分析。
Iptables是用户空间应用程序，通过配置Netfilter规则表（ Xtables ）来构建linux内核防火墙。下面就是K8S利用iptables的DNAT模块，实现了Service入口地址（10.20.30.40:80）到Pod实际地址（172.17.0.2:8080）的转换。
图16
IPVS是LVS的负载均衡模块，亦基于netfilter，但比iptables性能更高，具备更好的可扩展性。
图17
如上所示，一旦创建一个Service和Endpoints，Kube-proxy的IPVS模式会做三样事情：
1）确保一块dummy网卡（kube-ipvs0）存在。至于为什么要创建dummy网卡，因为IPVS的netfilter钩子挂载INPUT chain，我们需要把Service的访问IP绑定在dummy网卡上让内核“觉得”虚IP就是本机IP，进而进入到INPUT chain。
2）把Service的访问IP绑定在dummy网卡上。
3）通过socket调用，创建IPVS的virtual server和real server，分别对应K8S的Service和Endpoints。
