Service

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

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

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

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

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

kind: Endpoints
apiVersion: v1
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 1.2.3.4
    ports:
      - port: 9376

注意：Endpoint IP 地址不能是 loopback（ 127.0.0.0/8 ）、 link-local（ 169.254.0.0/16 ）、或者 link-local 多播（ 224.0.0.0/24 ）

访问没有 selector 的 Service，与有 selector 的 Service 的原理相同

请求将被路由到用户定义的 Endpoint（该示例中为 1.2.3.4:9376）

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

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

当查询主机 my-service.prod.svc.CLUSTER时，集群的 DNS 服务将返回一个值为 my.database.example.com 的 CNAME 记录 。访问这个服务的工作方式与其它的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发

如果后续决定要将数据库迁移到 Kubernetes 集群中，可以启动对应的 Pod，增加合适的 Selector 或 Endpoint，修改 Service 的 type

1. kube-proxy 会 监视 Kubernetes master 对 Service 对象 和 Endpoints 对象 的 添加 和 移除
   • 对每个 Service，它会在本地 Node 上 打开 一个 端口 （ 随机选择）
2. 任何连接到 代理端口 的请求，都会被代理到 Service 的 backend Pods 中的某个上面（如 Endpoints 所报告的一样）
   • 使用哪个 backend Pod，是基于 Service 的 SessionAffinity 来确定的
3. 它安装 iptables 规则 ，捕获到达该 Service 的 clusterIP （虚拟 IP）和 Port 的 请求 ，并 重定向 到 代理端口

4. 代理端口 再 代理请求 到 backend Pod ，网络返回的结果是，任何到达 Service 的 IP:Port 的请求，都会被代理到一个合适的 backend，不需要客户端知道关于 Kubernetes、Service、或 Pod 的任何信息

   

默认的策略是，通过 round-robin 算法来选择 backend Pod

实现基于客户端 IP 的会话亲和性，可以通过设置 service.spec.sessionAffinity 的值为 "ClientIP" （默认值为 "None"）

1. kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除
2. 对每个 Service ，它会安装 iptables 规则 ，从而 捕获 到达该 Service 的 clusterIP （虚拟 IP）和 端口 的请求
3. 将请求 重定向 到 Service 的一组 backend 中的 某个 上面
4. 对于每个 Endpoints 对象，它也会安装 iptables 规则 ，这个规则会 选择 一个 backend Pod

和 userspace 代理类似，网络返回的结果是，任何到达 Service 的 IP:Port 的请求，都会被代理到一个合适的 backend，不需要客户端知道关于 Kubernetes、Service、或 Pod 的任何信息。

这应该比 userspace 代理更快、更可靠。然而，不像 userspace 代理，如果初始选择的 Pod 没有响应，iptables 代理不能自动地重试另一个 Pod，所以它需要依赖 readiness probes

默认的策略是， 随机 选择一个 backend

实现基于客户端 IP 的会话亲和性，可以将 service.spec.sessionAffinity 的值设置为 "ClientIP" （默认值为 "None"）

1. kube-proxy会监视Kubernetes Service对象和Endpoints
2. 调用 netlink 接口以相应地 创建 ipvs规则
3. 定期与Kubernetes Service对象和Endpoints对象同步ipvs规则，以确保ipvs状态与期望一致
4. 访问服务时， 流量 将被 重定向 到其中一个 后端Pod

与 iptables 类似，ipvs基于 netfilter 的 hook 功能，但使用 哈希表 作为 底层数据结构 并在 内核空间 中工作

这意味着ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能

此外，ipvs为 负载均衡算法 提供了更多选项，例如：

• rr：轮询调度
• lc：最小连接数
• dh：目标哈希
• sh：源哈希
• sed：最短期望延迟
• nq： 不排队调度

注意： ipvs模式假定在运行kube-proxy之前在节点上都已经安装了IPVS内核模块

当kube-proxy以ipvs代理模式启动时，kube-proxy将验证节点上是否安装了IPVS模块，如果未安装，则kube-proxy将回退到iptables代理模式

一个不时出现的问题是，为什么都使用 VIP 的方式，而不使用标准的 round-robin DNS

有如下几个原因：

• 长久以来，DNS 库都没能认真对待 DNS TTL、缓存域名查询结果
• 很多应用只查询一次 DNS 并缓存了结果
• 就算应用和库能够正确查询解析，每个客户端反复重解析造成的负载也是非常难以管理的

尽力阻止用户做那些对他们没有好处的事情，如果很多人都来问这个问题，可能会选择实现它

当 Pod 运行在 Node 上，kubelet 会为每个 活跃的 Service 添加 一组 环境变量 。 它同时支持 Docker links 兼容 变量 、简单的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 变量

这里 Service 的名称需大写，横线被转换成下划线

举个例子，一个名称为 "redis-master" 的 Service 暴露了 TCP 端口 6379，同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量：

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

这意味着需要有顺序的要求：Pod 想要访问的任何 Service 必须在 Pod 自己之前被创建，否则这些环境变量就不会被赋值

DNS 并没有这个限制

