服务（Service）

使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pod 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。

动机

创建和销毁 Kubernetes Pod 以匹配集群的期望状态。 Pod 是非永久性资源。 如果你使用 Deployment 来运行你的应用程序，则它可以动态创建和销毁 Pod。

每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。

这导致了一个问题： 如果一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能， 那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用提供工作负载的后端部分？

进入 Services。

Service 资源

Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。 Service 所针对的 Pod 集合通常是通过选择算符来确定的。 要了解定义服务端点的其他方法，请参阅不带选择算符的服务。

举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化， 前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。

Service 定义的抽象能够解耦这种关联。

云原生服务发现

如果你想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询 API 服务器 用于匹配 EndpointSlices。只要服务中的 Pod 集合发生更改，Kubernetes 就会为服务更新 EndpointSlices。

对于非本机应用程序，Kubernetes 提供了在应用程序和后端 Pod 之间放置网络端口或负载均衡器的方法。

定义 Service

Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 像所有的 REST 对象一样，Service 定义可以基于 POST 方式，请求 API server 创建新的实例。 Service 对象的名称必须是合法的 RFC 1035 标签名称。

例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 app.kubernetes.io/name=MyApp 标签：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

上述配置创建一个名称为 "my-service" 的 Service 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 app.kubernetes.io/name=MyApp 的 Pod 上。

Kubernetes 为该服务分配一个 IP 地址（有时称为 “集群 IP”），该 IP 地址由服务代理使用。 (请参见下面的 VIP 和 Service 代理).

服务选择算符的控制器不断扫描与其选择算符匹配的 Pod，然后将所有更新发布到也称为 “my-service” 的 Endpoint 对象。

Pod 中的端口定义是有名字的，你可以在 Service 的 targetPort 属性中引用这些名称。 例如，我们可以通过以下方式将 Service 的 targetPort 绑定到 Pod 端口：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app.kubernetes.io/name: proxy
spec:
  containers:
  - name: nginx
    image: nginx:stable
    ports:
      - containerPort: 80
        name: http-web-svc

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app.kubernetes.io/name: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort: http-web-svc

即使 Service 中使用同一配置名称混合使用多个 Pod，各 Pod 通过不同的端口号支持相同的网络协议， 此功能也可以使用。这为 Service 的部署和演化提供了很大的灵活性。 例如，你可以在新版本中更改 Pod 中后端软件公开的端口号，而不会破坏客户端。

服务的默认协议是 TCP；你还可以使用任何其他受支持的协议。

由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。 每个端口定义可以具有相同的 protocol，也可以具有不同的协议。

没有选择算符的 Service

由于选择算符的存在，服务最常见的用法是为 Kubernetes Pod 的访问提供抽象， 但是当与相应的 EndpointSlices 对象一起使用且没有选择算符时， 服务也可以为其他类型的后端提供抽象，包括在集群外运行的后端。

例如：

• 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
• 希望服务指向另一个 名字空间（Namespace） 中或其它集群中的服务。
• 你正在将工作负载迁移到 Kubernetes。在评估该方法时，你仅在 Kubernetes 中运行一部分后端。

在任何这些场景中，都能够定义没有选择算符的 Service。 实例:

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

由于此服务没有选择算符，因此不会自动创建相应的 EndpointSlice（和旧版 Endpoint）对象。 你可以通过手动添加 EndpointSlice 对象，将服务手动映射到运行该服务的网络地址和端口：

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: my-service-1 # 按惯例将服务的名称用作 EndpointSlice 名称的前缀
  labels:
    # 你应设置 "kubernetes.io/service-name" 标签。
    # 设置其值以匹配服务的名称
    kubernetes.io/service-name: my-service
addressType: IPv4
ports:
  - name: '' # 留空，因为 port 9376 未被 IANA 分配为已注册端口
    appProtocol: http
    protocol: TCP
    port: 9376
endpoints:
  - addresses:
      - "10.4.5.6" # 此列表中的 IP 地址可以按任何顺序显示
      - "10.1.2.3"

自定义 EndpointSlices

当为服务创建 EndpointSlice 对象时，可以为 EndpointSlice 使用任何名称。 命名空间中的每个 EndpointSlice 必须有一个唯一的名称。通过在 EndpointSlice 上设置 kubernetes.io/service-name label 可以将 EndpointSlice 链接到服务。

对于你自己或在你自己代码中创建的 EndpointSlice，你还应该为 endpointslice.kubernetes.io/managed-by 标签拣选一个值。如果你创建自己的控制器代码来管理 EndpointSlice， 请考虑使用类似于 "my-domain.example/name-of-controller" 的值。 如果你使用的是第三方工具，请使用全小写的工具名称，并将空格和其他标点符号更改为短划线 (-)。 如果人们直接使用 kubectl 之类的工具来管理 EndpointSlices，请使用描述这种手动管理的名称， 例如 "staff" 或 "cluster-admins"。你应该避免使用保留值 "controller"， 该值标识由 Kubernetes 自己的控制平面管理的 EndpointSlices。

