怎么跟你说Service的出现，就是解决ip不固定的问题，怎么解决呢？听小刘慢慢道来
当Pod宕机后重新生成时，其IP等状态信息可能会变动，Service会根据Pod的Label对这些状态信息进行监控和变更，保证上游服务不受Pod的变动而影响。
一、Service简介
1.1Service概念
KubernetesService定义了这样一种抽象：Service是一种可以访问Pod逻辑分组的策略，Service通常是通过LabelSelector访问Pod组。
Service能够提供负载均衡的能力，但是在使用上有以下限制：只提供4层负载均衡能力，而没有7层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上4层负载均衡是不支持的
s1.2Service类型
Service在K8s中有以下四种类型：
①ClusterIp
默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP
②NodePort
在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过:NodePort来访问该服务。
③LoadBalancer
在NodePort的基础上，借助CloudProvider创建一个外部负载均衡器，并将请求转发到NodePort
④ExternalName
把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有Kubernetes1.7或更高版本的kube-dns才支持。
1.3Service基础导论
客户端访问节点时通过iptables实现的iptables规则是通过kube-proxy写入的apiserver通过监控kube-proxy去进行对服务和端点的监控kube-proxy通过pod的标签（lables）去判断这个断点信息是否写入到Endpoints里
二、代理
2.1VIP和Service代理
在Kubernetes集群中，每个Node运行一个kube-proxy进程。kube-proxy负责为Service实现了一种VIP（虚拟IP）的形式，而不是ExternalName的形式。在Kubernetesv1.0版本，代理完全在userspace。在Kubernetesv1.1版本，新增了iptables代理，但并不是默认的运行模式。从Kubernetesv1.2起，默认就是iptables代理。在Kubernetesv1.8.0-beta.0中，添加了ipvs代理。在Kubernetes1.14版本开始默认使用ipvs代理。
在Kubernetesv1.0版本，Service是4层（TCP/UDPoverIP）概念。在Kubernetesv1.1版本，新增了IngressAPI（beta版），用来表示7层（HTTP）服务为何不使用round-robinDNS？
DNS会在很多的客户端里进行缓存，很多服务在访问DNS进行域名解析完成、得到地址后不会对DNS的解析进行清除缓存的操作，所以一旦有他的地址信息后，不管访问几次还是原来的地址信息，导致负载均衡无效
2.2代理模式分类
①userspace代理模式
②iptables代理模式
③ipvs代理模式
ipvs代理模式中kube-proxy会监视KubernetesService对象和Endpoints，调用netlink接口以相应地创建ipvs规则并定期与KubernetesService对象和Endpoints对象同步ipvs规则，以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod。
与iptables类似，ipvs于netfilter的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，例如：
rr：轮询调度lc：最小连接数dh：目标哈希sh：源哈希sed：最短期望延迟nq：不排队调度
三、Service使用
3.1ClusterIp
ClusterIP主要在每个node节点使用iptables，将发向ClusterIP对应端口的数据，转发到kube-proxy中。然后kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个service下对应pod的地址和端口，进而把数据转发给对应的pod的地址和端口。
为了实现图上的功能，主要需要以下几个组件的协同工作：
apiserver：用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中kube-proxy：Kubernetes的每个节点中都有一个叫做kube-porxy的进程，这个进程负责感知service、pod的变化，并将变化的信息写入本地的iptables规则中iptables：使用NAT等技术将virtualIP的流量转至endpoint中创建myapp-deploy.yaml文件
创建Service信息：
执行命令：
3.2HandlessService
有时不需要或不想要负载均衡，以及单独的ServiceIP。遇到这种情况，可以通过指定spec.clusterIP的值为None来创建HeadlessService。这类Service并不会分配ClusterIP，kube-proxy不会处理它们，而且平台也不会为它们进行负载均衡和路由。
3.3NodePort
NodePort的原理在于在Node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步到给对应的pod。
创建Service信息：
执行命令：
3.4LoadBalancer
LoadBalancer和NodePort其实是同一种方式。区别在于LoadBalancer比NodePort多了一步，就是可以调用Cloudprovider去创建LB来向节点导流。
3.5ExternalName
这种类型的Service通过返回CNAME和它的值，可以将服务映射到externalName字段的内容(例：hub.hc.