一个可选 集群插件 是 DNS 服务器 。DNS 服务器 监视 着 创建 新 Service 的 Kubernetes API，从而为每一个 Service 创建 一组 DNS 记录 。如果整个集群的 DNS 一直被启用，那么所有的 Pod 应该能够自动对 Service 进行名称解析

例如，有一个名称为 "my-service" 的 Service，它在 Kubernetes 集群中名为 "my-ns" 的 Namespace 中，为 "my-service.my-ns" 创建了一条 DNS 记录

在名称为 "my-ns" 的 Namespace 中的 Pod 应该能够简单地通过名称查询找到 "my-service"

在另一个 Namespace 中的 Pod 必须限定名称为 "my-service.my-ns"

这些名称查询的结果是 Cluster IP 

Kubernetes 也支持对 端口名称 的 DNS SRV (Service) 记录

如果名称为 "my-service.my-ns" 的 Service 有一个名为 "http" 的 TCP 端口，可以对 "_http._tcp.my-service.my-ns" 执行 DNS SRV 查询，得到 "http" 的端口号

Kubernetes DNS 服务器是 唯一 的一种能够 访问 ExternalName 类型的 Service 的方式

如果定义了 selector 的 Headless Service， Endpoint 控制器 在 API 中创建了 Endpoints 记录 ，并且 修改 DNS 配置 返回 A 记录 （地址）

通过这个地址直接到达 Service 的后端 Pod 上

对没有定义 selector 的 Headless Service，Endpoint 控制器 不会创建 Endpoints 记录 。 然而 DNS 系统会查找和配置，无论是：

• ExternalName 类型: Service 的 CNAME 记录
  • 记录：与 Service 共享一个名称的任何 Endpoints，以及所有其它类型

如果设置 type 的值为 NodePort ：

1. Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口
2. 每个 Node 将从该端口（每个 Node 上的同一端口）代理到 Service
   • 该端口将通过 Service 的 spec.ports[*].nodePort 字段被指定

如果需要指定的端口号，可以配置 nodePort 的值，系统将分配这个端口，否则调用 API 将会失败（比如，需要关心端口冲突的可能性）

这可以让开发人员自由地安装他们自己的负载均衡器，并配置 Kubernetes 不能完全支持的环境参数，或者直接暴露一个或多个 Node 的 IP 地址

需要注意：Service 将能够通过 <NodeIP>:spec.ports[*].nodePort 和 spec.clusterIp:spec.ports[*].port 而 对外可见

使用支持外部负载均衡器的云提供商的服务，设置 type 的值为 LoadBalancer ，将为 Service 提供负载均衡器。负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 Service 的 status.loadBalancer 字段被发布出去：

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30061
  clusterIP: 10.0.171.239
  loadBalancerIP: 78.11.24.19
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
      - ip: 146.148.47.155

来自外部负载均衡器的流量将直接打到 backend Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。 在这些情况下，将根据用户设置的 loadBalancerIP 来创建负载均衡器：

• 某些云提供商允许设置 loadBalancerIP

  如果设置了 loadBalancerIP，但云提供商并不支持这种特性，那么设置的 loadBalancerIP 值将会被忽略掉
  

• 如果没有设置 loadBalancerIP，将会给负载均衡器指派一个 临时 IP

如果外部的 IP 路由 到 集群中 一个或多个 Node 上，Kubernetes Service 会被 暴露 给这些 externalIPs

通过外部 IP（作为目的 IP 地址）进入到集群，打到 Service 的端口上的流量，将会被路由到 Service 的 Endpoint 上

externalIPs 不会被 Kubernetes 管理，它属于集群管理员的职责范畴

根据 Service 的规定，externalIPs 可以同 任意的 ServiceType 来一起指定。在下面的例子中，my-service 可以在 80.11.12.10:80 （外部 IP:端口）上被客户端访问：

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
  externalIPs: 
    - 80.11.12.10

Kubernetes 最主要的哲学之一，是 用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错 的场景

来看一下网络端口：用户不应该必须选择一个端口号，而且该端口还有可能与其他用户的冲突，这就是说，在彼此隔离状态下仍然会出现失败

为了使用户能够为他们的 Service 选择一个端口号，必须确保不能有2个 Service 发生冲突

这是通过为每个 Service 分配它们自己的 IP 地址来实现：

• 为了保证每个 Service 被分配到一个唯一的 IP，需要一个 内部的分配器 能够 原子地 更新 etcd 中的一个 全局分配映射表

  这个更新操作要先于创建每一个 Service
  

• 为了使 Service 能够获取到 IP，这个 映射表 对象必须在 注册中心 存在，否则创建 Service 将会失败，指示一个 IP 不能被分配。一个后台 Controller 的职责：

  • 创建 映射表

    从 Kubernetes 的旧版本迁移过来，旧版本中是通过在内存中加锁的方式实现
    

  • 检查 由于管理员干预和清除任意 IP 造成的不合理分配

    这些 IP 被分配了但当前没有 Service 使用它们 
    

不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答

相反，使用 iptables 来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向：

• 当客户端连接到 VIP 时，它们的 流量 会 自动地传输 到一个合适的 Endpoint
• 环境变量 或 DNS ，实际上会根据 Service 的 VIP 和端口 来进行 填充