访问没有选择算符的 Service

访问没有选择算符的 Service，与有选择算符的 Service 的原理相同。 在没有选择算符的 Service 示例中， 流量被路由到 EndpointSlice 清单中定义的两个端点之一： 通过 TCP 协议连接到 10.1.2.3 或 10.4.5.6 的端口 9376。

ExternalName Service 是 Service 的特例，它没有选择算符，但是使用 DNS 名称。 有关更多信息，请参阅本文档后面的 ExternalName。

EndpointSlices

EndpointSlices 这些对象表示针对服务的后备网络端点的子集（切片）。

你的 Kubernetes 集群会跟踪每个 EndpointSlice 表示的端点数量。 如果服务的端点太多以至于达到阈值，Kubernetes 会添加另一个空的 EndpointSlice 并在其中存储新的端点信息。 默认情况下，一旦现有 EndpointSlice 都包含至少 100 个端点，Kubernetes 就会创建一个新的 EndpointSlice。 在需要添加额外的端点之前，Kubernetes 不会创建新的 EndpointSlice。

参阅 EndpointSlices 了解有关该 API 的更多信息。

Endpoints

在 Kubernetes API 中，Endpoints （该资源类别为复数）定义了网络端点的列表，通常由 Service 引用，以定义可以将流量发送到哪些 Pod。

推荐用 EndpointSlice API 替换 Endpoints。

超出容量的端点

Kubernetes 限制单个 Endpoints 对象中可以容纳的端点数量。 当一个服务有超过 1000 个后备端点时，Kubernetes 会截断 Endpoints 对象中的数据。 由于一个服务可以链接多个 EndpointSlice，所以 1000 个后备端点的限制仅影响旧版的 Endpoints API。

这种情况下，Kubernetes 选择最多 1000 个可能的后端端点来存储到 Endpoints 对象中，并在 Endpoints: endpoints.kubernetes.io/over-capacity: truncated 上设置注解。 如果后端 Pod 的数量低于 1000，控制平面也会移除该注解。

流量仍会发送到后端，但任何依赖旧版 Endpoints API 的负载均衡机制最多只能将流量发送到 1000 个可用的后备端点。

相同的 API 限制意味着你不能手动将 Endpoints 更新为拥有超过 1000 个端点。

应用协议

appProtocol 字段提供了一种为每个 Service 端口指定应用协议的方式。 此字段的取值会被映射到对应的 Endpoints 和 EndpointSlices 对象。

该字段遵循标准的 Kubernetes 标签语法。 其值可以是 IANA 标准服务名称 或以域名为前缀的名称，如 mycompany.com/my-custom-protocol。

虚拟 IP 和 Service 代理

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。

为什么不使用 DNS 轮询？

时不时会有人问到为什么 Kubernetes 依赖代理将入站流量转发到后端。那其他方法呢？ 例如，是否可以配置具有多个 A 值（或 IPv6 为 AAAA）的 DNS 记录，并依靠轮询名称解析？

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

• DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。
• 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。
• 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给 DNS 带来高负载，从而使管理变得困难。

在本页下文中，你可以了解各种 kube-proxy 实现是如何工作的。 总的来说，你应该注意当运行 kube-proxy 时，内核级别的规则可能会被修改（例如，可能会创建 iptables 规则）， 在某些情况下直到你重新引导才会清理这些内核级别的规则。 因此，运行 kube-proxy 只能由了解在计算机上使用低级别、特权网络代理服务后果的管理员来完成。 尽管 kube-proxy 可执行文件支持 cleanup 功能，但此功能不是官方特性，因此只能按原样使用。

配置

请注意，kube-proxy 可以以不同的模式启动，具体取决于其配置。

• kube-proxy 的配置是通过 ConfigMap 完成的，并且 kube-proxy 的 ConfigMap 有效地弃用了 kube-proxy 几乎所有标志的行为。
• kube-proxy 的 ConfigMap 不支持实时重新加载配置。
• kube-proxy 的 ConfigMap 参数不能在启动时被全部校验和验证。 例如，如果你的操作系统不允许你运行 iptables 命令，则标准内核 kube-proxy 实现将无法工作。 同样，如果你的操作系统不支持 netsh，它将无法在 Windows 用户空间模式下运行。

userspace 代理模式

在这种（遗留）模式下，kube-proxy 会监视 Kubernetes 控制平面对 Service 对象和 Endpoints 对象的添加和移除操作。 对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。 任何连接到“代理端口”的请求，都会被代理到 Service 的后端 Pods 中的某个上面（如 Endpoints 所报告的一样）。 使用哪个后端 Pod，是 kube-proxy 基于 SessionAffinity 来确定的。

