IBM Cloud Docs
经典：关于网络负载均衡器 (NLB)

经典：关于网络负载均衡器 (NLB)

网络负载均衡器只能在经典集群中创建。 要在 VPC 集群中进行负载均衡，请参阅使用 VPC 负载均衡器公开应用程序。

创建标准集群时，IBM Cloud® Kubernetes Service 会自动供应可移植公用子网和可移植专用子网。

  • 可移植公共子网提供 5 可用 IP 地址。1 可移植公共 IP 地址由缺省 public Ingress ALB 使用。 剩余 4 个可移植公共 IP 地址可用于通过创建公共网络负载均衡器 (NLB) 服务向因特网公开单个应用程序。
  • 可移植专用子网提供 5 个可用 IP 地址。1 可移植专用 IP 地址由缺省专用 Ingress ALB 使用。 剩余 4 个可移植专用 IP 地址可用于通过创建专用网络负载均衡器 (NLB) 服务向专用网络公开单个应用程序。

要使应用程序可通过可移植的公共 IP 地址和可移植的专用 IP 地址进行访问，您必须创建公共 NLB 和专用 NLB。 可移动的公共和私有IP地址是静态浮动IP，当工作节点被移除时不会改变。 如果NLB IP地址所在的节点被移除，持续监控该IP的Keepalive守护进程会自动将该IP移至另一个工作节点。 您可以为 NLB 分配任何端口。 NLB 充当应用程序入局请求的外部入口点。 要从互联网访问NLB，您可以使用NLB的公共IP地址和分配的端口，格式为 <IP_address>:<port>。 还可以通过向子域注册 NLB IP 地址，为 NLB 创建 DNS 条目。

使用 NLB 服务公开应用程序时，该应用程序还会自动通过服务的 NodePort 可用。 在集群内的每个工作程序节点的每个公共和专用 IP 地址上都可以访问 NodePort。 要在使用 NLB 时阻止流至 NodePort 的流量，请参阅控制流至网络负载均衡器 (NLB) 或 NodePort 服务的入站流量。

虽然 Kubernetes SCTP 协议 在 Kubernetes 社区发行版中通常可用，但在 IBM Cloud Kubernetes Service 集群中不支持创建使用此协议的负载均衡器。

V1.0 和 V2.0 NLB 中基本负载均衡和 DSR 负载均衡的比较

创建 NLB 时，可以选择 V1.0 NLB（执行基本负载均衡）或 V2.0 NLB（执行直接服务器返回 (DSR) 负载均衡）。

版本 1.0 和 2.0 NLB有哪些相似之处？
V1.0 和 V2.0 NLB 都是在 Linux 内核空间中存在的第 4 层负载均衡器。 这两个版本都在集群内运行，并使用工作程序节点资源。 因此，NLB 的可用容量始终专用于您自己的集群。 此外，两种版本的NLB都不会终止连接。 而是会将连接转发到应用程序 pod。
版本 1.0 和 2.0 NLB有何不同？
客户机向应用程序发送请求时，NLB 会将请求包路由到应用程序 pod 所在的工作程序节点 IP 地址。 V1.0 NLB 会使用网络地址转换 (NAT) 将请求包的源 IP 地址重写为负载均衡器 pod 所在的工作程序节点的 IP。 在工作程序节点返回应用程序响应包时，会使用 NLB 所在的工作程序节点 IP。 然后，NLB 必须将响应包发送到客户机。 为了防止重写 IP 地址，您可以启用源 IP 保留。 但是，源 IP 保留需要负载均衡器 pod 和应用程序 pod 在同一工作程序上运行，这样请求就不必转发给其他工作程序。 为此，您必须向应用程序 pod 添加节点亲缘关系和容忍度。 有关使用 V1.0 NLB 进行基本负载均衡的更多信息，请参阅 NLB 1.0 的组件和体系结构。

与 V1.0 NLB 不同，V2.0 NLB 在将请求转发到其他工作程序上的应用程序 pod 时不会使用 NAT。 NLB 2.0 路由客户机请求时，会使用 IP-over-IP (IPIP) 将原始请求包封装到另一个包中。 此封装的 IPIP 包具有负载均衡器 pod 所在的工作程序节点的源 IP，这允许原始请求包保留客户机 IP 作为其源 IP 地址。 然后，工作程序节点使用直接服务器返回 (DSR) 将应用程序响应包发送到客户机 IP。 响应包会跳过 NLB 而直接发送到客户机，从而减少了 NLB 必须处理的流量。 有关使用版本 2.0 NLB的DSR负载均衡的更多信息，请参阅 NLB的组件和架构 2.0。

NLB 1.0 的组件和体系结构

TCP/UDP 网络负载均衡器 (NLB) 1.0 使用 Iptables（Linux 内核功能）在应用程序的各 pod 中对请求进行负载均衡。

单专区集群中的流量流

下图显示 NLB 1.0 如何将来自因特网的通信定向到单专区集群中的应用程序。

使用 NLB 1.0在单专区集群中公开应用程序。
Expose an app in a single-zone cluster by using an NLB 1.0

  1. 发送到应用程序的请求使用 NLB 的公共 IP 地址和工作程序节点上分配的端口。 请注意，如果为 NLB 创建 DNS 子域，那么用户可以改为通过 NLB 的子域来访问应用程序。 DNS 系统服务会将子域解析为 NLB 的可移植公共 IP 地址。

  2. NLB 收到请求，并通过专用网络将其转发到应用程序 pod 的专用 IP 地址。 请求数据包的源IP地址被更改为NLB pod运行的工作节点的公共IP地址。 如果集群中部署了多个应用程序实例，那么 NLB 会在应用程序 pod 之间路由请求。

  3. 应用程序返回响应包时，会使用转发客户机请求的 NLB 所在的工作程序节点的 IP 地址。 然后，NLB 会将响应包发送到客户机。

