Service
Service 通过标签选择 pod，将各 pod 的 ip 保存到它的 endpoints 属性中。Service 的收到的请求会被均摊到这一组 endpoints 上。
DNS
在 k8s 中做服务发现，最常用的方式是通过 DNS 解析。
在我们的 k8s 集群配置了 dns 服务（最常用的是 coredns）的前提下，我们就可以直接通过全限定域名（FQDN）来访问别的服务。
全限定域名的格式如下：
# 格式
..svc.cluster.local # 域名 .svc.cluster.local 是可自定义的
# 举例：访问 default 名字空间下的 nginx 服务
nginx.default.svc.cluster.local 如果两个服务在同一个名字空间内，可以省略掉后面的 .，直接以服务名称为 DNS 访问别的服务
P.S. DNS 服务发现的实现方式：修改每个容器的 /etc/resolv.conf，使容器访问 k8s 自己的 dns 服务器。而该 dns 服务器知道系统中的所有服务，所以它能给出正确的响应。
SRV 记录
Service 除了会使用最常见的 A 记录做 Pod 的负载均衡外，还提供一种 SRV 记录，这种类型的服务被称为 Headless Service.
将 Service 的 spec.ClusterIP 设为 None，得到的就是一个 Headless Service。
普通的 Service 拥有自己的 ClusterIP 地址，service name 会被 DNS 解析到这个虚拟的 ClusterIP（A 记录或 CNAME 记录），然后被 kubectl proxy 转发到具体的 Pod。
而 Headless Service 没有自己的 ClusterIP（这个值被指定成了 None），service name 只提供 SRV 记录的 DNS 解析，返回一个 Pods 的 ip/dns 列表。
有状态集可能会比较需要 SRV 记录。
最佳实践
- 总是使用 Deployment，避免直接使用 ReplicaSet/Pod
- 为 Pod 的 Port 命名（比如命名成 http/https），然后在 Service 的 targetPort 中通过端口名称（http/https）来指定目标端口（容器端口）。
- 更直观，也更灵活
- 应用通过 dns 查找/发现其他服务
- 同一名字空间下的应用，可以直接以服务名称为域名发现别的服务，如通过
http://nginx访问 nginx
- 同一名字空间下的应用，可以直接以服务名称为域名发现别的服务，如通过
- Service 配置会话亲和性为 ClientIP 可能会更好（会话将被同一个 pod 处理，不会发生转移）
- 配置 externalTrafficPolicy: Local 可以防止不必要的网络跳数，但是可能会导致 pod 之间的流量分配不均。