最后，它配置 iptables 规则，捕获到达该 Service 的 clusterIP（是虚拟 IP） 和 Port 的请求，并重定向到代理端口，代理端口再代理请求到后端Pod。

默认情况下，用户空间模式下的 kube-proxy 通过轮转算法选择后端。

iptables 代理模式

这种模式，kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。 对于每个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个后端组合。

默认的策略是，kube-proxy 在 iptables 模式下随机选择一个后端。

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

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

你可以使用 Pod 就绪探测器 验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。 这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。

IPVS 代理模式

在 ipvs 模式下，kube-proxy 监视 Kubernetes 服务和端点，调用 netlink 接口相应地创建 IPVS 规则， 并定期将 IPVS 规则与 Kubernetes 服务和端点同步。该控制循环可确保 IPVS 状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端 Pod 之一。

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

IPVS 提供了更多选项来平衡后端 Pod 的流量。这些是：

• rr：轮替（Round-Robin）
• lc：最少链接（Least Connection），即打开链接数量最少者优先
• dh：目标地址哈希（Destination Hashing）
• sh：源地址哈希（Source Hashing）
• sed：最短预期延迟（Shortest Expected Delay）
• nq：从不排队（Never Queue）

在这些代理模型中，绑定到服务 IP 的流量： 在客户端不了解 Kubernetes 或服务或 Pod 的任何信息的情况下，将 Port 代理到适当的后端。

如果要确保每次都将来自特定客户端的连接传递到同一 Pod， 则可以通过将 service.spec.sessionAffinity 设置为 "ClientIP" （默认值是 "None"），来基于客户端的 IP 地址选择会话亲和性。 你还可以通过适当设置 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 来设置最大会话停留时间。（默认值为 10800 秒，即 3 小时）。

多端口 Service

对于某些服务，你需要公开多个端口。 Kubernetes 允许你在 Service 对象上配置多个端口定义。 为服务使用多个端口时，必须提供所有端口名称，以使它们无歧义。 例如：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
    - name: https
      protocol: TCP
      port: 443
      targetPort: 9377

选择自己的 IP 地址

在 Service 创建的请求中，可以通过设置 spec.clusterIP 字段来指定自己的集群 IP 地址。 比如，希望替换一个已经已存在的 DNS 条目，或者遗留系统已经配置了一个固定的 IP 且很难重新配置。

用户选择的 IP 地址必须合法，并且这个 IP 地址在 service-cluster-ip-range CIDR 范围内， 这对 API 服务器来说是通过一个标识来指定的。 如果 IP 地址不合法，API 服务器会返回 HTTP 状态码 422，表示值不合法。

流量策略

外部流量策略

你可以通过设置 spec.externalTrafficPolicy 字段来控制来自于外部的流量是如何路由的。 可选值有 Cluster 和 Local。字段设为 Cluster 会将外部流量路由到所有就绪的端点， 设为 Local 会只路由到当前节点上就绪的端点。 如果流量策略设置为 Local，而且当前节点上没有就绪的端点，kube-proxy 不会转发请求相关服务的任何流量。

内部流量策略

你可以设置 spec.internalTrafficPolicy 字段来控制内部来源的流量是如何转发的。可设置的值有 Cluster 和 Local。 将字段设置为 Cluster 会将内部流量路由到所有就绪端点，设置为 Local 只会路由到当前节点上就绪的端点。 如果流量策略是 Local，而且当前节点上没有就绪的端点，那么 kube-proxy 会丢弃流量。

服务发现

Kubernetes 支持两种基本的服务发现模式 —— 环境变量和 DNS。

环境变量

当 Pod 运行在 Node 上，kubelet 会为每个活跃的 Service 添加一组环境变量。 kubelet 为 Pod 添加环境变量 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT。 这里 Service 的名称需大写，横线被转换成下划线。 它还支持与 Docker Engine 的 "legacy container links" 特性兼容的变量 （参阅 makeLinkVariables) 。

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

REDIS_PRIMARY_SERVICE_HOST=10.0.0.11
REDIS_PRIMARY_SERVICE_PORT=6379
REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379
REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp
REDIS_PRIMARY_PORT_6379_TCP_PORT=6379
REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11

DNS

你可以（几乎总是应该）使用附加组件 为 Kubernetes 集群设置 DNS 服务。

支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 如果在整个集群中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。

例如，如果你在 Kubernetes 命名空间 my-ns 中有一个名为 my-service 的服务， 则控制平面和 DNS 服务共同为 my-service.my-ns 创建 DNS 记录。 my-ns 命名空间中的 Pod 应该能够通过按名检索 my-service 来找到服务 （my-service.my-ns 也可以工作）。

