3. Nginx Ingress 控制器安装:使用 Helm 部署与配置验证

Nginx Ingress Controller 是 Kubernetes 生态中最广泛使用的 Ingress 实现之一。本章将使用 Helm 包管理器完成部署,并深入解析核心配置参数,最后通过多种手段验证安装状态。Helm 方式相比手动 YAML 部署,具备版本管理、参数化配置、一键升级/回滚等优势,是生产环境推荐方案。

3.1 前置条件与 Helm 仓库准备

在开始部署前,请确保集群满足以下条件:

  • Kubernetes 集群:版本 ≥ 1.19,且集群 DNS(CoreDNS)正常运行。
  • Helm 客户端:版本 ≥ 3.8.0,已初始化并具备集群管理员权限。
  • 网络环境:集群节点可访问 registry.k8s.io 和 github.com 以下载镜像和 Chart。
  • StorageClass(可选):如需为 Controller 挂载持久卷,需提前配置默认 StorageClass。

添加官方 Helm 仓库并更新索引:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
提示:如果网络受限,可先在有公网的环境下载 Chart 包(helm pull ingress-nginx/ingress-nginx),再传输到离线环境使用 helm install 本地路径部署。

3.2 使用 Helm 部署 Nginx Ingress Controller

执行以下命令完成基础部署。命名空间建议使用 ingress-nginx,便于资源隔离和管理。

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.service.type=LoadBalancer \
  --set controller.service.externalTrafficPolicy=Local \
  --set controller.replicaCount=2

部署参数说明:

参数 值 说明
controller.service.type LoadBalancer 对外暴露方式,云环境自动分配公网 IP;本地测试可改为 NodePort
controller.service.externalTrafficPolicy Local 保留客户端源 IP,避免 SNAT 导致日志丢失真实来源
controller.replicaCount 2 高可用部署,生产环境建议 ≥ 2
controller.admissionWebhooks.enabled true(默认) 启用准入 Webhook,校验 Ingress 资源合法性
controller.config.use-forwarded-headers "true" 信任反向代理传递的 X-Forwarded-* 头
注意:如果集群未集成云负载均衡器(如 bare-metal 环境),type=LoadBalancer 会导致 Service 一直处于 Pending 状态。此时应改用 --set controller.service.type=NodePort,并结合外部负载均衡或直接使用节点端口访问。

3.3 核心配置参数详解

Nginx Ingress Controller 的 Helm Chart 提供了超过 200 个可配置参数。以下按功能分类列出生产环境最常用的参数组:

3.3.1 控制器副本与资源

参数路径 推荐值 作用
controller.replicaCount 2~3 Pod 副本数,保证滚动更新不中断
controller.resources.requests.cpu 100m CPU 预留,避免调度到资源不足的节点
controller.resources.requests.memory 256Mi 内存预留,应对突发流量
controller.resources.limits.cpu 500m CPU 上限,防止单 Pod 抢占过多资源
controller.resources.limits.memory 1Gi 内存上限,超出后 OOM Kill

3.3.2 网络与服务暴露

参数路径 推荐值 作用
controller.service.type LoadBalancer / NodePort Service 暴露方式
controller.service.annotations."service.beta.kubernetes.io/aws-load-balancer-type" nlb AWS 环境指定使用 NLB,提升性能
controller.service.nodePorts.http 30080 NodePort 模式下 HTTP 端口映射
controller.service.nodePorts.https 30443 NodePort 模式下 HTTPS 端口映射
controller.hostNetwork false 是否使用主机网络,true 时直接监听宿主机端口

3.3.3 安全与 TLS

参数路径 推荐值 作用
controller.admissionWebhooks.enabled true 启用准入校验,拒绝无效 Ingress 规则
controller.defaultSSLCertificate "" 默认 TLS 证书 Secret 名称,未匹配域名时使用
controller.config.ssl-redirect "true" 自动将 HTTP 请求重定向到 HTTPS
controller.config.hsts "true" 启用 HSTS 头,强制浏览器使用 HTTPS

