Kubernetes - Service

在你的应用程序中你可以使用 Kubernetes APIs 做服务发现，可以向 API Server 查询 Endpoints，每当在 Service 中的 Pod 集合发生变更时， 这些更新就会耕者更新。

对于非原生应用，Kubernetes 提供了防止网络端口的方法或者在应用程序和后端 Pod 之间的负载均衡器。

Service 最常见的是抽象对 Pod 集合的访问，但是他们也可以抽象其它类型的后端，比如：

• 你想要在生产中使用外部的数据库集群，但是在测试环境中，使用自己的数据库。
• 你想要将 Service 指向其他 Namespace 或者另外一个集群。
• 你正在将工作负载迁移到 Kubernetes。为了做测试，你在 Kubernetes 中运行一部分后端。

这种情况下，你可以定义一个 Service 不指定 Pod 选择器，如下：

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

因为 Service 没有选择器，对应的 Endpoint 对象不会被创建。你可以手动将 Service 映射到其运行所在网络的地址和端口，手动添加 Endpoint 对象：

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

Endpoints 对象必须是一个有效的 DNS 子域名。

注意：

Endpoint IPs 不可以 为：回环地址（IPv4 的127.0.0.0/8，IPv6 的 ::1/128），或者本地链接（IPv4 的 169.254.0.0/16 和 224.0.0.0/24 IPv6 的 fe80::/64）。

Endpoint IP 地址不能是 Kubernetes Services 集群 IPs，因为 kube-proxy 不支持虚拟 IPs 作为目标。

没有选择器的情况下访问 Service 和有选择器的访问一样。

ExternalName Service 是 Service 的特例，它没有选择器，而是使用 DNS 名称代替。

特性状态: Kubernetes v1.17 [beta]

EndpointSlices 是一种 API 资源，可以为 Endpoints 提供更具扩展性的替代方案。尽管从概念上来讲与 Endpoints 非常相似， 但 EndpointSlices 允许跨多个网络资源分布式网络 endpoints。默认情况下，EndpointSlice 到达 1000 个 endpoints 之后就会被认为是已满。 这时将创建其他的 EndpointSlice，以存储任何其他 endpoints。

EndpointSlices 提供了其他属性和功能，具体见：https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/

特性状态: Kubernetes v1.20 [stable]

appProtocol 字段提供了为每个服务端口指定应用程序协议的方法。该字段的值由相应的 Endpoints 和 EndpointSlice 对象镜像（mirror）。

该字段遵循标准的 Kubernetes 标签语法。值应该是 IANA 标准 service 名称 或者类似 mycompany.com/my-custom-protocol 的域名前缀。

经常会有人问，为什么 Kubernetes 要依赖于代理将流量转发到后端，而不是使用其他方式，比如说：是否可以配置具有多个 A 值的 DNS 记录， 并依靠轮询名称进行解析呢？

使用服务代理有以下几个原因：

• DNS 实现的历史悠久都不遵守记录的 TTLs，并且在查找结果过期后进行缓存。
• 某些应用仅执行一次 DNS 查找，并无限期缓存结果。
• 即使应用程序和程序库做了适当的重新解析，DNS 的低或者 0 TTLs 可能会给 DNS 带来高负载，从而使 DNS 变的难以管理。

在此模式下，Kube-proxy 监听 Kubernetes master 以添加或者删除 Service 和 Endpoint 对象。 对于每一个 Service ，它都会在本地节点上打开一个端口（随机选择）。与此代理端口的连接将代理到 Service 后端 Pod 之一。 在决定选择哪一个后端 Pod 时，kube-proxy 会考虑 Service 的 SessionAffinity 设置。

最后，user-space 代理安装 iptables 规则，以捕获到 Service 的 clusterIP 和 port 的流量。规则将流量重定向到代理后端 Pod 的 代理端口。

默认情况下，user-proxy 模式下的 kube-proxy 通过轮询算法选择后端。

