025.掌握Service-SVC基础使用

一 Service简介

1.1 Service观点


Service是Kubernetes的焦点观点,通过建立Service,可以为一组具有相同功效的容器应用提供一个统一的入口地址,而且将请求负载分发到后端的各个容器应用上。

1.2 Service界说详解

  1 apiVersion: v1		#必须,api版本
  2 kind: Service		#必须,类型为Service
  3 metadata:			#必须,元数据
  4   name: string		#必须,Service名称
  5   namespace: string		#必须,命名空间,默以为default
  6   labels:			#自界说标签属性列表
  7     - name: string
  8   annotations:		#自界说注解属性列表
  9     - name: string
 10 spec:			#必须,详细描述
 11   selector: []		#必须,Label Selector设置
 12   type: ClusterIP		#必须,Serice类型,详见如下
 13   sessionAffinity: string	#虚拟服务IP地址,当选择type=ClusterIP时,若不指定,则系统举行自动分配;当type=LoadBalancer时,需要指定
 14   ports:			#Service需要露出的端口列表
 15   - name: string		#端口名称
 16     protocol:		#端口协议,支持TCP和UDP,默以为TCP
 17     port: int		#服务监听的端口号
 18     targetPort: 8080	#需要转发到后端Pod的端口号
 19     nodePort: int		#当spec.type=NodePort时,指定映射到物理机的端口号
 20 status:			#当spec.type=LoadBalancer时,设置外部负载平衡的地址,用于公有云
 21   loadBalancer:		#外部负载平衡器
 22     ingress:		#外部负载平衡器
 23       ip: string		#外部负载平衡器的IP地址
 24       hostname: string	#外部负载平衡器的主机名


spec.type:Service的类型,指定Service的接见方式,默以为ClusterIP。

  • ClusterIP:虚拟的服务IP地址,该地址用于Kubernetes集群内部的Pod接见,在Node上kube-proxy通过设置的iptables规则举行转发;
  • NodePort:使用宿主机的端口,使能够接见各Node的外部客户端通过Node的IP地址和端口号就能接见服务;
  • LoadBalancer:使用外接负载平衡器完成到服务的负载分发,需要在spec.status.loadBalancer字段指定外部负载平衡器的IP地址,并同时界说nodePort和clusterIP,用于公有云。

二 Service基本使用

2.1 Service的基本用法


一般来说,对外提供服务的应用程序需要通过某种机制来实现,对于容器应用最简捷的方式就是通过TCP/IP机制及监听IP和端口号来实现。

示例:界说一个提供Web服务的RC,由两个Tomcat容器副本组成,每个容器都通过containerPort设置提供服务的端口号为8080。

[root@k8smaster01 study]# cat webapp-rc.yaml

  1 apiVersion: v1
  2 kind: ReplicationController
  3 metadata:
  4   name: webapp
  5 spec:
  6   replicas: 2
  7   template:
  8     metadata:
  9       name: webapp
 10       labels:
 11         app: webapp
 12     spec:
 13       containers:
 14       - name: webapp
 15         image: tomcat
 16         ports:
 17         - containerPort: 8080



[root@k8smaster01 study]# kubectl create -f webapp-rc.yaml

[root@k8smaster01 study]# kubectl get pods -l app=webapp -o yaml | grep podIP

podIP: 172.24.9.88

podIP: 172.24.9.199

[root@k8smaster01 study]# curl 172.24.9.88:8080

25.掌握Service-SVC基础使用"

SpringBoot图文教程14—SpringBoot集成EasyExcel「上」


直接通过Pod的IP地址和端口号可以接见到容器应用内的服务,然则Pod的IP地址是不可靠的,例如当Pod所在的Node发生故障时,Pod将被Kubernetes重新调剂到另一个Node,Pod的IP地址将发生变化。

