在k8s中，service 是一个固定接入层，客户端可以通过访问 service 的 ip 和端口访问到 service 关联的后端pod，这个 service 工作依赖于在 kubernetes 集群之上部署的一个附件，就是kubernetes 的 dns 服务（不同 kubernetes 版本的 dns 默认使用的也是不一样的，1.11 之前的版本使用的是 kubeDNs，较新的版本使用的是 coredns），service 的名称解析是依赖于 dns 附件的，因此在部署完 k8s 之后需要再部署 dns附件，kubernetes 要想给客户端提供网络功能，需要依赖第三方的网络插件（flannel，calico 等）。每个 K8s 节点上都有一个组件叫做 kube-proxy，kube-proxy 这个组件将始终监视着 apiserver 中有关service 资源的变动信息，需要跟 master 之上的 apiserver 交互，随时连接到 apiserver 上获取任何一个与 service 资源相关的资源变动状态，这种是通过 kubernetes 中固有的一种请求方法 watch（监视）来实现的，一旦有 service 资源的内容发生变动（如创建，删除），kube-proxy 都会将它转化成当前节点之上的能够实现 service 资源调度，把我们请求调度到后端特定的 pod 资源之上的规则，这个规则可能是 iptables，也可能是 ipvs，取决于 service 的实现方式。
1.2 service的作用 ① 服务发现。 service通过label selector 选择提供服务的pod。此label selector其实就是转换规则，会通过它生成service的endpoints。endpoint是k8s中的资源对象，存储在etcd中，可以由service定义中的selector生成，它记录了一条serviceIP对应的所有podIP。当请求到达serviceIP时，会根据分发策略从所有的podIP中选择一个podIP，作为提供服务的pod。当pod被删除或者重建时，podIP会发生变化，kube-proxy会基于监听机制发现对应的变化并实时更新endpoints中的serviceIP对应的podIP。因此，service具有服务发现的功能，当pod更新时，service会根据label
selector找到对应的pod，并将podIP记录更新到service的endpoint中。这样，无论pod怎样更新变化，service都能找到pod并使用其提供的服务。② 负载均衡。 service往往通过label- selector代表着一组pod。当请求到达service时，该请求会根据负载均衡策略将请求定向到对应的pod上。在此过程，除非特别设置，否则请求会被分配到各个pod上，避免集中将请求发送给某个pod上导致服务被打挂的现象。 2、五种负载均衡类型及区别
Service 对象的一般示例：
apiVersion: v1 kind: Service metadata: name: my-web-service spec: type: LoadBalancer ports: - port: 80 targetPort: 8080 # 这是你的应用程序容器监听的端口 selector: app: my-web-app # 这里需要指定与你的应用程序 Pod 匹配的标签其中type的四中类型和使用区别：
1、【Kubernetes Service NodePort 外网访问、LoadBalancer
来自 https://blog.csdn.net/qq_34556414/article/details/108976004 】
2、CoreDNS: DNS and Service Discovery
来自 https://coredns.io/
3、Kubernetes的ExternalName详解
来自 https://developer.aliyun.com/article/1320417
4、Kubernetes LoadBalancer使用场景例子及配置步骤
来自 https://developer.aliyun.com/article/1309651?spm=a2c6h.14164896.0.0.191647c5P9XDDO&scm=20140722.S_community@@文章@@1309651._.ID_1309651-RL_loadbalancer-LOC_search~UND~community~UND~item-OR_ser-V_3-P0_3
5、K8s之service
来自 https://zhuanlan.zhihu.com/p/568436695