在这种模式下，kube-proxy 监听 Kubernetes 控制面板用于添加和删除 Service 和 Endpoint 对象。对于每一个 Services，它安装 iptables 规则，用来捕获到 Service 的 clusterIP 和 port 的流量，然后将该流量重定向到 Services 的后端集合之一。 对于每一个 Endpoint 对象，都会安装 iptables 规则来选择后端 Pod。

默认情况下，iptables 模式下的 kube-proxy 会随机选择一个后端。

使用 iptables 处理流有较低的系统开销，因为流量由 Linux netfilter 处理，而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。

如果 kube-proxy 在 iptables 模式下运行，并且所选择的第一个 Pod 没有响应，则连接失败。这和 userspace 模式不同在于： 在这种情况下，kube-proxy 会检测与第一个 Pod 的连接失败，并会自动使用其它后端 Pod 重试。

你可以使用 Pod 的可用检测（readiness）探针来检测后端 Pods 是不是正常运行，确保 kube-proxy 只看到经过测试后正常的后端。 这样做可以避免流量通过 kube-proxy 发送到已知故障的 Pod。

Kubernetes v1.11 之后支持的特性, stable 。

在 ipvs 模式中，kube-proxy 监听 Kubernetes Services 和 Endpoints，调用 netlink 接口创建对应的 IPVS 规则并定期与 Kubernetes 中的对象保持同步。这种控制循环可确保 IPVS 状态与所期望状态匹配。当访问 Service 时，IPVS 直接转发流量到一个后端 Pod 中。

IPVS 代理模式基于 netfilter hook 函数与 iptables 模式类似，但是它使用哈希表作为基础数据结构，并在内核空间中工作。 这意味着 kube-proxy 在 IPVS 模式重定向流量延迟比 iptables 模式下的 kube-proxy 还要低，在同步代理规则时具有更好的性能。 与其他代理模式相比，IPVS 模式还支持更高网络流量吞吐量。

IPVS 为后端 Pods 流量的负载均衡提供了更多的选项：

• rr 轮询
• lc 最小连接（打开连接的最小数量）
• dh 目标 hashing
• sh 源 hashing
• sed 最短预期延迟
• nq 永不排队（never queue）

注意： 使用 IPVS 模式的 kube-proxy，必须在启动 kube-proxy 之前使 IPVS Linux 在节点上可用。

当 kube-proxy 在 IPVS 代理模式下启动，它会验证 IPVS 内核模块是否可用。如果 IPVS 内核模块没有被检测到，它会以 iptables 代理 模式运行。

在这些代理模式中，Service 的 IP 流量限制：在客户端不知道 Kubernetes 或者 Service 或者 Pod 的任何信息的情况下，将 Port 代理到合适的后端。

如果你想确保每次都将来自特定的客户端的连接都传递给相同的 Pod，你可以通过设置客户端基于 IP 地址的会话亲和性 service.spec.sessionAffinity 设置为 "ClientIP" （默认情况下是 "None"）。你也可以适当的设置 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 来控制最大会话粘性时间。（默认是 10800，3小时）。

当节点上运行一个 Pod，kubelet 回味每个激活的 Service 添加一组环境变量。它既支持 Docker lins compatible 变量又支持简单的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 变量，Service 名称为大写字母，并且破折号转换为下划线。

比如，Service redis-master 暴露了 TCP 端口 6379 而且分配至集群 IP 地址为 10.0.0.11，将产生以下的环境变量：

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，并且你使用环境变量的方法来将端口和集群 IP 发布到客户端 Pod， 你必须在客户端 Pods 产生之前创建 Service。否则这些客户端 Pods 不会填充其环境变量。

如果你仅使用 DNS 查找服务的集群 IP，那么不用担心顺序问题。

你应该添加插件来为你的集群创建一个 DNS 服务（并且总应该这么做）。

一个支持集群的 DNS 服务，比如 CoreDNS，监听 Kubernetes API 的 Service 创建，然后创建为每个记录创建一组 DNS 记录。 如果在整个集群中都启用了 DNS，那么所有的 Pods 都应该能够通过其 DNS 名称解析其 Services。

