kubernetes进阶(04)kubernetes的service

时间:2023-03-09 09:50:07
kubernetes进阶(04)kubernetes的service

kubernetes进阶(04)kubernetes的service

一、service概念

Service是对一组提供相同功能的Pods的抽象,并为它们提供一个统一的入口。借助Service,应用可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级。
Service通过标签来选取服务后端,一般配合Replication Controller或者Deployment来保证后端容器的正常运行。
这些匹配标签的Pod IP和端口列表组成endpoints,由kubeproxy负责将服务IP负载均衡到这些endpoints上。

Service有四种类型:

  • ClusterIP:默认类型,自动分配一个仅cluster内部可以访问的虚拟IP
  • NodePort:在ClusterIP基础上为Service在每台机器上绑定一个端口,这样就可以通过 <NodeIP>:NodePort 来访问该服务
  • LoadBalancer:在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器,并将请求转发到 <NodeIP>:NodePort
  • ExternalName:将服务通过DNS CNAME记录方式转发到指定的域名(通过 spec.externlName 设定)。需要kube-dns版本在1.7以上。

另外,也可以将已有的服务以Service的形式加入到Kubernetes集群中来,只需要在创建Service的时候不指定Label selector,而是在Service创建好后手动为其添加endpoint。

二、定义service

Service的定义也是通过yaml或json,比如下面定义了一个名为nginx的服务,将服务的80端口转发到default namespace中带有标签 run=nginx 的Pod的80端口

kubernetes进阶(04)kubernetes的service

kubernetes进阶(04)kubernetes的service

二、不指定Selectors的服务

在创建Service的时候,也可以不指定Selectors,用来将service转发到kubernetes集群外部的服务(而不是Pod)。目前支持两种方法

(1)自定义endpoint,即创建同名的service和endpoint,在endpoint中设置外部服务的IP和端口

(2)通过DNS转发,在service定义中指定externalName。

此时DNS服务会给 <service-name>.<namespace>.svc.cluster.local 创建一个CNAME记录,其值为 my.database.example.com 。

并且,该服务不会自动分配Cluster IP,需要通过service的DNS来访问(这种服务也称为Headless Service)。

kubernetes进阶(04)kubernetes的service

三、Ingress Controller

Service虽然解决了服务发现和负载均衡的问题,但它在使用上还是有一些限制,

比如- 只支持4层负载均衡,没有7层功能

对外访问的时候,NodePort类型需要在外部搭建额外的负载均衡,而LoadBalancer要求kubernetes必须跑在支持的cloud provider上面
Ingress就是为了解决这些限制而引入的新资源,主要用来将服务暴露到cluster外面,并且可以自定义服务的访问策略。

比如想要通过负载均衡器实现不同子域名到不同服务的访问:

kubernetes进阶(04)kubernetes的service

可以这样来定义Ingress:

kubernetes进阶(04)kubernetes的service

注意Ingress本身并不会自动创建负载均衡器,cluster中需要运行一个 ingress controller 来根据Ingress的定义来管理负载均衡器。目前社区提供了nginx和gce的参考实现。
Traefik提供了易用的Ingress Controller,使用方法见https://docs.traefik.io/userguide/kubernetes/。
更多Ingress和Ingress Controller的介绍参见ingress。

四、Service Load Balancer

在Ingress出现以前,Service Load Balancer是推荐的解决Service局限性的方式。
Service Load Balancer将haproxy跑在容器中,并监控service和endpoint的变化,通过容器IP对外提供4层和7层负载均衡服务。
社区提供的Service Load Balancer支持四种负载均衡协议:TCP、HTTP、HTTPS和SSL TERMINATION,并支持ACL访问控制。

五、Custom Load Balancer

虽然Kubernetes提供了丰富的负载均衡机制,但在实际使用的时候,还是会碰到一些复杂的场景是它不能支持的,比如接入已有的负载均衡设备
多租户网络情况下,容器网络和主机网络是隔离的,这样 kube-proxy 就不能正常工作
这个时候就可以自定义组件,并代替kube-proxy来做负载均衡。基本的思路是监控kubernetes中service和endpoints的变化,并根据这些变化来配置负载均衡器。

比如weave flux、nginx plus、kube2haproxy等