4.1.1 Service上手体验
本节,我们将通过实际的例子来体验Service
所提供的功能。
创建
创建Service
对象时,Kubernetes
会根据spec.selector
来查找拥有指定标签的Pod
,查找到Pod
就维护一组拓扑关系,如果查找不到也不会自动创建Pod
(配置中没有Pod
模版),所以本例中用到的Pod
对象需要单独创建,在开始之前,假定我们已使用前面介绍Deployment
时使用的配置创建了一组label为app: nginx
的Pod
对象,这些Pod
通过端口80
对外提供服务。
首先,我们将以下配置保存到名为service.yaml
的文件中:
然后,创建Service
对象:
查看
接着查看刚刚创建的Service
对象:
命令行输出中各字段含义如下:
NAME:
Service
对象名称,对应配置中的metadata.name
;TYPE:
Service
类型,默认为ClusterIP
类型,更多的类型将在后面的章节中介绍;CLUSTER-IP:自动分配的
Cluster IP
;EXTERNAL-IP:外部IP地址,用于接收集群外部流量的地址,在后面介绍
Service
类型时详细介绍;PORT(S):
Service
对外暴露的端口列表,本例中只对外暴露一个端口,对应配置中的spec.ports
;AGE:创建至今经历的时间;
SELECTOR:标签选择器,
Service
根据此选择器查看后端Pod
,对应配置中的spec.selector
。
当前Kubernetes
支持多种Service
类型,来应对不同的使用场景:
ClusterIP:Service通过一个只能在集群内部访问的 Cluster IP来暴露服务;
NodePort:Service通过Node上的某个端口来暴露服务;
LoadBalancer:Service通过具体云厂商提供的负载均衡器来暴露服务;
ExternalName:Service仅对外暴露一个域名;
查看Pod 拓扑
尽管Service
会通过selector
来查找Pod
,但查找到的Pod
信息并不直接记录到Service
对象中,而是记录到一个Endpoints
对象中,进一步说当创建Service
对象时,Kubernetes
还会创建一个同名的Endpoints
对象,来记录后端的Pod
拓扑。 关于Endpoints
,我们会在后续的章节中详细介绍,此处仅做初步介绍。
查看随Service
一并创建的Endpoints
对象:
可以看到,该Endpoints
对象记录了Service
匹配到的所有Pod
地址。
访问Service
在集群内部,可以直接访问Service
的Cluster IP
,流量将会被自动转发到后端的某个Pod
中:
更新
当更新Service
的spec.selector
时,Kubernetes
会自动按照新的spec.selector
配置查找Pod
,并更新Endpoints
对象。
使用kubectl edit service nginx-service
命令来修改Service
,并指定一个无法匹配到任何Pod
的spec.selector
,可以看到 Endpoints
对象中的Pod
拓扑信息也会相应地消失掉,如下所示:
删除
当删除Service
对象时,随Service
对象创建而自动创建的Endpoints
对象也会一并删除,后端的Pod
不会被删除,它仍然受相应的Pod
控制器管理。
最后更新于