多专区集群中的流量流

下图显示网络负载均衡器 (NLB) 1.0 如何将来自因特网的通信定向到多专区集群中的应用程序。

使用 NLB1.0在多区群集中对应用程序进行负载平衡*
NLB1.0在多区群集中对应用程序进行负载平衡* 使用 NLB * 在多区群
对应用程序进行负载平衡

  1. 对应用程序的请求使用 NLB 的 DNS 子域。 您还可以使用工作程序节点上的公共 IP 地址和端口来访问每个专区中的 NLB。 请注意，缺省情况下，每个 NLB 1.0 仅在一个专区中设置。 要实现高可用性，必须在具有应用程序实例的每个专区中部署一个 NLB 1.0。

  2. DNS 系统服务会将子域解析为工作程序节点上其中一个 NLB 的可移植公共 IP 地址及其分配的端口。 请求会由各个专区中的 NLB 循环处理。

  3. NLB 收到请求，并通过专用网络将其转发到应用程序 pod 的专用 IP 地址。 请求数据包的源IP地址被更改为NLB pod运行的工作节点的公共IP地址。 每个 NLB 都会将请求路由到其自己的专区中的应用程序实例以及其他专区中的应用程序实例。 此外，如果一个专区中部署了多个应用程序实例，那么 NLB 会在该专区的应用程序 pod 之间路由请求。

  4. 应用程序返回响应包时，会使用转发客户机请求的 NLB 所在的工作程序节点的 IP 地址。 然后，NLB 会将响应包发送到客户机。

NLB的组件和架构 2.0

NLB 2.0 是使用 Linux 内核的 IP 虚拟服务器 (IPVS) 的第 4 层负载均衡器。 NLB 2.0 支持 TCP 和 UDP，可在多个工作程序节点前端运行，并使用 IP-over-IP (IPIP) 隧道在这些工作程序节点之间分发到达单个 NLB IP 地址的流量。

单专区集群中的流量流

下图显示 NLB 2.0 如何将来自因特网的通信定向到单专区集群中的应用程序。

Expose an app in IBM Cloud Kubernetes Service by using a version 2.0 NLB
Expose an app in IBM Cloud Kubernetes Service by using a version 2.0 NLB

  1. 发送到应用程序的客户机请求使用 NLB 的公共 IP 地址和工作程序节点上分配的端口。 在此示例中，NLB 具有虚拟 IP 地址 169.61.23.130，并且在具有专用 IP 地址 10.73.13.25 的工作程序节点上运行。 请注意，如果为 NLB 创建 DNS 子域，那么用户可以改为通过 NLB 的子域来访问应用程序。 DNS 系统服务会将子域解析为 NLB 的可移植公共 IP 地址。

  2. NLB 将客户机请求包（在图中标注为“CR”）封装在 IPIP 包（标注为“IPIP”）内。 客户机请求包保留客户机 IP 作为其源 IP 地址。 IPIP 封装包使用工作程序节点 IP 10.73.14.25 作为其源 IP 地址。

  3. NLB 将 IPIP 包路由到应用程序 pod 所在的具有专用 IP 地址 10.73.13.26 的工作程序。 如果集群中部署了多个应用程序实例，那么 NLB 会在部署了应用程序 pod 的工作程序之间路由请求。

  4. 工作程序 10.73.14.26 对 IPIP 封装包解包，然后对客户机请求包解包。 客户机请求包会转发到该工作程序节点上的应用程序 pod。

  5. 然后，工作程序 10.73.14.26 使用原始请求包中的源 IP 地址（即客户机 IP），将应用程序 pod 的响应包直接返回给客户机。

多专区集群中的流量流

下图显示每个专区中的 V2.0 NLB 如何将来自因特网的流量定向到多专区集群中的应用程序。

Expose an app in IBM Cloud Kubernetes Service by using an NLB 2.0
Expose an app in IBM Cloud Kubernetes Service by using an NLB 2.0

  1. 对应用程序的请求使用 NLB 的 DNS 子域。 您还可以使用工作程序节点上的公共 IP 地址和端口来访问每个专区中的 NLB。 请注意，缺省情况下，每个 NLB 2.0 仅在一个专区中设置。 要实现高可用性，必须在具有应用程序实例的每个专区中部署一个 NLB 2.0。

  2. DNS 系统服务会将子域解析为工作程序节点上其中一个 NLB 的可移植公共 IP 地址及其分配的端口。 在此示例中，NLB 具有虚拟 IP 地址 169.61.23.130，并且在具有专用 IP 地址 10.73.13.25 的工作程序节点上运行。 请求会由各个专区中的 NLB 循环处理。

  3. NLB 将客户机请求包（在图中标注为“CR”）封装在 IPIP 包（标注为“IPIP”）内。 客户机请求包保留客户机 IP 作为其源 IP 地址。 IPIP 封装包使用工作程序 10.73.14.25 IP 作为其源 IP 地址。

  4. NLB 将 IPIP 包路由到应用程序 pod 所在的具有专用 IP 地址 10.73.13.26 的工作程序。 请注意，每个 NLB 都会将请求路由到其自己的专区中的应用程序实例以及其他专区中的应用程序实例。 此外，如果一个专区中部署了多个应用程序实例，那么 NLB 会在该专区的应用程序 pod 之间路由请求。

  5. 工作程序 10.73.14.26 对 IPIP 封装包解包，然后对客户机请求包解包。 客户机请求包会转发到该工作程序节点上的应用程序 pod。

  6. 然后，工作程序 10.73.14.26 使用原始请求包中的源 IP 地址（即客户机 IP），将应用程序 pod 的响应包直接返回给客户机。