K8s 中 Ingress-Nginx 结合负载均衡器（Ingress nginx combined with load balancer）

K8s 中 Ingress-Nginx 结合负载均衡器（LB）的部署全解析

在 K8s的世界里，有效地管理和路由进入集群的外部流量是至关重要的。Ingress-Nginx 作为一款强大的 Ingress 控制器，搭配负载均衡器（LB），可以为我们的应用服务提供高效、灵活且可靠的流量接入和分发机制。本章详细介绍如何在 K8s 环境中部署 Ingress-Nginx 并结合 LB 发挥其强大功能。

一、Ingress 与 Ingress-Nginx 概述

（一）什么是 Ingress

Ingress 是 K8s 中的一个 API 对象，它的核心作用在于将集群外部的 HTTP 和 HTTPS 流量路由到集群内部的不同服务上。简单来说，它就像是集群对外的“大门”和“交通指挥员”，能够根据配置的规则，把请求精准地引导到对应的后端服务实例中，避免了我们为每个服务都单独去配置外部访问方式的繁琐操作。

（二）Ingress-Nginx 的优势

Ingress-Nginx 则是众多 Ingress 控制器实现中的佼佼者。它基于 Nginx 服务器构建，Nginx 本身就有着高性能、高并发处理能力以及丰富的功能模块等优势。Ingress-Nginx 继承了这些优点，并且与 K8s 生态深度集成，可以方便地通过配置 Ingress 资源来动态地更新 Nginx 的路由规则，轻松应对复杂多变的业务场景，例如实现基于域名、路径等多维度的流量路由策略。

二、负载均衡器（LB）在 K8s 中的作用

（一）负载均衡的基本概念

在分布式系统中，尤其是像 K8s 这样的容器编排平台里，往往会有多个相同服务的副本在运行，以提高系统的可用性和处理能力。负载均衡器（LB）的任务就是将进入的客户端请求合理地分配到这些后端的服务副本上，避免某个副本负载过重而其他副本闲置的情况，从而优化整个系统资源的利用效率，提升服务的响应速度和稳定性。

（二）LB 类型及选择

在 K8s 环境中，常见的负载均衡器类型有多种，比如云服务商提供的云负载均衡器（例如阿里云的 SLB、腾讯云的 CLB 等），这类负载均衡器依托云平台强大的资源和功能，能够无缝对接 K8s 集群，并且提供诸如健康检查、自动扩缩容等高级特性；还有软件定义的负载均衡器（像 MetalLB 等），适用于在没有云服务商原生 LB 支持的自建数据中心等环境下，通过软件配置来模拟实现类似云 LB 的功能。我们需要根据自身的部署环境、成本预算以及业务需求等来选择合适的负载均衡器。

三、部署前的准备工作

（一）K8s 集群环境搭建

首先，自然是要有一个正常运行的 Kubernetes 集群啦。可以通过诸如 kubeadm、Minikube 等工具来搭建不同规模和用途的集群。确保集群的各个节点状态正常，网络通信顺畅，K8s 的核心组件（如 API Server、Controller Manager、Scheduler、kubelet 等）都稳定运行，这是后续部署 Ingress-Nginx 和配置 LB 的基础前提。

（二）确定负载均衡器选型及配置

根据前面提到的原则选定了具体的负载均衡器后，要按照相应的文档说明进行基础配置。例如使用云负载均衡器时，需要在云平台控制台创建对应的负载均衡实例，配置监听端口（一般对于 HTTP 和 HTTPS 流量常用的 80、443 端口等），设置后端服务的关联规则等；若是采用软件定义的 LB，则要安装和配置相应的软件组件，使其能够与 K8s 集群进行有效的交互。

（三）安装必要的命令行工具和插件

我们还需要安装一些在部署过程中会用到的命令行工具，比如 kubectl，它可是操作 K8s 集群的得力助手，通过它可以创建、修改、删除各种 K8s 资源对象。另外，如果选择的是特定的 Ingress-Nginx 版本或者有相关依赖的插件（比如用于自动配置证书的 Cert-Manager 插件等，在处理 HTTPS 流量时可能会用到），也要提前进行安装和配置妥当。

四、部署 Ingress-Nginx

（一）获取 Ingress-Nginx 部署文件