其他命名空间中的 Pod 必须将名称限定为 my-service.my-ns。 这些名称将解析为为服务分配的集群 IP。

Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 如果 my-service.my-ns 服务具有名为 http　的端口，且协议设置为 TCP， 则可以对 _http._tcp.my-service.my-ns 执行 DNS SRV 查询以发现该端口号、"http" 以及 IP 地址。

Kubernetes DNS 服务器是唯一的一种能够访问 ExternalName 类型的 Service 的方式。 更多关于 ExternalName 信息可以查看 DNS Pod 和 Service。

无头服务（Headless Services）

有时不需要或不想要负载均衡，以及单独的 Service IP。 遇到这种情况，可以通过指定 Cluster IP（spec.clusterIP）的值为 "None" 来创建 Headless Service。

你可以使用一个无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。

对于无头 Services 并不会分配 Cluster IP，kube-proxy 不会处理它们， 而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置，依赖于 Service 是否定义了选择算符。

带选择算符的服务

对定义了选择算符的无头服务，Kubernetes 控制平面在 Kubernetes API 中创建 EndpointSlice 对象， 并且修改 DNS 配置返回 A 或 AAA 条记录（IPv4 或 IPv6 地址），通过这个地址直接到达 Service 的后端 Pod 上。

无选择算符的服务

对没有定义选择算符的无头服务，控制平面不会创建 EndpointSlice 对象。 然而 DNS 系统会查找和配置以下之一：

• 对于 type: ExternalName 服务，查找和配置其 CNAME 记录
• 对所有其他类型的服务，针对 Service 的就绪端点的所有 IP 地址，查找和配置 DNS A / AAAA 条记录
  • 对于 IPv4 端点，DNS 系统创建 A 条记录。
  • 对于 IPv6 端点，DNS 系统创建 AAAA 条记录。

发布服务（服务类型）

对一些应用的某些部分（如前端），可能希望将其暴露给 Kubernetes 集群外部的 IP 地址。

Kubernetes ServiceTypes 允许指定你所需要的 Service 类型。

Type 的取值以及行为如下：

• ClusterIP：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是你没有为服务显式指定 type 时使用的默认值。

• NodePort：通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 为了让节点端口可用，Kubernetes 设置了集群 IP 地址，这等同于你请求 type: ClusterIP 的服务。

• LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。

• ExternalName：通过返回 CNAME 记录和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理。

  说明：

  你需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 ExternalName 类型。

你也可以使用 Ingress 来暴露自己的服务。 Ingress 不是一种服务类型，但它充当集群的入口点。 它可以将路由规则整合到一个资源中，因为它可以在同一 IP 地址下公开多个服务。

NodePort 类型

如果你将 type 字段设置为 NodePort，则 Kubernetes 控制平面将在 --service-node-port-range 标志指定的范围内分配端口（默认值：30000-32767）。 每个节点将那个端口（每个节点上的相同端口号）代理到你的服务中。 你的服务在其 .spec.ports[*].nodePort 字段中报告已分配的端口。

使用 NodePort 可以让你自由设置自己的负载均衡解决方案， 配置 Kubernetes 不完全支持的环境， 甚至直接暴露一个或多个节点的 IP 地址。

对于 NodePort 服务，Kubernetes 额外分配一个端口（TCP、UDP 或 SCTP 以匹配服务的协议）。 集群中的每个节点都将自己配置为监听分配的端口并将流量转发到与该服务关联的某个就绪端点。 通过使用适当的协议（例如 TCP）和适当的端口（分配给该服务）连接到所有节点， 你将能够从集群外部使用 type: NodePort 服务。

选择你自己的端口

如果需要特定的端口号，你可以在 nodePort 字段中指定一个值。 控制平面将为你分配该端口或报告 API 事务失败。 这意味着你需要自己注意可能发生的端口冲突。 你还必须使用有效的端口号，该端口号在配置用于 NodePort 的范围内。

以下是 type: NodePort 服务的一个示例清单，它指定了一个 NodePort 值（在本例中为 30007）。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
      # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。
    - port: 80
      targetPort: 80
      # 可选字段
      # 默认情况下，为了方便起见，Kubernetes 控制平面会从某个范围内分配一个端口号（默认：30000-32767）
      nodePort: 30007

为 type: NodePort 服务自定义 IP 地址配置

你可以在集群中设置节点以使用特定 IP 地址来提供 NodePort 服务。 如果每个节点都连接到多个网络（例如：一个网络用于应用程序流量，另一个网络用于节点和控制平面之间的流量）， 你可能需要执行此操作。

如果你要指定特定的 IP 地址来代理端口，可以将 kube-proxy 的 --nodeport-addresses 标志或 kube-proxy 配置文件的等效 nodePortAddresses 字段设置为特定的 IP 段。

