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记录,默认为:
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 来负载。