Ingress-Nginx 官方提供了多种方式来获取部署所需的文件，常见的是通过 helm 包管理器或者直接下载官方提供的 YAML 配置文件模板。

• 使用 helm 方式：首先需要安装 helm 工具（如果还未安装的话），然后添加 Ingress-Nginx 的 helm 仓库，例如执行如下命令：

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

接着就可以通过 helm 命令来安装 Ingress-Nginx 了，比如使用默认配置安装的命令大致如下：

helm install ingress-nginx ingress-nginx/ingress-nginx

• 使用 YAML 文件方式：可以从 Ingress-Nginx 官方 GitHub 仓库（https://github.com/kubernetes/ingress-nginx）下载对应的部署 YAML 文件，一般会有包含不同资源对象（如 Deployment、Service、ConfigMap 等）配置的多个文件。下载好后，使用 kubectl 依次应用这些文件来部署 Ingress-Nginx，例如：

kubectl apply -f <namespace>-ingress-nginx-deployment.yaml
kubectl apply -f <namespace>-ingress-nginx-service.yaml
kubectl apply -f <namespace>-ingress-nginx-configmap.yaml

（这里的要替换为实际计划部署的命名空间名称，若采用默认命名空间则可省略此项）

（二）配置 Ingress-Nginx 参数

部署好基础的 Ingress-Nginx 后，往往还需要根据实际业务情况对其进行参数配置。例如，通过修改 ConfigMap 资源对象来调整 Nginx 的一些基础设置，像缓存策略、超时时间、日志格式等内容。以下是一个简单的修改 ConfigMap 中日志格式的示例操作：

首先，获取当前 Ingress-Nginx 的 ConfigMap 内容：

kubectl get configmap <ingress-nginx-configmap-name> -o yaml

（这里的是实际部署后的 ConfigMap 名称，可以通过查看之前部署的资源来确定）

然后在获取到的 YAML 文件内容中找到对应日志格式相关的配置字段，进行修改，比如将日志格式修改为包含更多详细信息的格式，修改完成后再使用 kubectl 应用更新后的 ConfigMap：

kubectl apply -f updated-configmap.yaml

这样就能让 Ingress-Nginx 按照新的配置来运行了。

五、将负载均衡器（LB）与 Ingress-Nginx 集成

（一）配置 LB 指向 Ingress-Nginx 服务

不同类型的负载均衡器有不同的配置方式来关联到 Ingress-Nginx 的服务。

• 对于云负载均衡器来说，在云平台控制台中，需要将负载均衡实例的后端服务设置为指向 Ingress-Nginx 对应的 Service 资源。一般会根据 Ingress-Nginx 服务暴露的端口（通常是 80 和/或 443 端口）以及所在的命名空间等信息进行准确关联，同时配置好健康检查机制，让 LB 能够实时监测 Ingress-Nginx 服务的健康状态，确保只将流量转发到可用的实例上。
• 如果是使用软件定义的负载均衡器（如 MetalLB），则要通过其自身的配置文件或者命令行参数等方式，指定将外部流量转发到 Ingress-Nginx 服务所在的节点和端口上。例如 MetalLB 可能需要配置 IP 地址池，并将这些 IP 分配给 Ingress-Nginx 的服务，使其能够接收来自外部网络的请求。

（二）验证集成效果

配置完成后，我们要进行一系列的验证操作来确保 LB 和 Ingress-Nginx 集成成功并且流量能够正确路由。

• 首先，可以通过查看 LB 的监控数据或者状态页面（云 LB 一般在云平台控制台有相应展示，软件 LB 也会有自己的状态查看方式），确认是否有流量进入并且成功转发到 Ingress-Nginx 服务，查看请求的数量、成功率等指标是否符合预期。
• 然后，在集群内部创建一些简单的测试服务和对应的 Ingress 资源，定义好基于域名、路径等的路由规则，尝试从集群外部通过 LB 的公开发布地址访问这些测试服务，查看是否能够按照配置准确地访问到对应的后端服务内容。例如，创建一个简单的 nginx 示例服务，配置 Ingress 规则将 /testpath 路径的请求路由到该 nginx 服务，通过在浏览器中输入 http:///testpath（这里的是负载均衡器对外的访问地址），看是否能正确返回 nginx 的默认页面，如果能，则说明整体的集成和路由配置是有效的。

六、基于 Ingress-Nginx 和 LB 的流量路由策略配置