3.3.4 日志与监控

参数路径 推荐值 作用
controller.config.log-format-escape-json "true" JSON 格式日志,便于日志系统解析
controller.metrics.enabled true 暴露 Prometheus 指标(默认端口 10254)
controller.metrics.serviceMonitor.enabled true 自动创建 ServiceMonitor,对接 Prometheus Operator

3.4 验证安装状态

部署完成后,通过以下步骤逐层验证控制器是否正常工作。

3.4.1 检查 Pod 运行状态

kubectl get pods -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

预期输出:所有 Pod 处于 Running 状态,且 READY 列为 1/1。

3.4.2 检查 Service 与端点

kubectl get svc -n ingress-nginx
kubectl get endpoints -n ingress-nginx

Service 的 EXTERNAL-IP 列应显示负载均衡器 IP(云环境)或 <none>(NodePort 模式)。Endpoints 列表应与 Pod IP 一致。

3.4.3 验证准入 Webhook

kubectl get validatingwebhookconfiguration -l app.kubernetes.io/name=ingress-nginx

确认 Webhook 配置已创建,且 service 引用正确。如果 Webhook 未就绪,创建 Ingress 时会报 Internal error occurred: failed calling webhook。

3.4.4 功能验证:部署测试应用

创建一个简单的 echo 服务与 Ingress 规则,验证流量能否正确路由:

kubectl create deployment echo-server --image=registry.k8s.io/echoserver:1.10
kubectl expose deployment echo-server --port=8080 --target-port=8080

kubectl create ingress echo-ingress \
  --rule="echo.example.com/=echo-server:8080" \
  --annotation nginx.ingress.kubernetes.io/rewrite-target=/

获取 Ingress 控制器对外 IP:

export INGRESS_IP=$(kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -H "Host: echo.example.com" http://$INGRESS_IP

如果返回包含 Hostname: echo-server 的响应,说明 Ingress 控制器安装成功且路由正常。

关键检查点:如果 curl 返回 503 Service Temporarily Unavailable,通常是因为后端 Service 的 targetPort 不匹配或 Pod 尚未就绪。使用 kubectl describe ingress echo-ingress 查看 Events 字段可快速定位问题。

3.5 Nginx Ingress 控制器架构图

下图展示了 Nginx Ingress Controller 在 Kubernetes 集群中的核心组件与流量路径:

Nginx Ingress Controller 架构与流量路径 Nginx Ingress Controller 核心架构 外部用户 Service (LB/NodePort) 端口 80/443 Ingress Controller Nginx 进程 Lua 插件 Ingress 资源 路由规则 后端 Service ClusterIP 后端 Pod (应用) 容器端口 8080 说明: 1. 外部流量通过 Service(LoadBalancer/NodePort)进入 Ingress Controller Pod。 2. Controller 根据 Ingress 资源中的规则匹配 Host/Path,将请求转发到对应的后端 Service。 3. 后端 Service 通过标签选择器将流量分发到实际运行应用的 Pod。

3.6 常见安装问题与排查

现象 可能原因 解决方案
Pod 一直 Pending 节点资源不足,或 PVC 无法绑定 检查节点 CPU/内存;确认 StorageClass 存在且可动态供应
Service 外部 IP 一直 <pending> 云环境未集成 LB,或 metallb 未部署 改用 NodePort 模式,或部署 metallb/云 LB 插件
创建 Ingress 报 Webhook 错误 Admission Webhook 未就绪或证书异常 检查 Webhook Pod 日志;kubectl delete validatingwebhookconfiguration 临时禁用(不推荐生产)
curl 返回 502/503 后端 Service 端口不匹配或 Pod 未启动 确认 targetPort 与容器端口一致;kubectl logs <pod> 查看应用日志
生产建议:部署完成后,立即配置 controller.metrics.enabled=true 并接入 Prometheus + Grafana 监控面板。重点关注 nginx_ingress_controller_requests(请求速率)、nginx_ingress_controller_ingress_upstream_latency_seconds(上游延迟)等指标,为容量规划提供数据支撑。