Kubernetes Ingress 控制器问题排查与最佳实践

1. Ingress 服务暴露的典型问题与排查思路

在 Kubernetes 集群中部署完 Service 后，很多工程师会习惯性地通过 Ingress 来暴露服务。典型的配置就像下面这个 YAML 片段所示：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: demo.example.com http: paths: - path: / pathType: Prefix backend: service: name: web-service port: number: 8080

但实际部署后，执行kubectl get ingress命令时，ADDRESS 字段却显示为空：

NAME CLASS HOSTS ADDRESS PORTS AGE example-ingress <none> demo.example.com 80 5m

这个问题困扰过不少 Kubernetes 使用者。我最初遇到时尝试了各种替代方案：

1. 直接使用 NodePort 类型的 Service 暴露端口
2. 在裸金属服务器上部署独立的负载均衡器（如 HAProxy）
3. 采用应用层网关方案（如 Spring Cloud Gateway）

这些方法虽然可行，但都偏离了 Kubernetes 原生的服务暴露最佳实践。经过多次测试和源码分析，发现问题根源在于 Ingress 控制器的工作机制。

2. Ingress 控制器的工作原理深度解析

2.1 Ingress 与 Ingress Controller 的关系

关键认知误区：很多工程师认为 Ingress 资源本身就能提供外部访问能力，实际上：

• Ingress 只是路由规则的抽象定义
• Ingress Controller 才是实际处理流量的组件
• ADDRESS 字段由 Controller 负责填充

常见的 Controller 实现包括：

• NGINX Ingress Controller
• Traefik
• HAProxy Ingress
• AWS ALB Ingress Controller

2.2 ADDRESS 字段的生成机制

当出现 ADDRESS 为空的情况时，说明：

1. 集群中没有安装任何 Ingress Controller
2. 已安装的 Controller 未能正确运行
3. Controller 与 Ingress 资源之间存在配置隔离

可以通过以下命令验证 Controller 状态：

# 检查 Controller Pod 状态 kubectl get pods -n ingress-nginx # 查看 Controller 日志 kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

3. 完整解决方案与部署实践

3.1 Ingress Controller 安装指南

以最常用的 NGINX Ingress Controller 为例：

# 使用 Helm 安装（推荐） helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace # 验证安装 kubectl get services -n ingress-nginx

安装完成后，ADDRESS 字段通常会在以下情况显示：

• 云环境：自动显示负载均衡器的外部 IP
• 本地集群：显示节点 IP（需额外配置）

3.2 混合环境特殊配置

对于本地开发环境（如 Minikube/Docker Desktop）：

# Minikube 需要启用插件 minikube addons enable ingress # 查看 IP 分配 minikube ip

对于裸金属集群，需要配置外部 IP：

apiVersion: v1 kind: Service metadata: name: ingress-nginx-controller namespace: ingress-nginx spec: externalIPs: - 192.168.1.100 # 物理节点IP ports: - name: http port: 80 targetPort: 80

3.3 服务发现机制详解

Ingress Controller 通过以下流程关联 Ingress 资源：

1. 监听 API Server 的 Ingress 资源变更
2. 验证后端 Service 是否存在且健康
3. 生成对应的负载均衡配置（如 NGINX conf）
4. 更新状态字段（包括 ADDRESS）

可以通过以下命令检查关联状态：

kubectl describe ingress example-ingress

在 Events 部分会显示配置应用的详细过程。

4. 高级调试技巧与常见问题排查

4.1 诊断流程图

当 ADDRESS 为空时，建议按照以下流程排查：

检查 Controller 是否安装 → 验证 Pod 运行状态 → 检查 Service 配置 → 查看控制器日志 → 检查网络策略 → 验证服务端点(Endpoint)

4.2 典型问题案例库

案例1：控制器安装但未指定 IngressClass

# 解决方案：添加注解 metadata: annotations: kubernetes.io/ingress.class: "nginx"

