没有 selector 的 Service

Servcie 抽象了该如何访问 Kubernetes Pod，但也能够抽象其它类型的 backend，例如：

• 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
• 希望服务指向另一个 Namespace 中或其它集群中的服务。
• 正在将工作负载转移到 Kubernetes 集群，和运行在 Kubernetes 集群之外的 backend。

在任何这些场景中，都能够定义没有 selector 的 Service ：

由于这个 Service 没有 selector，就不会创建相关的 Endpoints 对象。可以手动将 Service 映射到指定的 Endpoints：

apiVersion: v1
kind: Service
metadata:
  name: redis
  labels:
    app: redis
spec:
  ports:
    - port: 6379


apiVersion: v1
kind: Endpoints
metadata:
  name: redis
subsets:
  - addresses:
    - ip: 10.0.0.1   # redis ip，不能是 loopback (127.0.0.0/8) 或 link-local (169.254.0.0/16)、或者 link-local 多播（224.0.0.0/24）。
    ports:
      - port: 6379

访问没有 selector 的 Service，与有 selector 的 Service 的原理相同。请求将被路由到用户定义的 Endpoint（该示例中为 10.0.0.1:6379）。
这样就可以通过 service 访问那些不是部署在 K8S 上的服务

mysql的例子

kind: Service
apiVersion: v1
metadata:
  name: mysql                #保持与下面endpoint的metadata.name一致
  labels:
    name: mysql            #保持与下面endpoint的metadata.labels.name一致
spec:
  clusterIP: None
  ports:
    - port: 3306
      name: mysql            #这名字理论上随意
      targetPort: 3306
---
kind: Endpoints
apiVersion: v1
metadata:
  name: mysql
  labels:
    name: mysql
subsets:
  - addresses:
      - ip: 10.0.0.1        #这里是数据库的ip地址
    ports:
      - port: 3306              #数据库端口

ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。 相反地，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

kind: Service
apiVersion: v1
metadata:
  name: my-service
  namespace: test
spec:
  type: ExternalName
  externalName: my.database.example.com

当查询主机 my-service.test.svc.CLUSTER时，集群的 DNS 服务将返回一个值为 my.database.example.com 的 CNAME 记录。 访问这个服务的工作方式与其它的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。 如果后续决定要将数据库迁移到 Kubernetes 集群中，可以启动对应的 Pod，增加合适的 Selector 或 Endpoint，修改 Service 的 type。