一、service简介
Service：标准资源类型，Service Controller（service发挥作用依赖控制器发挥作用）
1、为动态的一组pod提供一个固定的访问入口，Cluster IP（Cluster Network）
2、service会根据标签选择器查找到符合条件的pod，还能够对后端端点做就绪状态检测，如果pod是就绪的那service会把它加载到自己后端可用列表中来，否则就会将其移除掉。
这个功能并不是service做的，他借助一个中间组件，叫做endpoint，service控制器会根据标签选择器创建一个同名的endpoint资源，随后endpoint介入， 会使用endpoint的标签选择器来查找符合条件的pod，endpoint的标签选择器与service的标签选择器一模一样，属于继承关系。
Endpoint：标准资源类型，Endpoint Controller（endpoint发挥作用依赖控制器发挥作用）
二、kube-proxy简介
kube-proxy：Service Controller位于各节点上的agent；
三种代理模型：
Userspace：用户空间与内核空间交互，通过拦截规则（k8s已不再支持）
iptables：kube-proxy时刻监视着apiserver中所有service的定义，
并转为自己本地的iptables规则，不光拥有拦截还有调度。
ipvs：拦截及调度规则，规则数量将更少，规模较大集群中必然要用到ipvs。
kube-proxy和service关系：
1、service定义在apiserver中，是一个数据项，而service controller 负责将其触发实际是触发的endpoint（参考上面service简介），kube-proxy时刻监视着apiserver中所有service的定义，任何节点的service创建，kube-proxy都会转化为自己本地的iptables规则。
2、client pod1访问 server pod1 ：
任何节点的ipvs或iptables规则，通常只负责本地节点上的user space中pod作为客户端发出请求时的过滤规则或调度规则。所以pod1访问server pod1或server pod2时候，请求报文会先到达本机的内核空间，进而被iptables或ipvs规则所捕获（iptables一般在PREROUTING链上，ipvs规则是借助于PREROUTING链上的iptables有限的一两条规则，发送至input规则链上，因为ipvs一般在input链上）随后被ipvs所调度。
3、client pod1访问 service：
pod1会把请求报文发给内核，因为目标地址很有可能不在本机，因为pod网络和service网络本来就不在一个网络，pod访问service一定先发给内核，由内核进行路由的，于是会到达iptables或netfilter之上，netfilter之上的iptables规则捕获到这个请求并且能够匹配到这个报文，也就是到达某一个service的报文，这个报文会告诉你到达后端端点的有哪几个pod，更重要的是这个iptables规则还会给你从中挑选一个出来，于是如果挑中的是本机的，即转给本机，挑中是其他节点的就转给其他主机。所以说iptables既要拦截请求又要调度请求。
二、service四种类型
Service的四种类型
ClusterIP：通过集群内部IP地址暴露服务，但该地址仅在集群内部可见、可达，它无法被集群外部的客户端访问；默认类型；
NodePort：NodePort是ClusterIP的增强类型，它会于ClusterIP的功能之外，在每个节点上使用一个相同的端口号将外部流量引入到该Service上来。
LoadBalancer：LB是NodePort的增强类型，要借助于底层IaaS云服务上的LBaaS产品来按需管理LoadBalancer。
ExternalName：借助集群上KubeDNS来实现，服务的名称会被解析为一个CNAME记录，而CNAME名称会被DNS解析为集群外部的服务的IP地址； 这种Service既不会有ClusterIP，也不会有NodePort；
ClusterIP：建议由K8S动态指定一个； 也支持用户手动明确指定；
ServicePort：被映射进Pod上的应用程序监听的端口； 而且如果后端Pod有多个端口，并且每个端口都想通过SErvice暴露的话，每个都要单独定义。最终接收请求的是PodIP和containerPort；