比如说在 Kubernetes 空间 my-ns 中包含一个 Service 叫做 my-service ，控制平面和 DNS 服务共同为 my-service.my-ns 创建一个 DNS 记录。在 my-ns 空间中可以简单的通过 my-service 找到对应的服务，使用 my-service.my-ns 也可以。。

在其它空间的服务必须使用 my-service.my-ns 才可以。这些名字会被解析为 Service 的集群 IP。

Kubernetes 还支持命名端口的 DNS SRV(Service) 记录。如果 my-service.my-ns Serivce 包含一个命名端口 http 协议为 TCP , 你可以为 _http._tcp.my-service.my-ns 做一个 DNS SRV 来发现 http 的端口号，以及 IP 地址。

Kubernetes DNS 服务器是唯一访问 ExternalName Services 的方法。你可以在 DNS Pods 和 Services 中找到更多的关于 ExternalName 的解释。

如果定义了选择器，endpoints 控制器在 API 中创建 Endpoints 记录，然后修改 DNS 配置返回记录（指向 Service 后面的 Pods ）。

如果没有定义选择器的话，endpoints 控制器不会创建 Endpoints 记录。然而，DNS 系统会查找并配置以下任意一项：

• ExternalName 类型 Services 的 CNAME 记录；
• 其他的类型，任何的 Endpoints 与 Services 共享名字的记录；

当你的 type 字段设置为 NodePort ，Kubernetes 控制平面会从 --service-node-port-range 中分配一个端口 （默认为 30000-32767）。每一个节点都会代理这个端口到你的 Service 中。你的 Service 在它的 .spec.ports[*].nodePort 字段中 报告分配端口的值。

如果你想要指定特定的 IP(s) 代理到端口，你可以设置 --nodeport-addresses 在 kube-proxy 中指定 IP 块； 这个特性从 Kubernetes v1.10 开始支持。该标识用逗号分割的 IP 块（比如：10.0.0.0/8, 192.0.2.0/25）指定 IP 地址范围 以 kube-proxy 应该视该节点为本地节点。

比如，你启动 kube-proxy 设置 -nodeport-addresses=127.0.0.0/8 ，kube-proxy 只会选择 NodePort Services 的回环接口。 默认设置的 --nodeport-addresses 是一个空的列表。这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口 （这也与早起的 Kubernetes 版本兼容）。

如果你想要指定端口号，你可以在 nodePort 字段中指定值。控制平面会为你分配该端口或者告诉你 API 事务失败。也就是说 你要自己注意端口是否会冲突。你还必须要使用有效的端口号，确保端口号在配置的范围内。

使用 NodePort 会给你自由设置自己的负载均衡方案，配置 Kubernetes 不完全支持的环境，甚至是直接暴露一个或者多个节点的 IP。

注意 Service 以 <NodeIP>:spec.ports[*].nodePort 和 .spec.clusterIP:spec.ports[*].port 可见（如果 --nodeport-addresses 在 kube-proxy 中设置了，将被过滤 NodeIPs ）。

比如：

apiVersion: v1
kind: Service
metadata:
  name: my-service
  spec:
    type: NodePort
    selector:
      app: MyApp
      ports:
        # By default and for convenience, the `targetPort` is set to the same value as the `port` field.
        - port: 80
          targetPort: 80
          # Optional field
          # By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767)
          nodePort: 30007

https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer

类型为 ExternalName 的 Service 会将 Service 映射为一个 DNS 名字，而不是一个典型的类似 my-service 或者 cassandra 的选择器。 你可以使用 .spec.externalName 参数来指定这些 Services。

下面的 Service 定义，在 prod 空间中将 my-service 映射到 my.database.example.com :

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

注意： ExternalName 接受一个 IPv4 的字符串地址，包括数字组成的 DNS 地址，而不是 IP 地址。 类似与 IPv4 地址的 ExternalName 不会被 CoreDNS 或者 ingress-nginx 解析，因为 ExternalName 用于指定规范的 DNS 名称。 要对 IP 地址进行硬编码，请考虑使用 headless Services。