案例2：Service 端口不匹配

# Ingress 配置的端口必须与 Service 的 port 对应 # 错误示例： spec: rules: - http: paths: - backend: service: name: web-service port: number: 80 # 但 Service 实际暴露的是 8080

案例3：网络策略阻断

# 需要允许 ingress 命名空间访问应用 kind: NetworkPolicy spec: ingress: - from: - namespaceSelector: matchLabels: name: ingress-nginx

4.3 性能优化建议

对于生产环境：

1. 启用控制器就绪检查：

spec: template: spec: containers: - name: controller readinessProbe: httpGet: path: /healthz port: 10254

2. 调整工作进程数量：

args: - --worker-processes=4 # 根据 CPU 核心数调整

3. 启用动态配置重载：

annotations: nginx.ingress.kubernetes.io/config-backend: lua

5. 架构设计思考与替代方案对比

5.1 Ingress 方案的适用场景

最适合使用 Ingress 的情况：

• 需要基于主机名/路径的路由
• 统一管理 TLS 证书
• 多个服务共享公网 IP
• 需要标准化的七层流量管理

5.2 与其他方案的对比分析

方案	优点	缺点	适用场景
Ingress + Controller	原生支持、功能丰富	需要额外组件	生产环境、多服务
NodePort	简单直接	端口管理复杂	开发测试、临时方案
LoadBalancer	云服务商集成度高	成本高、厂商锁定	云环境单一服务
Service Mesh	细粒度流量控制	复杂度高、资源消耗大	大规模微服务架构

5.3 现代 Ingress 的发展趋势

1. Gateway API 的演进：

# Gateway API 示例 apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute spec: parentRefs: - name: example-gateway rules: - matches: - path: type: PathPrefix value: /shop backendRefs: - name: shop-service port: 8080

2. 多协议支持（如 gRPC、WebSocket）
3. 与服务网格的集成（如 Istio Ingress）

6. 生产环境最佳实践

6.1 安全加固方案

1. TLS 配置优化：

annotations: nginx.ingress.kubernetes.io/ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256" nginx.ingress.kubernetes.io/ssl-protocols: "TLSv1.2 TLSv1.3"

2. 防 DDoS 配置：

annotations: nginx.ingress.kubernetes.io/limit-connections: 100 nginx.ingress.kubernetes.io/limit-rps: 50

3. 审计日志配置：

spec: containers: - args: - --audit-log-path=/var/log/nginx/audit.log - --audit-log-maxsize=100

6.2 高可用部署模式

推荐的多副本部署配置：

spec: replicas: 3 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 topologySpreadConstraints: - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: ScheduleAnyway

6.3 监控与告警配置

Prometheus 监控示例：

annotations: prometheus.io/scrape: "true" prometheus.io/port: "10254"

关键监控指标：

• nginx_ingress_controller_requests
• nginx_ingress_controller_connections
• nginx_ingress_controller_config_hash

7. 个人实战经验总结

在多个生产集群的部署实践中，有几个特别容易忽视的细节：

1. 控制器版本匹配：Ingress 资源的 apiVersion 必须与控制器版本兼容。曾经因为使用 networking.k8s.io/v1 而控制器只支持 extensions/v1beta1 导致配置不生效。

2. 默认后端配置：建议显式配置默认后端，避免暴露集群信息：

spec: defaultBackend: service: name: default-404 port: number: 80

3. 优雅终止配置：确保控制器能正确处理终止信号：

spec: template: spec: terminationGracePeriodSeconds: 300 containers: - name: controller lifecycle: preStop: exec: command: ["/wait-shutdown"]

4. 资源限制建议：根据流量预估设置合理限制：

resources: limits: cpu: 2000m memory: 1Gi requests: cpu: 100m memory: 128Mi

最后分享一个实用的小技巧：可以通过以下命令快速验证 Ingress 配置是否正确解析：

kubectl get ingress -o yaml | grep -A5 'spec:'