在 Kubernetes 微服务架构中，优先选择 Kubernetes Ingress（通常配合 Nginx Ingress Controller），而不是手动维护独立的 Nginx 反向代理。

核心概念与关系

Nginx 本身是一款高性能的 HTTP 服务器和反向代理工具，而 Kubernetes Ingress 是一种 API 对象，用来定义进入集群的流量路径。两者不是对立关系，而是协作关系。Nginx Ingress Controller 是将 Nginx 与 Kubernetes 集成的组件，它是 Ingress 规则的“执行者”。

用户通过 YAML 文件定义 Ingress 资源，Controller 监听并解析该规则，自动生成对应的 Nginx 配置（如 server 块、location 路由规则），Nginx 进程再根据生成的配置将外部流量转发到集群内的目标服务。相比独立部署 Nginx 需要手动修改配置文件并 reload，Ingress 方案能结合 Kubernetes 的声明式配置与 Nginx 的实际流量处理能力，实现动态更新。

实操：Kubernetes Ingress 配置流程

以下是基于 Ingress 方案的标准配置流程，包含具体命令与配置示例：

1. 准备后端服务
确保你的应用已经部署，并暴露为 ClusterIP 类型的 Service。ClusterIP 为 Pod 提供稳定的虚拟 IP，仅限集群内部访问。

apiVersion: v1
kind: Service
metadata:
  name: web-service
  namespace: default
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

2. 定义 Ingress 规则
编写 Ingress 资源 YAML，指定域名、路径和后端 Service。例如将 example.com 的流量转发到 web-service 的 80 端口。

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

3. 应用配置
使用 kubectl 命令应用上述配置：

kubectl apply -f service.yaml
kubectl apply -f ingress.yaml

4. 获取入口 IP
查看 Ingress 资源状态，确认 ADDRESS 字段已获取到外部 IP：

kubectl get ingress web-ingress -n default

若 ADDRESS 显示为 pending，检查 Ingress Controller 是否已正确部署并拥有负载均衡器支持。

对比：独立 Nginx 反向代理配置

若不使用 Ingress，需在集群外独立部署 Nginx，并手动维护 upstream 和 server 配置。

Nginx 配置片段示例：

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://<K8s_Node_IP>:<NodePort>;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

主要差异：

• 域名路由：独立 Nginx 虽可通过 server_name 实现域名路由，但需手动修改配置并 reload，无法像 Ingress 那样动态感知 K8s 服务变化。
• 服务发现：独立 Nginx 需要配合服务发现工具（如 consul）才能感知后端变化，而 Ingress Controller 通过与 kube-apiserver 交互实时感知后端 Service、Pod 的变化。
• 维护成本：每次有新服务加入时，独立 Nginx 需手动更改配置或滚动更新前端 Nginx Pod，Ingress 仅需应用 YAML 文件。

验证与故障排查

配置完成后，可以通过以下方式确认流量是否按预期路由：

1. curl 测试
在集群外部使用 curl 命令访问配置的域名，检查是否返回后端服务响应。若 DNS 未解析，可通过 Host 头指定：

curl -v http://<Ingress_External_IP> -H "Host: example.com"

预期返回后端服务的响应内容（如 HTTP 200 OK）。

2. 查看日志
检查 Ingress Controller 的 Pod 日志，确认是否有配置更新记录及请求转发日志：

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

3. 常见排查步骤

• 检查 Endpoints：确认 Service 后端有健康的 Pod。kubectl get endpoints web-service
• 检查 Controller：确认 Ingress Controller Pod 处于 Running 状态。
• 检查网络策略：确认没有 NetworkPolicy 阻止 Ingress Controller 访问后端 Service。

常见误区与风险

• 端口管理：如果使用 NodePort 暴露 Controller，需手动管理 30000-32767 端口范围，缺乏灵活性，生产环境建议配合 LoadBalancer。
• 性能差异：公开资料中没有看到可靠的量化数据表明 Traefik 与 Nginx Ingress 在具体 QPS 上的绝对优劣，但 Nginx 作为成熟的反向代理服务器，具有出色的性能和稳定性，继承了这些优点。
• 配置同步延迟：Ingress 配置生效后可能存在秒级延迟，若立即测试失败，可稍后重试。