（一）基于域名的路由

在实际业务中，往往有多个不同的域名对应不同的业务应用。通过 Ingress-Nginx 结合 LB，我们可以轻松实现基于域名的流量路由。例如，我们有 app1.example.com 和 app2.example.com 两个域名，分别对应两个不同的后端服务 service1 和 service2。我们可以在 Ingress 资源配置中如下设置：

apiVersion:networking.k8s.io/v1
kind:Ingress
metadata:
name:domain-based-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target:/
spec:
rules:
-host:app1.example.com
http:
paths:
-path:/
backend:
service:
name:service1
port:
number:80
-host:app2.example.com
http:
paths:
-path:/
backend:
service:
name:service2
port:
number:80

这样，当外部用户通过浏览器访问 app1.example.com 时，LB 会将请求转发到 Ingress-Nginx，Ingress-Nginx 再依据配置将请求路由到 service1 服务；同理，访问 app2.example.com 会路由到 service2 服务。

（二）基于路径的路由

有时候，我们希望在同一个域名下，根据不同的路径来访问不同的服务，这也是完全可以实现的。比如对于 example.com 域名，我们想让 /api 路径的请求访问后端的 API 服务，/web 路径的请求访问前端网页服务。配置示例如下：

apiVersion:networking.k8s.io/v1
kind:Ingress
metadata:
name:path-based-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target:/$2
spec:
rules:
-host:example.com
http:
paths:
-path:/api(/|$)(.*)
backend:
service:
name:api-service
port:
number:80
-path:/web(/|$)(.*)
backend:
service:
name:web-service
port:
number:80

通过这样的配置，Ingress-Nginx 就能根据请求路径的不同，准确地将流量分发到对应的后端服务上了，再借助 LB 的负载均衡能力，保证服务的高效运行。

七、常见问题及解决办法

（一）Ingress-Nginx 无法启动或频繁重启

• 可能原因：配置文件错误，比如 ConfigMap 中的某些参数设置不符合要求导致 Nginx 启动失败；资源不足，所在节点的 CPU、内存等资源不够支撑 Ingress-Nginx 的运行；镜像拉取问题，可能是无法正常从镜像仓库拉取到 Ingress-Nginx 所需的镜像。
• 解决办法：仔细检查配置文件，对照官方文档核对各个参数设置是否正确，特别是一些关键的 Nginx 配置参数；查看节点资源使用情况，适当增加节点资源或者调整 Ingress-Nginx 的资源请求和限制配置；排查镜像拉取问题，检查网络连接是否正常，镜像仓库的权限是否正确等。

（二）LB 转发的流量无法正确路由到后端服务

• 可能原因：LB 与 Ingress-Nginx 服务的关联配置有误，没有准确地将流量指向 Ingress-Nginx 的对应端口和服务实例；Ingress 资源的路由规则配置错误，导致 Ingress-Nginx 按照错误的规则处理请求，无法找到正确的后端服务；网络策略限制，集群内部可能存在网络策略限制了从 Ingress-Nginx 到后端服务的流量传输。
• 解决办法：重新核对 LB 与 Ingress-Nginx 的关联配置，确保端口、IP 等信息准确无误；检查并修正 Ingress 资源的路由规则配置，通过 kubectl 查看 Ingress 资源的详细状态以及日志信息来排查问题；检查集群网络策略，根据需要适当放宽对相关流量的限制，确保从 Ingress-Nginx 到后端服务的网络通路顺畅。

八、总结与展望

通过以上详细的步骤，我们成功地在 K8s 集群中部署了 Ingress-Nginx 并结合负载均衡器（LB）实现了高效灵活的外部流量管理和路由功能。这一组合在实际的生产环境中有着广泛的应用，可以满足各种复杂的业务需求，无论是多域名、多服务的复杂架构，还是应对高并发的流量场景，都能发挥重要作用。

随着 Kubernetes 生态的不断发展以及业务需求的持续变化，Ingress-Nginx 和 LB 的功能也在不断完善和扩展，比如在安全性方面进一步强化（更好的 HTTPS 支持、认证授权机制等），在性能优化上持续迭代（更高的并发处理能力、更低的延迟等）。我们需要不断学习和跟进这些新技术、新特性，以便更好地利用它们为我们的应用服务保驾护航，构建更加稳定、高效的云原生架构。