此标志采用逗号分隔的 IP 段列表（例如 10.0.0.0/8、192.0.2.0/25）来指定 kube-proxy 应视为该节点本地的 IP 地址范围。

例如，如果你使用 --nodeport-addresses=127.0.0.0/8 标志启动 kube-proxy， 则 kube-proxy 仅选择 NodePort 服务的环回接口。 --nodeport-addresses 的默认值是一个空列表。 这意味着 kube-proxy 应考虑 NodePort 的所有可用网络接口。 （这也与早期的 Kubernetes 版本兼容。）

LoadBalancer 类型

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

实例：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

来自外部负载均衡器的流量将直接重定向到后端 Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。

某些云提供商允许设置 loadBalancerIP。 在这些情况下，将根据用户设置的 loadBalancerIP 来创建负载均衡器。 如果没有设置 loadBalancerIP 字段，将会给负载均衡器指派一个临时 IP。 如果设置了 loadBalancerIP，但云提供商并不支持这种特性，那么设置的 loadBalancerIP 值将会被忽略掉。

要实现 type: LoadBalancer 的服务，Kubernetes 通常首先进行与请求 type: NodePort 服务等效的更改。 cloud-controller-manager 组件然后配置外部负载均衡器以将流量转发到已分配的节点端口。

作为 Alpha 特性，你可以将负载均衡服务配置为忽略分配节点端口， 前提是云提供商实现支持这点。

混合协议类型的负载均衡器

默认情况下，对于 LoadBalancer 类型的服务，当定义了多个端口时， 所有端口必须具有相同的协议，并且该协议必须是受云提供商支持的协议。

当服务中定义了多个端口时，特性门控 MixedProtocolLBService（在 kube-apiserver 1.24 版本默认为启用）允许 LoadBalancer 类型的服务使用不同的协议。

禁用负载均衡器节点端口分配

你可以通过设置 spec.allocateLoadBalancerNodePorts 为 false 对类型为 LoadBalancer 的服务禁用节点端口分配。 这仅适用于直接将流量路由到 Pod 而不是使用节点端口的负载均衡器实现。 默认情况下，spec.allocateLoadBalancerNodePorts 为 true， LoadBalancer 类型的服务继续分配节点端口。 如果现有服务已被分配节点端口，将参数 spec.allocateLoadBalancerNodePorts 设置为 false 时，这些服务上已分配置的节点端口不会被自动释放。 你必须显式地在每个服务端口中删除 nodePorts 项以释放对应端口。

设置负载均衡器实现的类别

spec.loadBalancerClass 允许你不使用云提供商的默认负载均衡器实现，转而使用指定的负载均衡器实现。 默认情况下，.spec.loadBalancerClass 的取值是 nil，如果集群使用 --cloud-provider 配置了云提供商， LoadBalancer 类型服务会使用云提供商的默认负载均衡器实现。 如果设置了 .spec.loadBalancerClass，则假定存在某个与所指定的类相匹配的负载均衡器实现在监视服务变化。 所有默认的负载均衡器实现（例如，由云提供商所提供的）都会忽略设置了此字段的服务。.spec.loadBalancerClass 只能设置到类型为 LoadBalancer 的 Service 之上，而且一旦设置之后不可变更。

.spec.loadBalancerClass 的值必须是一个标签风格的标识符， 可以有选择地带有类似 "internal-vip" 或 "example.com/internal-vip" 这类前缀。 没有前缀的名字是保留给最终用户的。

内部负载均衡器

在混合环境中，有时有必要在同一(虚拟)网络地址块内路由来自服务的流量。

在水平分割 DNS 环境中，你需要两个服务才能将内部和外部流量都路由到你的端点（Endpoints）。

如要设置内部负载均衡器，请根据你所使用的云运营商，为服务添加以下注解之一。

• Default
• GCP
• AWS
• Azure
• IBM Cloud
• OpenStack
• Baidu Cloud
• Tencent Cloud
• Alibaba Cloud
• OCI

[...]
metadata:
    name: my-service
    annotations:
        cloud.google.com/load-balancer-type: "Internal"
[...]

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/aws-load-balancer-internal: "true"
[...]

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
[...]

[...]
metadata:
    name: my-service
    annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
[...]

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
[...]

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
[...]

[...]
metadata:
  annotations:
    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
[...]

[...]
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
[...]

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/oci-load-balancer-internal: true
[...]

AWS TLS 支持

为了对在 AWS 上运行的集群提供 TLS/SSL 部分支持，你可以向 LoadBalancer 服务添加三个注解：

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012

第一个指定要使用的证书的 ARN。 它可以是已上载到 IAM 的第三方颁发者的证书， 也可以是在 AWS Certificate Manager 中创建的证书。

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp)