若是容器应用自己是分布式的部署方式,通过多个实例配合提供服务,就需要在这些实例的前端设置一个负载平衡器来实现请求的分发。Kubernetes中的Service就是用于解决这些问题的焦点组件。

Service示例:以如上webapp应用为例,为了让客户端应用接见到两个Tomcat Pod实例,可以建立一个Service来提供服务。Kubernetes提供了一种快速的方式,即通过kubectl expose下令来建立Service。
[root@k8smaster01 study]# kubectl expose rc webapp

[root@k8smaster01 study]# kubectl get svc | grep -E ‘NAME|webapp’

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

webapp ClusterIP 10.10.10.51 <none> 8080/TCP 45s

[root@k8smaster01 study]# curl 10.10.10.51:8080 #测试接见


提醒:如上Service地址10.10.10.51:8080的接见被自动负载分发到后端两个Pod。

Service示例2:通过Service设置文件露出服务。

[root@k8smaster01 study]# vi webappsvc.yaml

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   name: webappservice
  5 spec:
  6   ports:
  7   - port: 8081
  8     targetPort: 8080
  9   selector:
 10     app: webapp


[root@k8smaster01 study]# kubectl create -f webappsvc.yaml

[root@k8smaster01 study]# kubectl get svc | grep -E ‘NAME|webappser’

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

webappservice ClusterIP 10.10.10.83 <none> 8081/TCP 22s

提醒:如上Service界说中的要害字段是ports和selector。本例中ports界说部门指定了Service所需的虚拟端口号为8081,由于与Pod容器端口号8080不一样,以是需要再通过targetPort来指定后端Pod的端口号。selector界说部门设置的是后端Pod所拥有的label:app=webapp。

[root@k8smaster01 study]# curl 10.10.10.83:8081 #接见测试

  • Service负载分发计谋:RoundRobin和SessionAffinity


    • RoundRobin:轮询模式,即轮询将请求转发到后端的各个Pod上。
    • SessionAffinity:基于客户端IP地址举行会话保持的模式,即第1次将某个客户端提议的请求转发到后端的某个Pod上,之后从相同的客户端提议的请求都将被转发到后端相同的Pod上。


在默认情况下,Kubernetes接纳RoundRobin模式对客户端请求举行负载分发,同时可以通过设置service.spec.sessionAffinity=ClientIP来启用SessionAffinity计谋。这样,同一个客户端IP发来的请求就会被转发到后端牢固的某个Pod上了。

通过Service的界说,Kubernetes实现了一种分布式应用统一入口的界说和负载平衡机制。Service还可以举行其他类型的设置,例如设置多个端口号、直接设置为集群外部服务,或实现为Headless Service(无头服务)模式。

2.2 多端口Service


有时一个容器应用也可能提供多个端口的服务,那么在Service的界说中也可以响应地设置为将多个端口对应到多个应用服务。

示例1:如下,Service设置了两个端口号,而且为每个端口号都举行了命名。

[root@k8smaster01 study]# vi twoportservice.yaml

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   name: webapp
  5 spec:
  6   ports:
  7   - port: 8080
  8     targetPort: 8080
  9     name: web
 10   - port: 8005
 11     targetPort: 8005
 12     name: management
 13   selector:
 14     app: webapp


[root@k8smaster01 study]# vi kubednsservice.yaml

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   name: kube-dns
  5   namespace: kube-system
  6   labels:
  7     k8s-app: kube-dns
  8     kubernetes.io/cluster-service: "true"
  9     kubernetes.io/name: "KubeDNS"
 10 spec:
 11   selector:
 12     k8s-app: kube-dns
 13   clusterIP: 169.169.0.100
 14   ports:
 15   - name: dns
 16     port: 53
 17     protocol: UDP
 18 
 19   - name: dns-tcp
 20     port: 53
 21     protocol: TCP

2.3 外部服务Service


在某些环境中,应用系统需要将一个外部数据库、另一个集群或Namespace中的服务作为服务的后端,则可通过建立一个无Label Selector的Service来实现。

