nginx-ingress怎样ingress

联启网络工具 2026-07-16 14

本文目录导读：

nginx-ingress怎样ingress-第1张图片-电脑手机工具软件下载 - 免费实用工具合集 | 联启科技

目录导读
1. 什么是 Ingress ？为什么需要 Nginx Ingress？">1. 什么是 Ingress ？为什么需要 Nginx Ingress？
2. 核心工作机制：Nginx Ingress 如何“Ingress”？">2. 核心工作机制：Nginx Ingress 如何“Ingress”？
3. 实战部署：从安装到第一个路由规则">3. 实战部署：从安装到第一个路由规则
4. 高级配置：HTTPS、限流、灰度发布与重写（Rewrite）">4. 高级配置：HTTPS、限流、灰度发布与重写（Rewrite）
5. 企业级挑战：高可用、日志监控与性能调优">5. 企业级挑战：高可用、日志监控与性能调优
6. 常见问题与答疑（QA）">6. 常见问题与答疑（QA）
总结：Nginx Ingress 的“Ingress”本质

Nginx Ingress 实战指南：从零搭建到企业级高可用架构

什么是 Ingress ？为什么需要 Nginx Ingress？

在 KubernetES 生态中，Ingress 并不是一种具体软件，而是一个 API 对象，它定义了从集群外部访问集群内部服务的 HTTP/HTTPS 路由规则，你可以把 Ingress 理解为 “流量大门” —— 它决定了一个请求域名/路径应该被转发到哪个 Service。

而 Nginx Ingress Controller 是这个 API 的 “具体执行者”，它通过监听 Kubernetes API 中的 Ingress 资源变化，自动生成 Nginx 配置文件并 reload，从而实现动态路由，相比云厂商（如 AWS ALB、GCP HTTP LB）的 Ingress 控制器，Nginx Ingress 具有 高性能、极低的资源消耗、丰富的插件生态（如 Lua、Mirror、CORS）等优势。

问答：
问： Nginx Ingress 和 Service 的 NodePort / LoadBalancer 有什么区别？
答： NodePort 是直接将节点端口暴露到外部，每个 Service 一个端口，管理混乱；LoadBalancer 依赖云供应商创建负载均衡器，成本高且不通用，而 Nginx Ingress 通过一个 统一的入口（NodePort 或 LB 单 IP）承载所有路由，由 Ingress 规则进行 七层分发,更适合微服务架构。

核心工作机制：Nginx Ingress 如何“Ingress”？

Nginx Ingress 的工作流程可以简化为三步：

资源监听：Ingress Controller 通过 Kubernetes watch API 监听 Ingress、Service、Endpoints 等资源变化。
配置生成：当检测到新的 Ingress 规则，Controller 会结合 默认配置模板 + 用户注解（Annotations） 动态生成 nginx.conf 片段。
热加载：生成配置后，Controller 会执行 nginx -s reload 实现无缝重载，期间不断连接（长连接重试）—— 这正是它实现“无感更新”且不丢流量的关键。

关键数据结构示例（简化版）：
当用户创建一个 Ingress 资源：

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

Controller 会生成如下 Nginx Location 配置（伪代码）：

location ~* "^/api(/|$)(.*)" {
    set $service_name "api-service";
    set $service_port "80";
    proxy_pass http://api-service:8080/$2;
    ...
}

问答：
问：为什么 Ingress 规则更新后偶现 502 错误？
答：通常因为后端 Pod 滚动更新时，Nginx upstream 配置更新与 Pod 清理存在 时间竞态，解决方案：确保 Service 的 spec.sessionAffinity 为 None（默认），并启用 nginx.ingress.kubernetes.io/use-regex 注解配合慢启动。

实战部署：从安装到第一个路由规则

步骤 1：部署 Nginx Ingress Controller

推荐使用 Helm 安装（K8s v1.19+）：

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --set controller.service.type=NodePort

验证部署：

kubectl get pods -n ingress-nginx  # 期望得到 Running 状态
kubectl get svc -n ingress-nginx   # 查看 NodePort 端口（如 31234、31678）

步骤 2：创建第一个 Service 与 Ingress

假设已有两个应用：blue-service 和 green-service。

apiVersion: v1
kind: Service
metadata:
  name: blue-service
spec:
  selector:
    app: blue
  ports:
  - port: 80
    targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-routing
spec:
  ingressClassName: nginx
  rules:
  - host: app.demo-
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: blue-service
            port:
              number: 80

应用后，将 app.demo- 解析到任一节点IP + NodePort，访问 http://app.demo-/ 即可看到 blue-service 响应。

问答：
问： IngressClassName 必须指定吗？
答：是的，除非集群只有一个 Ingress 控制器且设置为默认，建议始终指定 ingressClassName: nginx,避免多控制器冲突。

