借助 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 实例来实现高可用性。
NGINX Loadbalancer for Kubernetes 用例快照
下面截图中的两个窗口展示了 NGINX Loadbalancer for Kubernetes 已部署完毕并正执行其作业:
-
service 类型 – LoadBalancer(适用于
nginx-ingress
) -
外部 IP – 连接到 NGINX Plus 服务器
-
端口 – NodePort 映射到 443:30158 及匹配的 NGINX 上游服务器(如 NGINX Plus 实时仪表盘所示)
-
日志 – 表示 NGINX Loadbalancer for Kubernetes 成功地将数据发送到 NGINX Plus
注:在本例中,Kubernetes worker 节点为 10.1.1.8 和 10.1.1.10
立即试用
如果您正苦于无法应对 Kubernetes 集群边缘的网络挑战,不妨试试该项目,并分享一下您的感想。NGINX Loadbalancer for Kubernetes 的源代码是开源代码(使用 Apache 2.0 许可),所有安装说明均可在 GitHub 上获得。
如需提供反馈,请在仓库中给我们留言,或在 NGINX Community Slack 上向我们发送消息。或者请微信添加小N助手(微信号:nginxoss)加入官方微信群,与社区用户交流探讨。
NGINX 唯一中文官方社区 ,尽在 nginx.org.cn

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Arm 旗下开源物联网项目 Mbed 将于 2026 年 7 月结束生命周期
Mbed 是一个平台和操作系统,用于基于 32-bit ARM Cortex-M 微控制器的连接互联网的设备。该项目由 Arm 和它的技术伙伴协作开发。 近日 Mbed 团队发布公告,称Mbed 平台和操作系统将于 2026 年 7 月结束生命周期: Mbed 平台和操作系统将于 2026 年 7 月终止生命周期,届时 Mbed 网站将被存档,并且将无法再在我们的在线工具中构建项目。 设备软件 Mbed OS 是开源的,将继续公开提供,但不再由 Arm 主动维护。 Mbed TLS 项目不受此公告的影响,并将继续作为TrustedFirmware社区项目的一部分获得支持。 公告还写道,自 2009 年以来,Mbed 一直是一个非常受欢迎的项目,帮助专业开发者、教育用户和创客社区基于 Arm 的硬件创建、保护、部署和更新数千个应用。 与此同时,Arm 支持的项目(如 micro:bit、Arduino 和 Raspberry Pi)在教育环境和创客社区中获得了发展势头,使得 Mbed 提供的许多功能变得更加广泛和易于访问。官方认为,现在更广泛的生态系统可以最好地满足这些需求,而无需 Ar...
- 下一篇
细说 MySQL 死锁(1)准备工作
死锁检查线程,检查并解决死锁,分为三步走,这期先聊聊准备工作:构造锁等待图、初始化事务权重。 > 作者:操盛春,爱可生技术专家,公众号『一树一溪』作者,专注于研究 MySQL 和 OceanBase 源码。 > >爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 > 本文基于 MySQL 8.0.32 源码,存储引擎为 InnoDB。 1. 模拟死锁 创建测试表: CREATE TABLE `t1` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `i1` int DEFAULT '0', PRIMARY KEY (`id`) USING BTREE, KEY `idx_i1` (`i1`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3; 插入测试数据: INSERT INTO `t1` (`id`, `i1`) VALUES (10, 101), (20, 201), (30, 301), (40, 401); 创建 4 个连接,按以下顺序执行示例 SQL:...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS关闭SELinux安全模块
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS8编译安装MySQL8.0.19
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7,8上快速安装Gitea,搭建Git服务器