第二个注解指定 Pod 使用哪种协议。对于 HTTPS 和 SSL，ELB 希望 Pod 使用证书通过加密连接对自己进行身份验证。

HTTP 和 HTTPS 选择第7层代理：ELB 终止与用户的连接，解析标头，并在转发请求时向 X-Forwarded-For 标头注入用户的 IP 地址（Pod 仅在连接的另一端看到 ELB 的 IP 地址）。

TCP 和 SSL 选择第4层代理：ELB 转发流量而不修改报头。

在某些端口处于安全状态而其他端口未加密的混合使用环境中，可以使用以下注解：

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
        service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443"

在上例中，如果服务包含 80、443 和 8443 三个端口， 那么 443 和 8443 将使用 SSL 证书， 而 80 端口将转发 HTTP 数据包。

从 Kubernetes v1.9 起可以使用 预定义的 AWS SSL 策略 为你的服务使用 HTTPS 或 SSL 侦听器。 要查看可以使用哪些策略，可以使用 aws 命令行工具：

aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName'

然后，你可以使用 "service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy" 注解; 例如：

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01"

AWS 上的 PROXY 协议支持

为了支持在 AWS 上运行的集群，启用 PROXY 协议。 你可以使用以下服务注解：

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"

从 1.3.0 版开始，此注解的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。

AWS 上的 ELB 访问日志

有几个注解可用于管理 AWS 上 ELB 服务的访问日志。

注解 service.beta.kubernetes.io/aws-load-balancer-access-log-enabled 控制是否启用访问日志。

注解 service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval 控制发布访问日志的时间间隔（以分钟为单位）。你可以指定 5 分钟或 60 分钟的间隔。

注解 service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name 控制存储负载均衡器访问日志的 Amazon S3 存储桶的名称。

注解 service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix 指定为 Amazon S3 存储桶创建的逻辑层次结构。

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
        # 指定是否为负载均衡器启用访问日志
        service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
        # 发布访问日志的时间间隔。你可以将其设置为 5 分钟或 60 分钟。
        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
        # 用来存放访问日志的 Amazon S3 Bucket 名称
        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
        # 你为 Amazon S3 Bucket 所创建的逻辑层次结构，例如 `my-bucket-prefix/prod`

AWS 上的连接排空

可以将注解 service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled 设置为 "true" 来管理 ELB 的连接排空。 注解 service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout 也可以用于设置最大时间（以秒为单位），以保持现有连接在注销实例之前保持打开状态。

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
        service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60"

其他 ELB 注解

还有其他一些注解，用于管理经典弹性负载均衡器，如下所述。

    metadata:
      name: my-service
      annotations:
        # 按秒计的时间，表示负载均衡器关闭连接之前连接可以保持空闲
        # （连接上无数据传输）的时间长度
        service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"

        # 指定该负载均衡器上是否启用跨区的负载均衡能力
        service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"

        # 逗号分隔列表值，每一项都是一个键-值耦对，会作为额外的标签记录于 ELB 中
        service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops"

        # 将某后端视为健康、可接收请求之前需要达到的连续成功健康检查次数。
        # 默认为 2，必须介于 2 和 10 之间
        service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""

        # 将某后端视为不健康、不可接收请求之前需要达到的连续不成功健康检查次数。
        # 默认为 6，必须介于 2 和 10 之间
        service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"

        # 对每个实例进行健康检查时，连续两次检查之间的大致间隔秒数
        # 默认为 10，必须介于 5 和 300 之间
        service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"

        # 时长秒数，在此期间没有响应意味着健康检查失败
        # 此值必须小于 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
        # 默认值为 5，必须介于 2 和 60 之间
        service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"

        # 由已有的安全组所构成的列表，可以配置到所创建的 ELB 之上。
        # 与注解 service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 不同，
        # 这一设置会替代掉之前指定给该 ELB 的所有其他安全组，也会覆盖掉为此
        # ELB 所唯一创建的安全组。 
        # 此列表中的第一个安全组 ID 被用来作为决策源，以允许入站流量流入目标工作节点
        # (包括服务流量和健康检查）。
        # 如果多个 ELB 配置了相同的安全组 ID，为工作节点安全组添加的允许规则行只有一个，
        # 这意味着如果你删除了这些 ELB 中的任何一个，都会导致该规则记录被删除，
        # 以至于所有共享该安全组 ID 的其他 ELB 都无法访问该节点。
        # 此注解如果使用不当，会导致跨服务的不可用状况。
        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"

        # 额外的安全组列表，将被添加到所创建的 ELB 之上。
        # 添加时，会保留为 ELB 所专门创建的安全组。
        # 这样会确保每个 ELB 都有一个唯一的安全组 ID 和与之对应的允许规则记录，
        # 允许请求（服务流量和健康检查）发送到目标工作节点。
        # 这里顶一个安全组可以被多个服务共享。
        service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"

        # 用逗号分隔的一个键-值偶对列表，用来为负载均衡器选择目标节点
        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"

