借助 NGINX 对本地的 Kubernetes 服务进行自动化的 TCP 负载均衡

原文作者：Chris Akker - F5 技术解决方案架构师，Steve Wagner - F5 NGINX 解决方案架构师

原文链接：借助 NGINX 对本地的 Kubernetes 服务进行自动化的 TCP 负载均衡

转载来源：NGINX 中文官网

NGINX 唯一中文官方社区，尽在 nginx.org.cn

作为一名现代应用开发人员，您不仅使用一系列开源工具和一些商业工具来编写、测试、部署及管理新应用和容器，而且还选择了 Kubernetes 在开发、测试、模拟和生产环境中运行这些容器和 pod，并引入了微服务架构和概念、云原生计算基金会及其他现代行业标准。

这一路走来，您发现 Kubernetes 的功能的确很强大，但可能也没想到它如此繁琐、复杂和僵化。实施并协调对路由器、防火墙、负载均衡器及其他网络设备的变更和更新可能会非常困难，尤其是在您自己的数据中心！这足以让开发人员崩溃。

如何应对这些挑战与 Kubernetes 运行位置和方式（作为托管 service 或本地 service）密切相关。本文将介绍 TCP 负载均衡，这是部署选择影响易用性的关键之处。

使用托管 Kubernetes 进行 TCP 负载均衡（所谓的“简易方案”）

如果您使用的是 Kubernetes 公有云提供商等托管 service，那么大部分繁琐的网络工作处理均由其为您代劳。只需一个命令（kubectl apply -f loadbalancer.yaml），Service 类型 LoadBalancer 便会为您提供公共 IP、DNS 记录及 TCP 负载均衡器。例如，您可以配置 Amazon Elastic Load Balancer，以便将流量分配到包含 NGINX Ingress Controller 的 pod。使用此命令，即使后端发生变化，也不必担心。简直太简单了，给人行云流水之感！

使用本地 Kubernetes 进行 TCP 负载均衡（所谓的“复杂方案”）

对于本地集群，情况完全不同。您或您的网络团队同事必须提供网络服务。您可能会想：“为何让用户使用我的 Kubernetes 应用如此困难？”原因很简单，但有些出人意料：没有 service 类型 LoadBalancer（集群的前门）。

若要将应用和 service 暴露在集群外部，您的网络团队可能需要创建工单、获得审批、执行程序乃至进行安全审查 — 然后才能重新配置设备。或者，您可能需要自己搞定一切，进而拖慢了应用交付的速度。更糟糕的是，您不敢对任何 Kubernetes service 进行更改，因为如果 NodePort 发生变化，流量可能会被阻断！我们都知道用户最不希望出现 500 错误，老板可能更是如此。

更好的本地 TCP 负载均衡解决方案：NGINX Loadbalancer for Kubernetes

通过我们的最新免费项目，您可将“复杂方案”变成“简易方案”：这个项目就是 NGINX Loadbalancer for Kubernetes ，它能够监控 NGINX Ingress Controller，并可自动更新专为负载均衡而配置的外部 NGINX Plus 实例。它的设计非常简单，易于安装和操作。有了此解决方案，您便可在本地环境中实现 TCP 负载均衡，确保新应用和 service 能即时被检测到并可接收流量，而无需手动操作。

架构和流程

NGINX Loadbalancer for Kubernetes 位于 Kubernetes 集群内部，已在 Kubernetes 中注册，可监控 nginx-ingress service (NGINX Ingress Controller)。当后端发生变化时，NGINX Loadbalancer for Kubernetes 会收集 worker IP 和 no reload required 端口号，然后通过 NGINX Plus API 将 IP:ports 发送到 NGINX Plus。NGINX 上游服务器无需重新加载即可更新，NGINX Plus 将流量负载均衡到正确的上游服务器和 Kubernetes NodePort。可添加额外的 NGINX Plus 实例来实现高可用性。