一、Service定义
Kubernetes Service定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略----通常称为微服务。这一组Pod能够被Service访问到，通常是通过Label Selector
Service能够提供负载均衡能力，但在使用时具有以下限制：
- 只提供四层负载均衡能力，而没有七层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上四层负载均衡是不支持的
1.1 Service的类型
Service在Kubernetes中有以下四种类型
- ClusterIP：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟IP
- NodePort：在 ClusterIP 基础上为Service在每台机器上绑定一个端口，这样可以通过 NodeIP：NodePort来访问服务
- LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到 NodeIP：NodePort
- ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用，没有任何类型代理被创建，这只有Kubernetes 1.7或更高版本的kube-dns才支持
1.1.1 ClusterIP
ClusterIP主要在每个node节点使用iptables（或ipvs），将发向ClusterIP对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应Pod的地址和端口，进而把数据转发给对应的Pod
为了实现图上的功能，主要需要以下几个组件的协同工作：
- apiserver：用户通过kubectl命令向apiserver发送创建service（svc）的命令，apiserver接收到请求后将数据存储到etcd中
- kube-proxy：Kubernetes的每个节点中都有一个叫做kube-proxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中
- iptables：使用NAT等技术将VIP的流量转至endpoint中
1.1.2 Headless Service
有时候不需要或不想要负载均衡，以及单独的 Service IP。遇到这种情况，可以通过指定ClusterIP（spec.clusterIP）的值为“None”来创建 Headless Service。这类 Service 并不会分配 ClusterIP ，kube-proxy 不会处理他们，而且平台也不会为它们进行负载均衡和路由
1.1.3 NodePort
NodePort的原理是在 node 上开了一个端口，将访问该端口的流量导入到kube-proxy，然后由kube-proxy进一步给到对应的Pod
1.1.4 LoadBalancer
LoadBalancer和NodePort其实是同一种方式，区别在于LoadBalancer比NodePort多了一步，就是可以调用cloud provider去创建LB来向节点导流
1.1.5 ExternalName
这种类型的Service通过返回 CNAME（别名）和它的值，可以将服务映射到 externalName 字段的内容。ExternalName Service是Service的特例，它没有selector，也没有定义任何的端口和Endpoint。相反，对于运行在集群外部的服务，通过返回该外部服务的别名这种方式来为集群内部提供服务
举例：
kind:Service
apiVersion:v1
metadata:
name:my-service-1
namespace:default
spec:
type:ExternalName
externalName:www.baidu.com
当查询主机my-service-1.default.svc.cluster.local（SVC_NAME.NAMESPACE.svc.cluster.local）时，集群的DNS服务将返回一个值 www.baidu.com 的CNAME记录。访问这个服务的工作方式和其他Service是一样，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发
二、代理模式分类
2.1 VIP（虚IP）和Service代理
在Kubernetes集群中，每个Node运行一个 “kube-proxy” 进程。“kube-proxy” 负责为 “Service” 实现了一种VIP的形式，而不是 “ExternalName” 的形式。在Kubernetes v1.0版本，代理完全在userspace。在Kubernetes v1.1版本，新增了iptables代理，但并不是默认的运行模式。从Kubernetes v1.2起，默认就是iptables代理。在Kubernetes v1.8.0-beta.0中，添加了ipvs代理
在Kubernetes 1.14版本开始默认使用ipvs代理
在Kubernetes v1.0版本，** “Service”是4层（TCP/UDP over IP）**概念。在Kubernetes v1.1版本，新增了“Ingress”API（beta版本），用来表示7层（HTTP）服务
不使用round-robin DNS进行负载均衡的原因：
由于DNS存在缓存问题，多次访问都是同一个缓存地址，不能达到期望的负载均衡效果
2.2 代理模式分类
2.2.1 userspace代理模式
2.2.2 iptables代理模式
2.2.3 ipvs代理模式
这种模式，kube-proxy会监视Kubernetes Service对象和Endpoints，调用netlink接口以相应地创建 ipvs 规则并定期与Kubernetes Service对象和Endpoints同步 ipvs 规则，以确保 ipvs 状态与期望一致，访问服务时，流量将被重定向到其中一个后端Pod
与iptables类似，ipvs 有 netfilter 的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，例如：
- rr：轮询调度
- lc：最小连接数
- dh：目标哈希
- sh：源哈希
- sed：最短期望延迟
- nq：不排队调度
⚠️注意：ipvs模式假定在运行 kube-proxy 之前，在节点上都已经安装了 ipvs 内核模块。当 kube-proxy 以 ipvs 代理模式启动时，kube-proxy 将验证节点上是否安装了 ipvs 模块，如果未安装，则 kube-proxy 将回退到 iptables代理模式