AWS 上网络负载均衡器支持

要在 AWS 上使用网络负载均衡器，可以使用注解 service.beta.kubernetes.io/aws-load-balancer-type，将其取值设为 nlb。

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

与经典弹性负载均衡器不同，网络负载均衡器（NLB）将客户端的 IP 地址转发到该节点。 如果服务的 .spec.externalTrafficPolicy 设置为 Cluster ，则客户端的 IP 地址不会传达到最终的 Pod。

通过将 .spec.externalTrafficPolicy 设置为 Local，客户端 IP 地址将传播到最终的 Pod， 但这可能导致流量分配不均。 没有针对特定 LoadBalancer 服务的任何 Pod 的节点将无法通过自动分配的 .spec.healthCheckNodePort 进行 NLB 目标组的运行状况检查，并且不会收到任何流量。

为了获得均衡流量，请使用 DaemonSet 或指定 Pod 反亲和性 使其不在同一节点上。

你还可以将 NLB 服务与内部负载均衡器 注解一起使用。

为了使客户端流量能够到达 NLB 后面的实例，使用以下 IP 规则修改了节点安全组：

为了限制哪些客户端 IP 可以访问网络负载均衡器，请指定 loadBalancerSourceRanges。

spec:
  loadBalancerSourceRanges:
    - "143.231.0.0/16"

有关弹性 IP 注解和更多其他常见用例， 请参阅AWS 负载均衡控制器文档。

腾讯 Kubernetes 引擎（TKE）上的 CLB 注解

以下是在 TKE 上管理云负载均衡器的注解。

    metadata:
      name: my-service
      annotations:
        # 绑定负载均衡器到指定的节点。
        service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)

        # 为已有负载均衡器添加 ID。
        service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx

        # 负载均衡器（LB）的自定义参数尚不支持修改 LB 类型。
        service.kubernetes.io/service.extensiveParameters: ""

        # 自定义负载均衡监听器。
        service.kubernetes.io/service.listenerParameters: ""

        # 指定负载均衡类型。
        # 可用参数: classic (Classic Cloud Load Balancer) 或 application (Application Cloud Load Balancer)
        service.kubernetes.io/loadbalance-type: xxxxx

        # 指定公用网络带宽计费方法。
        # 可用参数: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic) 和 BANDWIDTH_POSTPAID_BY_HOUR (bill-by-bandwidth).
        service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx

        # 指定带宽参数 (取值范围： [1,2000] Mbps).
        service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"

        # 当设置该注解时，负载均衡器将只注册正在运行 Pod 的节点，
        # 否则所有节点将会被注册。
        service.kubernetes.io/local-svc-only-bind-node-with-pod: true

ExternalName 类型

类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择算符，例如 my-service 或者 cassandra。 你可以使用 spec.externalName 参数指定这些服务。

例如，以下 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

当查找主机 my-service.prod.svc.cluster.local 时，集群 DNS 服务返回 CNAME 记录， 其值为 my.database.example.com。 访问 my-service 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。 如果以后你决定将数据库移到集群中，则可以启动其 Pod，添加适当的选择算符或端点以及更改服务的 type。

外部 IP

如果外部的 IP 路由到集群中一个或多个 Node 上，Kubernetes Service 会被暴露给这些 externalIPs。 通过外部 IP（作为目的 IP 地址）进入到集群，打到 Service 的端口上的流量， 将会被路由到 Service 的 Endpoint 上。 externalIPs 不会被 Kubernetes 管理，它属于集群管理员的职责范畴。

根据 Service 的规定，externalIPs 可以同任意的 ServiceType 来一起指定。 在上面的例子中，my-service 可以在 "80.11.12.10:80"(externalIP:port) 上被客户端访问。

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

不足之处

为 VIP 使用用户空间代理，将只适合小型到中型规模的集群，不能够扩展到上千 Service 的大型集群。 查看最初设计方案 获取更多细节。

使用用户空间代理，隐藏了访问 Service 的数据包的源 IP 地址。 这使得一些类型的防火墙无法起作用。 iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址， 但却要求客户端请求必须通过一个负载均衡器或 Node 端口。

Type 字段支持嵌套功能 —— 每一层需要添加到上一层里面。 不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 LoadBalancer 能工作而分配一个 NodePort，但是 AWS 需要 ），但针对服务的 Kubernetes API 设计是强制要求的。

虚拟 IP 实施

对很多想使用 Service 的人来说，前面的信息应该足够了。 然而，有很多内部原理性的内容，还是值去理解的。

避免冲突

Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错的场景。 对于 Service 资源的设计，这意味着如果用户的选择有可能与他人冲突，那就不要让用户自行选择端口号。 这是一个隔离性的失败。

