headless service:
使用场景:
(1)statefulset中进行pod的网络功能域名的,如创建的pod的名字为web-0,web-1那网络一致性其对应的dns存储就是以web-0,web-1打头
(2)进行跨namespace的访问服务(service),只有headless中的pod设置spec.hostname字段的pod才会在dns中单独记录pod的dns值
(3)不希望proxy帮助我们进行负载均衡(kube-proxy不处理这些service):即没有service对应的service dns记录,但是有返回其对应pod。但是service有endpoint记录。
所以headless service的作用1是为创建pod的dns记录(好像只有这种方式能创建pod的dns记录,spec.hostname必须设置),2是不想应用proxy的负载均衡。
没有选择器的Service:
使用场景:
(1) 使用k8s集群外的服务,如数据库集群
(2)service指向另一个namespace
此时你创建的service就没有指定service,此时不会创建service的对应endpoint,此时就需要你手动的创建endpoint,指向你希望的服务,可以在集群外,或者另一个namespace中。
所以没有selector的service就是可以使用自定义服务的service
普通service:
使用场景:
提供服务功能
创建service时targetport可以用port的name,这样就不关系实际端口号,如果改变端口号也不会影响功能,使service更灵活。