Kubernetes--Service资源的基础应用

Service资源的基础应用

首先Service资源本身并提供任何服务，其真正处理并响应客户端请求的是后端的Pod资源，这些Pod资源通常由各类控制器对象（ReplicaSet、Deployment、DaemonSet、Job、CronJob）所创建和管理，因此Service资源通常要与控制器资源（最为常用的控制器之一是Deployment）协同使用以完成应用的创建和对外的发布~

创建Service资源

• 创建Service对象的常用方法有两种：
• 一是直接使用“kubectl expose”（基于rc、service、deployment或pod创建Service资源）命令；
• 另一个是使用资源配置文件，它与使用资源清单文件配置其他资源的方法类似~

 

定义Service资源对象时，spec的两个较为常用的的内嵌字段分别为selector和ports，分别用于定义使用的标签选择器和要暴露的端口。 下面的配置清单是一个Service的资源示例：

kind: Service
apiVersion: v1
metadata:
  name: myapp-svc
spec:
  selector:       #定义使用的标签选择器
    app: myapp
  ports:
  - protocol: TCP
    port: 80      #定义要暴露的端口
    targetPort: 80

Service资源myapp-svc通过标签选择器关联至标签为“app=myapp”的各Pod对象，它会自动创建名为myapp-svc的Endpoints资源对象，并自动配置一个ClusterIP，暴露的端口由port字段进行指定，后端各Pod对象的端口则由targetPort给出，也可以使用同port字段的默认值。

• myapp-svc创建完成后，使用下面的命令即能获取相关的信息输出以了解资源的状态

]$ kubectl get svc myapp-svc
NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
myapp-svc   ClusterIP   10.108.17.20   <none>        80/TCP    7s

命令结果显示，myapp-svc的类型为默认的ClusterIP，其使用的地址自动配置为10.108.17.20。此类型的Service对象仅能通过此IP地址接受来自于集群内的客户端Pod中的请求。 若集群上存在标签为“app=myapp”的Pod资源，则它们将会被创建和关联，作为此Service对象的后端Endpoint对象，并负责接受相应的请求流量。

• 类似下面的命令可用于获取Endpoint资源的端点列表，其相关的端点是由我之前创建Deployment控制器创建的Pod对象的套接字信息组成的：

]$ kubectl get endpoints myapp-svc 
NAME        ENDPOINTS                                      AGE
myapp-svc   10.244.1.14:80,10.244.1.15:80,10.244.2.26:80   23s

提示： 也可以不为Service资源指定 .spec.selector属性值，其关联的Pod资源可由用户手动创建Endpoints资源进行定义哦~

Service对象创建完成后即可作为服务被各客户端访问，但要真正相应这些请求，还是要依赖于各后端的资源对象。

向Service对象请求服务

Service资源的默认类型为ClusterIP，它仅能接受来自于集群中的Pod对象中的客户端程序的访问请求。

• 下面创建一个专用的Pod对象，利用其交互式接口完成访问测试。为了简单起见，这里选择直接创建一个临时使用的Pod对象作为交互式使用的客户端进行，它使用CirrOS镜像，默认的命令提示符为“/#”：

]$ kubectl run cirros-$RANDOM --rm -it --image=cirros -- sh
/ # 

【CirrOS是设计用来进行云计算环境测试的Liunx微型发行版，它拥有HTTP客户端工具curl等】

而后，在容器的交互式接口中使用curl命令对myapp-svc服务的ClusterIP（10.108.17.20）和Port（80/tcp）发起访问请求测试：

/ # curl http://10.108.17.20:80/
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
/ # 

myapp容器中的“/hostname.html”页面能够输出当前容器的主机名，可反复向myapp-svc的此URL路径发起多次请求已验证其调度的效果：

/ # for loop in 1 2 3 4; do curl http://10.108.17.20:80/hostname.html; done
myapp-deploy-7ffb5fd5ff-zjnpk
myapp-deploy-7ffb5fd5ff-2s927
myapp-deploy-7ffb5fd5ff-5fvcb
myapp-deploy-7ffb5fd5ff-zjnpk
/ # 

当前Kubernetes集群的Service代理模式为iptables，它默认使用随机掉调度算法，因此 Service会将客户端请求随机调度至与其关联的某个后端Pod资源上。命令取样次数越大，其调度效果也越接近于短发的目标效果。