为了使用户能够为他们的 Service 选择一个端口号，我们必须确保不能有 2 个 Service 发生冲突。 Kubernetes 通过在为 API 服务器配置的 service-cluster-ip-range CIDR 范围内为每个服务分配自己的 IP 地址来实现。

为了保证每个 Service 被分配到一个唯一的 IP，需要一个内部的分配器能够原子地更新 etcd 中的一个全局分配映射表， 这个更新操作要先于创建每一个 Service。 为了使 Service 能够获取到 IP，这个映射表对象必须在注册中心存在， 否则创建 Service 将会失败，指示一个 IP 不能被分配。

在控制平面中，一个后台 Controller 的职责是创建映射表 （需要支持从使用了内存锁的 Kubernetes 的旧版本迁移过来）。 同时 Kubernetes 会通过控制器检查不合理的分配（如管理员干预导致的） 以及清理已被分配但不再被任何 Service 使用的 IP 地址。

type: ClusterIP 服务的 IP 地址范围

ServiceIPStaticSubrange 特性门控在 v1.25 及后续版本中默认启用，其分配策略根据配置的 service-cluster-ip-range 的大小，使用以下公式 min(max(16, cidrSize / 16), 256) 进行划分，该公式可描述为 “在不小于 16 且不大于 256 之间有一个步进量（Graduated Step）”，将 ClusterIP 范围分成两段。动态 IP 分配将优先从上半段地址中选择， 从而降低与下半段地址分配的 IP 冲突的风险。 这允许用户将 service-cluster-ip-range 的下半段地址用于他们的服务， 与所分配的静态 IP 的冲突风险非常低。

Service IP 地址

不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。 相反，我们使用 iptables（Linux 中的数据包处理逻辑）来定义一个虚拟 IP 地址（VIP）， 它可以根据需要透明地进行重定向。 当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。 环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。

kube-proxy 支持三种代理模式: 用户空间、iptables 和 IPVS；它们各自的操作略有不同。

Userspace

作为一个例子，考虑前面提到的图片处理应用程序。 当创建后端 Service 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 假设 Service 的端口是 1234，该 Service 会被集群中所有的 kube-proxy 实例观察到。 当代理看到一个新的 Service，它会打开一个新的端口， 建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。

当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 "服务代理" 的端口。 "服务代理" 选择一个后端，并将客户端的流量代理到后端上。

这意味着 Service 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。 客户端可以连接到一个 IP 和端口，而不需要知道实际访问了哪些 Pod。

iptables

再次考虑前面提到的图片处理应用程序。 当创建后端 Service 时，Kubernetes 控制面板会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 假设 Service 的端口是 1234，该 Service 会被集群中所有的 kube-proxy 实例观察到。 当代理看到一个新的 Service， 它会配置一系列的 iptables 规则，从 VIP 重定向到每个 Service 规则。 该特定于服务的规则连接到特定于 Endpoint 的规则，而后者会重定向（目标地址转译）到后端。

当客户端连接到一个 VIP，iptables 规则开始起作用。一个后端会被选择（或者根据会话亲和性，或者随机）， 数据包被重定向到这个后端。 不像用户空间代理，数据包从来不拷贝到用户空间，kube-proxy 不是必须为该 VIP 工作而运行， 并且客户端 IP 是不可更改的。

当流量打到 Node 的端口上，或通过负载均衡器，会执行相同的基本流程， 但是在那些案例中客户端 IP 是可以更改的。

IPVS

在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 IPVS 专为负载均衡而设计，并基于内核内哈希表。 因此，你可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。 同时，基于 IPVS 的 kube-proxy 具有更复杂的负载均衡算法（最小连接、局部性、加权、持久性）。

API 对象

Service 是 Kubernetes REST API 中的顶级资源。你可以找到有关 Service 对象 API 的更多详细信息。

受支持的协议

TCP

你可以将 TCP 用于任何类型的服务，这是默认的网络协议。

UDP

你可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。

SCTP

一旦你使用了支持 SCTP 流量的网络插件，你就可以使用 SCTP 于更多的服务。 对于 type = LoadBalancer 的服务，SCTP 的支持取决于提供此设施的云供应商（大多数不支持）。

警告

支持多宿主 SCTP 关联

Windows

用户空间 kube-proxy

HTTP

如果你的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部 HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。

PROXY 协议

如果你的云提供商支持它， 则可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置负载均衡器， 该负载均衡器将转发前缀为 PROXY 协议 的连接。

负载均衡器将发送一系列初始字节，描述传入的连接，类似于此示例：

PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

上述是来自客户端的数据。

接下来

• 遵循使用 Service 连接到应用教程
• 阅读了解 Ingress
• 阅读了解端点切片（Endpoint Slices）