[root@k8smaster01 study]# vi noselectorservice.yaml

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   name: my-service
  5 spec:
  6   ports:
  7   - protocol: TCP
  8     port: 80
  9     targetPort: 80


[root@k8smaster01 study]# kubectl create -f noselectorservice.yaml

如上界说建立的是一个不带标签选择器的Service,即无法选择后端的Pod,系统不会自动建立Endpoint,因此需要手动建立一个和该Service对应的Endpoint,用于指向现实的后端接见地址。

如下所示的Endpoint的界说文件:

[root@k8smaster01 study]# vi noselectorendpoint.yaml

  1 apiVersion: v1
  2 kind: Endpoints
  3 metadata:
  4   name: my-service
  5 subsets:
  6 - addresses:
  7   - IP: 47.96.145.131
  8   ports:
  9   - port: 80


[root@k8smaster01 study]# kubectl create -f noselectorendpoint.yaml

[root@k8smaster01 study]# kubectl get svc | grep -E ‘NAME|my-service’

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

my-service ClusterIP 10.10.10.211 <none> 80/TCP 3s

[root@k8smaster01 study]# curl 10.10.10.211


25.掌握Service-SVC基础使用"

提醒:如上所示,接见没有标签选择器的Service和带有标签选择器的Service一样,请求将会被路由到由用户手动界说的后端Endpoint上。

三 Headless Service

3.1 无头服务简介


在某些应用场景中,若需要人为指定负载平衡器,不使用Service提供的默认负载平衡的功效,或者应用程序希望知道属于同组服务的其他实例。Kubernetes提供了Headless Service来实现这种功效,即不为Service设置ClusterIP(入口IP地址),仅通过Label Selector将后端的Pod列表返回给挪用的客户端。

此场景中,Service就不再具有一个特定的ClusterIP地址,对其举行接见将获得包罗Label“app=nginx”的所有Pod列表,然后客户端程序自行决定若何处置这个Pod列表。

例如,StatefulSet就是使用Headless Service为客户端返回多个服务地址的。

对于“去中央化”类的应用集群,Headless Service异常适合。

3.2 Nginx场景实验


通过对Headless Service搭建Nginx集群,从而自动实现应用集群的建立。

[root@k8smaster01 study]# vi nginx-service.yaml #建立Service

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   labels:
  5     name: nginx-svc
  6   name: nginx-svc
  7 spec:
  8   ports:
  9   - protocol: TCP
 10     port: 80
 11     targetPort: 80
 12   selector:
 13     name: nginx-demo			#界说selector
 14   clusterIP: None


[root@k8smaster01 study]# kubectl create -f nginx-service.yaml

[root@k8smaster01 study]# vi nginx-deployment.yaml

  1 apiVersion: apps/v1
  2 kind: Deployment
  3 metadata:
  4   labels:
  5     name: nginx-demo
  6   name: nginx-demo
  7 spec:
  8   replicas: 2
  9   selector:
 10     matchLabels:
 11       name: nginx-demo
 12   template:
 13     metadata:
 14       labels:
 15         name: nginx-demo
 16     spec:
 17       containers:
 18       - name: nginx
 19         image: nginx:1.7.9
 20         ports:
 21         - containerPort: 80
 22           name: web


[root@k8smaster01 study]# kubectl create -f nginx-deployment.yaml

[root@k8smaster01 study]# kubectl create -f nginx-service.yaml

[root@k8smaster01 study]# kubectl get svc -o wide

[root@k8smaster01 study]# kubectl get pods -o wide

[root@k8smaster01 study]# nslookup nginx-svc.default.svc.cluster.local 10.10.190.170


25.掌握Service-SVC基础使用"

提醒:由上可知,通过剖析SVC的地址,直接剖析出来的为Pod的IP。

原创文章,作者:28x29新闻网,如若转载,请注明出处:https://www.28x29.com/archives/500.html