Kubetnetes中的Service有4种类型，ClusterIP、NodePort、LB、HandlessService.
一、首先理解为什么需要Service？
1、因为Kubetnetes认为Pod这个资源并不是一个持久资源，说白了就是认为Pod不在挂就是在挂的路上。那么就需要一个资源来配套Deployment或者Statfull set来保证集群内部流量访问有一个持久下且静态的IP地址和端口让服务之间不停摆。
2、且因为副本机制的存在，创建多副本的Pod以及实际需要访问服务的Pod不一定在同一个worker节点上，需要一个LB的机制。
二、Cluster IP
特点：
1、只能集群东西流量访问。
2、配置的Service会生成一个独立的ClusterIP,静态且持久、不删除Service不变。
3、集群内部唯一。
4、会在CoreDNS中自动生成一条DNS记录，默认为：<hostname>.<service-name>.<namespace>.svc.cluster.local 对应ClusterIP.
5、会占用每个集群节点上的端口.
6、会根据Label Seletct 自动生成服务端点 EndPoint.
三、NodePort
特点：运行集群外部访问Pod的服务，跑南北流量。
1、也会生成集群唯一的ClusterIP.
2、也会生成DNS记录。
3、会在节点端口上做映射，将NodePort (30000-32767)范围内某一个映射到Service的端口上。
4、访问集群内部任意节点的NodePort端口就可以通过Service的Endpoint到达Pod.
5、一般做测试使用，不应用到生存环境。
四、 LB
特点：只能由云提供商提供，比如Google Cloud、AWS等。
1、就是NodePort类型的扩展。
2、因为NodePort是Client直接访问集群节点端口，这么做直接暴露了集群节点的IP地址，安全问题太大。
3、所以在NodePort类型前面加了一个前置机就是云提供商的LB。
4、一个LB类型的Service对应一个云提供商的LB。
5、扩展要钱！！
五、HandlessService.
先说为什么存在HandlessService？
1、因为有状态应用（数据库，大型负责系统ELK）等存在选举，主备同步机制。
2、这类有状态应用并不需要通过一层Service的LB来帮助我负载节点，我只需要知道我的Master和Slave在哪里就可以。
3、如果用Cluster IP，例如像Mysql的集群一个节点是主一个是备，正常情况就是主干活，你后端服务发生的请求如果通过Cluster IP LB到备，就很尴尬，需要一个唯一的标识符来告诉后端的POD那个一个主那个是备。
特点：
1、HandlessService就是给Statefull set用的。
2、因为Statefull set的Pod有pod-1,pod-2的唯一标识符。
3、他没有Cluster IP ，他只需要和实际的Pod沟通，但因为Pod的IP地址老变，所以如果是有状态集群的配置，例如Mysql集群指定Master会直接这么写：master-host = mysql-cluster-0.mysql-cluster.default.svc.cluster.local 直接告诉Slave节点主节点在哪里，并且后端程序的配置文件也可以直接写mysql-cluster-0.mysql-cluster.default.svc.cluster.local告诉后端程序Mysql主的地址。
4、当然，如果你的DB是分布式且支持双活的，那就是DB集群内部使用handless Service来镜像选举和同步，后端程序访问DB Service使用Cluster IP 的Service 来负载。
标签：LB,Service,几句话,集群,NodePort,Kubetnetes,Pod,节点 From： https://blog.csdn.net/weixin_46510209/article/details/139622678