当查找 my-service.prod.svc.cluster.local 的主机时，集群的 DNS 服务将返回值为 my.database.example.com 的 CNAME 值。 访问 my-service 的方式与其他 Services 的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或者转发。 如果以后你决定将数据库迁移到集群中，则可以启动其 Pods，添加使用的选择器或者 endpoints，并修改它的 Services 类型。

警告： 你可以在使用 ExternalName 一些协议的过程中遇到麻烦，包括 HTTP 和 HTTPS。 如果你 ExternalName ，则集群内的客户端使用的主机名和 ExternalName 应用的名字不同。

对于使用主机名的协议，此差异可能导致错误或者意外的回包。HTTP 请求将具有原始服务器无法识别的 Host: header； TLS 服务器将无法提供与客户端连接的主机名匹配的证书。

如果有外部的 IP 路由到一个或者多个集群节点，Kubernetes Services 可以在 externalIPs 上暴露。 作为外部 IP（作为目标 IP）流量通过 ingresses 到集群，在 Service 端口上，会被路又道 Service 的 endpoints 之一。 externalIPs 不会受 Kubernetes 的管控，而是集群管理员的责任。

在 Service spec 中， externalIPs 与 ServiceTypes 一起指定。如下， my-service 可以被客户端在 80.11.12.10:80 上访问。

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

Kubernetes 的一个主要的设计哲学是：不是你的错误，你不应该面临可能导致失败的场景。对于 Service 资源的设计，意味着如果你选择的端口 跟可能跟别的端口相冲突，那就不要让你来选择端口。这就是个隔离失败。

为了允许你为你的 Services 选择一个端口号，我们必须要保证两个 Services 可以冲突。Kubernetes 是通过每个 Service 都分配一个自己的 IP 地址来实现的。

为了保证每个 Service 都有一个唯一的 IP，内部分配器在创建 Service 之前原子更新 etcd 中的全局分配映射。映射对象必须在注册表中， Services 才能分配到一个 IP 地址。否则会创建失败，并且提示无法分配 IP 地址的错误信息。

在控制平面中，后台控制器负责创建该映射关系，Kubernetes 还使用控制器来检查无效的分配（比如管理员的干预）和清理以不再被任何 Services 使用的 IP 地址。

不想 Pod 的 IP 地址，真实的路由到固定的目的地，Service IPs 不是由真实的单个主机来应答。而是，kube-proxy 使用 iptables（ Linux 上的包逻辑处理进程）来定义一个 虚拟的 IP 地址来透明的重定向到需要的地方。当客户端来连接 VIP 的时候，他们的流量 自动传输到适当的 endpoints。Services 的环境变量和 DNS 实际上是根据 Services 的虚拟 IP 地址（和端口）来填充的。

kube-proxy 支持三种代理模式 - 用户空间（usespace），iptables 和 IPVS - 每个操作都略有不同。

在任何的 Services 上你可以使用 TCP 协议，这也是默认的网络协议。

在大多数 Services 上你可以使用 UDP 协议，对于 type=LoadBalancer 的 Services，UDP 的支持取决于提供此功能的云厂商。

特性状态： kubernetes v1.20 [stable]

当使用 SCTP 流量的网络插件时，你可以在大多数 Service 上使用 SCTP ，对于 type=LoadBalancer 的 Services，SCTP 的支持取决于 提供此功能的云厂商（大部分都不支持）。

注意： SCTP 不支持基于 Windows 的节点。

用户空间 kube-proxy

Warning: The kube-proxy does not support the management of SCTP associations when it is in userspace mode.

如果你的云厂商提供了它，你就可以使用 Service 的 LoadBalancer 模式来设置外部的 HTTP/HTTPS 反向代理，转发到 Service 的 Endpoints。

注意： 你也使用 Ingress 替换 Service 来暴露 HTTP/HTTPS 协议。

如果你的云厂商提供了它，你就可以使用 Service 的 LoadBalancer 模式来配置 Kubernetes 自身之外的负载均衡，它会转发以 PROXY 协议 为前缀的连接。

负载均衡器将发送一系列的出十字街，描述传入的连接，类似于：

PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

其次是来自客户端的数据。