高级配置：HTTPS、限流、灰度发布与重写（Rewrite）

1 HTTPS 自动（Let‘s Encrypt）

创建 TLS 证书 Secret：

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: base64...(证书内容)
  tls.key: base64...(私钥)

Ingress 引用：

spec:
  tls:
  - hosts:
    - secure-app.demo-
    secretName: tls-secret
  rules:
  - host: secure-app.demo-
    http:
      paths:
      - path: /
        backend:
          service:
            name: secure-app
            port: 80

自动 HTTPS 升级（添加注解）：

metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

2 基于 Headers 的灰度发布（Canary）

利用 [canary] 注解：

metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"   # 10% 流量
    # 或 canary-by-header: "x-version: stable|canary"

原理：主 Ingress 处理 90% 流量，辅助 canary Ingress 处理 10% 并指向新版本 Service。

3 限流与重写

annotations:
  nginx.ingress.kubernetes.io/limit-rps: "10"
  nginx.ingress.kubernetes.io/limit-rpm: "600"
  nginx.ingress.kubernetes.io/rewrite-target: "/$2"

问答：
问：多个 canary 注解同时使用（如 weight + header）会如何？
答：会先检查 header，若匹配则进入 canary；否则按 weight 概率分配。注意：不能同时使用 canary-weight 和 canary-by-header-value 两种 “互斥条件”。

企业级挑战：高可用、日志监控与性能调优

1 高可用架构

控制器多副本：replicaCount: 3，并使用 Pod Anti-Affinity 分散到不同节点。
使用 DaemonSet + HostNetwork：让 Nginx 直接监听宿主机 80/443 端口，结合 Keepalived 实现 VIP 漂移。
优势：降低延迟（跳过 K8s Service 层 IPVS 转发）、减少跳数。

2 日志收集（JSON 格式）

开启结构化日志：

helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --set controller.config.log-format-upstream='{"@timestamp":"$time_iso8601","remote_addr":"$remote_addr","host":"$host","request":"$request","status":$status,"body_bytes_sent":$body_bytes_sent,"upstream_addr":"$upstream_addr","request_time":$request_time}'

3 性能调优关键参数

worker-processes: auto（根据节点 CPU 核数）
worker-connections: 65536
proxy-connect-timeout: 5s
proxy-send-timeout: 60s
启用 H2C（HTTP/2 over cleartext）的注解：nginx.ingress.kubernetes.io/backend-protocol: "HTTP2"

问答：
问： Nginx Ingress 高延迟如何排查？
答：首先查看 request_time vs upstream_response_time，前者大后者小，说明 Nginx 与客户端之间 出现瓶颈（如 SSL 握手慢或上行带宽不足）；反之为 后端应用慢，建议开启 enable-real-ip 注解并检查 WAF 规则。

常见问题与答疑（QA）

Q1： 为什么 Ingress 规则创建后访问返回 404？
A：最常见原因：

Ingress 控制器 Pod 尚未重启完（等待 10 秒）；
Service 的 label 与实际 Pod 不匹配；
后端 Pod 就绪检查失败（Readiness Probe 不通过）。

Q2： 如何在 Nginx Ingress 中使用自定义错误页面？
A：创建 ConfigMap 并挂载 default-backend-error-page，或者设置 custom-http-errors 注解指向自定义 Service。

Q3： Nginx Ingress 支持 WebSocket 吗？
A：支持，默认自动识别 Upgrade: websocket Header，如果遇到 101 切换失败，添加注解 nginx.ingress.kubernetes.io/proxy-send-timeout: "3600" 并检查后端支持 WSS 协议。

Q4： 如何实现基于客户端 IP 的会话保持（Sticky Session）？
A：通过 Cookie 实现：

annotations:
  nginx.ingress.kubernetes.io/affinity: "cookie"
  nginx.ingress.kubernetes.io/session-cookie-name: "route"
  nginx.ingress.kubernetes.io/session-cookie-hash: "sha1"

Nginx Ingress 的“Ingress”本质

从技术角度，Nginx Ingress 的 “Ingress” 动作 = 监听 K8s API → 模板渲染 → Nginx reload；从业务角度，它解决的是 “如何用统一入口管理数百个微服务路由” 的核心问题。
推荐在生产环境中使用 Helm 安装 + Prometheus Metrics 采集 + 预警规则（如：nginx_ingress_controller_requests > 1000/s） 构建完整可观测性。
如果你刚接触，建议按本文“实战部署”章节先跑通一个最简单的路由，再逐步加入 HTTPS、灰度、重写等高级功能，最终你会发现：Ingress 不是终点，而是统一管控流量的起点。

标签： ingress

本文地址： https://lianqi.tech/post/13272.html