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资源上。命令取样次数越大，其调度效果也越接近于短发的目标效果。
标签：Kubernetes,Service,--,svc,myapp,Pod,80,资源 From： https://www.cnblogs.com/zhangxin9/p/16747979.html