service 对象
selector就是如何去汇聚一组pod。
其次就是定义负载均衡的规则了，service是四层的，工作在网络传输层，所谓的protocol就是TCP或者UDP，以及服务发布在哪个端口上面，target是真正的pod服务运行在哪里。
这里其实就是端口映射了。
EndPoint对象
service和pod产生关联关系要通过endpoint对象产生的。
这个endpoint对象是谁产生的呢？是由controllermanager里面有个endpoint controller，这个endpoint controller会去watch pod和service这两类对象。
当它发现一个service被创建了，如果service里面定义了selector，那么就意味着这个service是想去关联一组pod，如果没有selector，那么controller manager是不会干活的。
如果有selector，那么endpoint controller会去建立一个和这个service同名的endpoint对象，然后按照service的selector去选择target port，然后它会去看pod的就绪状态，如果它是就绪的，那么在subset里面有个address和notreadyaddress，如果一个pod不就绪，它就在notreadyaddress里面，如果这个pod就绪了，它就在address里面。
endpoint对象本身就是关联了service和pod，endpoint里面维护了一堆的address，这些address就和pod的address，把这些都维护起来了，同时通过address和notreadyaddress将pod进行分类了。
pod的就绪状态体现在哪？处于notreadyaddress的pod是不接受流量的。
在新的kubernetes版本里面，有个新的对象在替换endpoint对象，这个是endpointslice，为什么有这个对象呢，它是为了做性能优化，比如一个service选择了5000或者10000个pod，针对这种应用，那么一个endpoint对象会有多大，它会维持很多信息，如果一个集群里面有这么多类型的service，那么这个集群里面会有非常非常多的endpoint大对象。
endpoint发生变化之后，比如服务由不能访问变成了可以访问，其实在每个节点上面的kube-proxy组件会去监听service和endpoint对象的变化，如果endpoint变化，那么就意味着集群里面所有节点上的kube-proxy都要监听到新的变化，并且去刷新这个配置，这就会产生一个问题，如果集群的规模比较大，然后你的endpoint对象又很大，因为这些都大，那么很有可能一些pod一下好，一下不好，如果每一次都有这样的变化，它都要去推送，就会将endpoint完整对象推送到所有节点 ，无论对控制面 apiserver还是kube-proxy，还是对网络压力都非常的大。
相当于你要做一个从apiserver往5000个节点上面推送这种大对象，而且是频繁的推送，这样的话整个集群的压力就会大。
所以endpointslice是干嘛的呢？针对大对象，我给你做一个一个的切片，比如service里面select了5000个pod，那么endpointslice可以设定将500个IP地址做个切片，或者1000个IP地址做成一个切片，那么切片就相当于之前几分之一的大小。
其次当pod发生变化的时候只影响到你一个endpointslice，而不是影响全局的。
这样的话假设说一个endpoint被切分为5个endpointslice，如果有一个IP变化，那么我要去传输的这个变化的对象就由原来一个很大的变为20%的传输，这样的话就有效的提升了性能。
不定义selector的service
如果不去定义selector service会干嘛呢？那么endpoint controller不会去为你的service去定义任何endpoint对象，但是你依然可以利用这一点完成负载均衡的配置。
外面有三台虚拟机，这三台虚拟机不在kubernets里面纳管，它有三个IP地址，但是我希望从集群内部去访问这三台虚拟机，那么我就建立一个service，这个service就不加selector，所以没有endpoint对象出现，然后手工去建立endpoint对象，这个endpoint对象里面的address就填入那三台机器的IP地址。
现在service和endpoint都有了，只不过endpoint是我手工建立的，那么kube-proxy一样会去工作，那么访问集群内部的服务就可以转到那三台虚拟机上面去了。
所以不带selector的service一般是用来访问集群外部的资源的。
Service Pod Endpoint对应关系
service和pod之间它们是多对多的关系，这个多对多的关系是由endpoint来关联的，所以endpoint名称和service名称是一样的，subset里面的address和notreadyaddress会关联到不同的pod，最后port的部分是从service拿过来的。
当我们去建立service的时候默认clusterip类型，apiserver里面有个参数叫做cluster service ip range，就是在启动整个集群的时候要为cluster ip配置可用的范围，真正去建立这个service的时候，apiserver会从可用IP区间里面帮你分配一个可用的clusterip。
[root@master manifests]# vi kube-apiserver.yaml
- --service-cluster-ip-range=10.233.0.0/18service类型
