带你玩转kubernetesk8s（第29篇：k8s深入掌握Service：定义详解）

    Pod的讲解终于告一段落了&＃xff0c;现在我们来一起学习Service。      

    Service是Kubernetes的核心概念&＃xff0c;通过创建Service&＃xff0c;可以为一组具有相同功能的容器应用提供一个统一的入口地址&＃xff0c;并且将请求负载分发到后端的各个容器应用上。本章对Service的使用进行详细说明&＃xff0c;包括Service的负载均衡机制、如何访问Service、Headless Service、DNS服务的机制和实践、Ingress 7层路由机制等。

   Service的yaml定义文件完整内容如下&＃xff1a;

apiVersion: v1 // Required
kind: Service // Required
metadata: // Requiredname: string // Requirednamespace: string // Requiredlabels:- name: stringannotations:- name: string
spec: // Requiredselector: [] // Requiredtype: string // RequiredclusterIP: stringsessionAffinity: stringports:- name: stringprotocol: stringport: inttargetPort: intnodePort: intstatus:loadBalancer:ingress:ip: stringhostname: string

Service 的基本用法

      一般来说&＃xff0c;对外提供服务的应用程序需要通过某种机制来实现&＃xff0c;对于容器应用最简便的方式就是通过TCP/IP机制及监听IP和端口号来实现。例如&＃xff0c;定义一个提供Web服务的RC&＃xff0c;由两个Tomcat容器副组成&＃xff0c;每个容器都通过containerPort设置提供服务的端口号为8080&＃xff1a;

webapp-rc.yaml

apiVersion: v1
kind: ReplicationController
metadata:name: webapp
spec:replicas: 2template:metadata:name: webapplabels:app: webappspec:containers:- name: webappimage: tomcatports:- containerPort: 8080

创建该RC之后获取该Pod的IP地址

kubectl get pod -l app&＃61;webapp -o yaml | grep podIP

可以直接通过这两个Pod的IP地址和端口号访问Tomcat服务&＃xff1a;

       直接通过Pod的IP地址和端口号可以访问到容器应用内的服务&＃xff0c;但是Pod的IP地址是不可靠的&＃xff0c;例如当Pod所在的Node发生故障时&＃xff0c;Pod将被Kubernetes重新调度到另一个Node&＃xff0c;Pod的IP地址将发生变化。更重要的是&＃xff0c;如果容器应用本身是分布式的部署方式&＃xff0c;通过多个实例共同提供服务&＃xff0c;就需要在这些实例的前端设置一个负载均衡器来实现请求的分发。Kubernetes中的Service就是用于解决这些问题的核心组件。

       以前面创建的webapp应用为例&＃xff0c;为了让客户端应用访问到两个Tomcat Pod实例&＃xff0c;需要创建一个Service来提供服务。Kubernetes提供了一种快速的方法&＃xff0c;即通过kubectl expose命令来创建Service&＃xff1a;

kubectl expose rc webapp

    查看新创建的Service&＃xff0c;可以看到系统为它分配了一个虚拟的IP地址&＃xff08;ClusterIP&＃xff09;&＃xff0c;Service所需的端口号则从Pod中的containerPort复制而来&＃xff1a;

接下来就可以通过Service的IP地址和Service的端口号访问该Service了&＃xff1a;

这里&＃xff0c;对Service地址10.111.79.254:8080的访问被自动负载分发到了后端两个Pod之一。

      除了使用kubectl expose命令创建Service&＃xff0c;我们也可以通过配置文件定义Service&＃xff0c;再通过kubectl create命令进行创建。例如对于前面的webapp应用&＃xff0c;我们可以设置一个Service&＃xff0c;代码如下&＃xff1a;

apiVersion: v1
kind: Service
metadata:name: webapp1
spec:ports:- port: 8081targetPort: 8080selector:app: webapp

      Service定义中的关键字段是ports和selector。本例中ports定义部分指定了Service所需的虚拟端口号为8081&＃xff0c;由于与Pod容器端口号8080不一样&＃xff0c;所以需要再通过targetPort来指定后端Pod的端口号。selector定义部分设置的是后端Pod所拥有的label&＃xff1a;app&＃61;webapp。

目前Kubernetes提供了两种负载分发策略&＃xff1a;RoundRobin和SessionAffinity&＃xff0c;具体说明如下:

◎　RoundRobin&＃xff1a;轮询模式&＃xff0c;即轮询将请求转发到后端的各个Pod上。
◎　SessionAffinity&＃xff1a;基于客户端IP地址进行会话保持的模式&＃xff0c;即第1次将某个客户端发起的请求转发到后端的某个Pod上&＃xff0c;之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。

       在默认情况下&＃xff0c;Kubernetes采用RoundRobin模式对客户端请求进行负载分发&＃xff0c;但我们也可以通过设置service.spec.sessionAffinity&＃61;ClientIP来启用SessionAffinity策略。这样&＃xff0c;同一个客户端IP发来的请求就会被转发到后端固定的某个Pod上了。

       通过Service的定义&＃xff0c;Kubernetes实现了一种分布式应用统一入口的定义和负载均衡机制。Service还可以进行其他类型的设置&＃xff0c;例如设置多个端口号、直接设置为集群外部服务&＃xff0c;或实现为Headless Service&＃xff08;无头服务&＃xff09;模式。

多端口Service

      有时一个容器应用也可能提供多个端口的服务&＃xff0c;那么在Service的定义中也可以相应地设置为将多个端口对应到多个应用服务。在下面的例子中&＃xff0c;Service设置了两个端口号&＃xff0c;并且为每个端口号都进行了命名&＃xff1a;

apiVersion: v1
kind: Service
metadata:name: webapp2
spec:ports:- port: 8080targetPort: 8080name: web- port: 8005targetPort: 8005name: managementselector:app: webapp

另一个例子是两个端口号使用了不同的4层协议—TCP和UDP&＃xff1a;

apiVersion: v1
kind: Service
metadata:name: webapp3
spec:ports:- port: 8080protocol: UDPname: tdp- port: 8080protocol: TCPname: tcpselector:app: webapp

外部服务Service

     在某些环境中&＃xff0c;应用系统需要将一个外部数据库作为后端服务进行连接&＃xff0c;或将另一个集群或Namespace中的服务作为服务的后端&＃xff0c;这时可以通过创建一个无Label Selector的Service来实现&＃xff1a;

kind: Service
apiVersion: v1
metadata:name: my-service
spec:ports:- protocol: TCPport: 80targetPort: 80

通过该定义创建的是一个不带标签选择器的Service&＃xff0c;即无法选择后端的Pod&＃xff0c;系统不会自动创建Endpoint&＃xff0c;因此需要手动创建一个和该Service同名的Endpoint&＃xff0c;用于指向实际的后端访问地址。创建Endpoint的配置文件内容如下&＃xff1a;

kind: Endpoints
apiVersion: v1
metadata:name: my-service
subsets:
- addresses:- ip: 1.2.3.4ports:- port: 8080


  访问没有标签选择器的Service和带有标签选择器的Service一样&＃xff0c;请求将会被路由到由用户手动定义的后端Endpoint上。

    小结&＃xff1a;

            本节内容到此结束&＃xff0c;是不是觉得很简单呢&＃xff1f;

            觉得简单&＃xff0c;说明我们已经入k8s的门了&＃xff0c;继续加油&＃xff01;

            多多点关注哦~