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
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-* 头 |
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 控制器安装成功且路由正常。
503 Service Temporarily Unavailable,通常是因为后端 Service 的 targetPort 不匹配或 Pod 尚未就绪。使用 kubectl describe ingress echo-ingress 查看 Events 字段可快速定位问题。
3.5 Nginx Ingress 控制器架构图
下图展示了 Nginx Ingress Controller 在 Kubernetes 集群中的核心组件与流量路径:
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(上游延迟)等指标,为容量规划提供数据支撑。