search

4.1.1 Service上手体验

本节，我们将通过实际的例子来体验Service所提供的功能。

hashtag
创建

创建Service对象时，Kubernetes会根据spec.selector来查找拥有指定标签的Pod，查找到Pod就维护一组拓扑关系，如果查找不到也不会自动创建Pod（配置中没有Pod模版），所以本例中用到的Pod对象需要单独创建，在开始之前，假定我们已使用前面介绍Deployment时使用的配置创建了一组label为app: nginx的Pod对象，这些Pod通过端口80对外提供服务。

首先，我们将以下配置保存到名为service.yaml的文件中：

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

然后，创建Service对象：

[root@ecs-d8b6 manifests]# kubectl create -f service.yaml 
service/nginx-service created

hashtag
查看

接着查看刚刚创建的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仅对外暴露一个域名；

hashtag
查看Pod 拓扑

尽管Service会通过selector来查找Pod，但查找到的Pod信息并不直接记录到Service对象中，而是记录到一个Endpoints对象中，进一步说当创建Service对象时，Kubernetes还会创建一个同名的Endpoints对象，来记录后端的Pod拓扑。 关于Endpoints，我们会在后续的章节中详细介绍，此处仅做初步介绍。

查看随Service一并创建的Endpoints对象：

可以看到，该Endpoints对象记录了Service匹配到的所有Pod地址。

hashtag
访问Service

在集群内部，可以直接访问Service的Cluster IP，流量将会被自动转发到后端的某个Pod中：

hashtag
更新

当更新Service的spec.selector时，Kubernetes会自动按照新的spec.selector配置查找Pod，并更新Endpoints对象。

使用kubectl edit service nginx-service命令来修改Service，并指定一个无法匹配到任何Pod的spec.selector，可以看到 Endpoints对象中的Pod拓扑信息也会相应地消失掉，如下所示：

hashtag
删除

当删除Service对象时，随Service对象创建而自动创建的Endpoints对象也会一并删除，后端的Pod不会被删除，它仍然受相应的Pod控制器管理。

上一页4.1.1 Service概述下一页[第六章：配置管理]

最后更新于

这有帮助吗？