跳转到内容

Ingress 面试题

10 道题
分类
Kubernetes
子分类
services-network
题目数
10 道
已阅读 0 / 10 题
1 什么是 Ingress?与 Service、Gateway 是什么关系?

答案:

Ingress 是 Kubernetes 内置的 L7 流量管理 API 对象,用于将集群外部的 HTTP/HTTPS 请求根据主机名(host)和路径(path)路由到集群内的 Service。

核心职责:

  • L7 负载均衡:基于 HTTP 主机头、URL 路径、Header 等做路由。
  • TLS 终止:在 Ingress 边缘统一卸载 HTTPS,后端 Service 走明文 HTTP。
  • 统一入口:为多个 Service 提供单一外部访问点,避免暴露过多 NodePort/LoadBalancer。
  • 可声明式路由:通过 YAML 描述规则,由 Controller 翻译成具体代理(Nginx/Envoy/Traefik)的配置。

与 Service 的关系:

  • Service 是 L4 负载均衡(基于 IP+Port),Ingress 是 L7 路由(基于 HTTP 语义)。
  • Ingress 不直接转发到 Pod,而是引用后端 Service,由 Service 再转发到 Pod。

与 Gateway API 的关系:

  • Ingress 是 2016 年 引入的早期 API,能力集中在 HTTP 路由,CRD 体系弱。
  • Gateway API(GA 于 2023 v1.0)是下一代演进标准,按角色拆分为 GatewayClass / Gateway / HTTPRoute 等资源(v1.5 标准含 HTTPRoute/GRPCRoute/TLSRoute/ReferenceGrant/BackendTLSPolicy/ListenerSet;TCPRoute/UDPRoute 仍为 Experimental),原生支持多协议、多租户、后端引用(BackendTLSPolicy、RateLimit、TrafficSplit)。
  • 在新项目中,云厂商、Istio、Envoy Gateway、Traefik、Higress 都在主推 Gateway API;Ingress 仍在维护但属于遗留 API。
2 IngressClass 的作用是什么?spec.ingressClassName 与旧版 kubernetes.io/ingress.class 注解有何区别?

答案:

IngressClass 是将 Ingress 资源具体 Controller 实现 解耦的资源对象。

核心机制:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx-public
spec:
  controller: k8s.io/ingress-nginx        # 关联到哪个 Controller
  parameters:
    apiGroup: k8s.io/v1
    kind: ConfigMap
    name: nginx-public-config              # Controller 特定的配置参数

两类 IngressClass 选 Controller:

方式写法状态
spec.ingressClassNamespec.ingressClassName: nginx官方推荐(v1+),强一致
kubernetes.io/ingress.class Annotationannotations: kubernetes.io/ingress.class: nginx旧版(v1beta1)兼容字段,v1 中仍可工作但已弃用

关键差异:

  • spec.ingressClassName 字段会被 Controller 严格校验,未匹配的 Controller 直接忽略该 Ingress,不会出现"被多个 Controller 同时接管"的歧义。
  • Annotation 方式在多 Controller 场景下需要靠 Controller 端 watch 选择器过滤,行为不统一。
  • 生产环境必须只使用 spec.ingressClassName,避免混用导致路由冲突。

默认 IngressClass:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"  # 标记为默认

设置了 is-default-class 后,未指定 ingressClassName 的 Ingress 自动归该 Controller 管理。

3 主流 Ingress Controller(ingress-nginx / Traefik / Higress / APISIX)如何选型?

答案:

四个 Controller 都实现了 Kubernetes Ingress API,但定位和能力差异显著。

维度ingress-nginxTraefikHigressAPISIX
数据面Nginx + Lua自研(Go)Envoy + WASM/IstioApache APISIX(Lua + etcd)
配置热加载Lua reload(毫秒级)Go 原生(无 reload)xDS 推送(零重启)etcd watch(毫秒级)
配置 APIIngress + CRDIngress + CRD(IngressRoute)Gateway API 一等公民Ingress + CRD
高并发吞吐极高(C10M 级别)中等极高(Envoy 内核)
插件体系Lua/OpenResty中间件插件WASM/Go/Redis/MCP 30+Lua + 多语言插件 100+
适用场景传统 Web 路由、稳定性优先中小规模、K8s 原生体验AI 网关、微服务、统一流量API 网关、插件生态丰富
运维复杂度低(社区文档多)极低(自动服务发现)中(依赖 Istio CRD)中(依赖 etcd)
社区背书K8s 官方维护分支法国公司,K8s 友好阿里云开源Apache 软件基金会(顶级项目)

选型决策树:

  • 传统企业、稳定性优先、高并发 Web → ingress-nginx(最成熟,生态最大)。
  • K8s 纯云原生、轻量化、快速上手 → Traefik(Dashboard 友好,配置全自动)。
  • AI 网关、Mesh 融合、多协议统一(HTTP/gRPC/WebSocket/MQTT/Dubbo) → Higress(阿里背书,WASM 插件灵活)。
  • API 网关、复杂插件、可观测性 → APISIX(插件市场 + etcd 统一配置中心)。

生产建议:

  • 单一团队、单一业务域:1 个 Controller 即可,避免多 Controller 抢同一 VIP。
  • 多团队共享集群:使用 IngressClass 隔离(每个团队独立 Controller + 独立 IngressClass + 独立 LoadBalancer)。
4 Ingress 的 path 重写(rewrite)怎么配置?不同 Controller 有何差异?

答案:

Ingress 自身不直接支持 URL 重写,需要通过 Controller 特定的 AnnotationCRD 实现。

ingress-nginx 的重写方式:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-rewrite
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2           # 关键
    nginx.ingress.kubernetes.io/use-regex: "true"             # 开启正则匹配
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: backend-svc
            port:
              number: 80

访问 /api/users/123 实际转发到后端的 /users/123$2 捕获组替换到 rewrite-target)。

Traefik 的重写方式(中间件 Middleware):

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: strip-prefix
spec:
  stripPrefix:
    prefixes: ["/api"]
    forceSlash: false
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: app
spec:
  routes:
  - match: Host(`app.example.com`) && PathPrefix(`/api`)
    kind: Rule
    services:
    - name: backend-svc
      port: 80
    middlewares:
    - name: strip-prefix

Higress / APISIX:通过 CRD + 插件

重写 vs 重定向:

  • 重写(rewrite):服务端改 URL 路径,客户端 URL 栏不变($request_uriproxy_pass)。
  • 重定向(redirect):返回 301/302,客户端浏览器改 URL 后重新请求。生产中,短链/SEO 域名切换 用重定向,路径归一化 用重写。

常见坑:

  • pathType: Prefix 时,rewrite 后路径仍会保留前缀(如 /api/foo → 后端 /api/foo),需要 rewrite-target 显式剥离。
  • pathType: ImplementationSpecific 才允许正则,Prefix/Exact 严格匹配。
  • 多重 Ingress 拼接路径时,注意 $1 $2 占位符与正则捕获组的对应关系。
5 Ingress 如何配置 TLS 终止?证书管理有哪些最佳实践?

答案:

Ingress 在 边缘层完成 TLS 卸载,后端 Service 使用明文 HTTP,简化微服务证书管理。

手动配置 TLS:

apiVersion: v1
kind: Secret
metadata:
  name: app-tls
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-cert>
  tls.key: <base64-encoded-key>
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-app
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    - api.example.com
    secretName: app-tls                          # 引用 Secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-svc
            port: { number: 80 }

cert-manager 自动化(生产首选):

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-account
    solvers:
    - http01:
        ingress:
          class: nginx                          # 通过 Ingress 80 完成 HTTP-01 校验
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-app
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod    # 自动签发
spec:
  tls:
  - hosts: [app.example.com]
    secretName: app-tls                              # cert-manager 自动写回
  rules: ...

最佳实践:

  • HTTP-01 vs DNS-01 校验:HTTP-01 简单(仅需 80 端口可达),但要求签发期间域名解析到 Ingress IP;通配符证书必须 DNS-01(如 *.example.com)。
  • TLS 1.2 强制:在 ConfigMap 中关闭 TLS 1.0/1.1(ssl-protocols: TLSv1.2 TLSv1.3),避免 POODLE/BEAST 等老协议攻击。
  • HSTS 开启nginx.ingress.kubernetes.io/hsts: "true" + hsts-max-age: 31536000,强制浏览器 HTTPS。
  • Secret 轮转:cert-manager 证书默认有效期 90 天,到期前 30 天自动续期;手动 Secret 需建立监控(cert-exporter + 告警)。
  • 国密证书:金融/政企场景需 SM2/SM3/SM4 套件,ingress-nginx 默认不支持,需要 Tengine 或 OpenResty + 国密扩展。
6 Ingress 常用 Annotations 有哪些?分类与典型配置是什么?

答案:

Annotations 是 Ingress Controller 行为调优的核心接口,不同 Controller 各自定义。

ingress-nginx 高频注解分类:

1. 后端连接与超时

nginx.ingress.kubernetes.io/proxy-body-size: 50m              # 上传大小
nginx.ingress.kubernetes.io/proxy-read-timeout: "60"          # 读超时(秒)
nginx.ingress.kubernetes.io/proxy-send-timeout: "60"          # 写超时
nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"       # 连接后端超时
nginx.ingress.kubernetes.io/upstream-keepalive-connections: "100"
nginx.ingress.kubernetes.io/upstream-keepalive-timeout: "60"

2. 后端协议

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"         # 后端走 HTTPS
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"          # gRPC 透传
nginx.ingress.kubernetes.io/grpc-backend: "true"

3. 限流与连接数

nginx.ingress.kubernetes.io/limit-rps: "100"                 # 每秒请求数
nginx.ingress.kubernetes.io/limit-rpm: "5000"                 # 每分钟请求数
nginx.ingress.kubernetes.io/limit-connections: "100"          # 并发连接数
nginx.ingress.kubernetes.io/limit-rate: "1024"                # 带宽(KB/s)

4. 跨域与安全

nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-origin: "https://example.com"
nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, OPTIONS"
nginx.ingress.kubernetes.io/cors-allow-credentials: "true"

5. 灰度与重写

nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20"
nginx.ingress.kubernetes.io/rewrite-target: /$2

6. 会话保持

nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "route"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "86400"

注解作用域优先级:

  1. Ingress 级 Annotation(最优先)
  2. IngressClass 的 parameters 引用 ConfigMap
  3. 全局 ConfigMap(如 nginx-configuration
  4. Controller 启动参数

生产经验:

  • 不要把所有配置都堆在 Ingress 上,应分层:通用参数进 ConfigMap,业务参数(路径/重写)放 Ingress。
  • Annotation 拼写错误不会报错(被忽略),但会导致隐性配置缺失;建议配合 kubectl describe ingress 校验最终生效配置。
  • 关键配置(限流、连接上限)必须显式设置,依赖默认值是大坑。
7 如何在 Ingress 层面做限流(Rate Limiting)?不同 Controller 的实现机制是什么?

答案:

Ingress 限流是 L7 边缘防护的第一道闸门,用于防爬虫、防刷单、防突发流量压垮后端。

ingress-nginx 限流(依赖 Lua + 共享内存):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-rate-limit
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "100"          # 单 IP 每秒 100 请求
    nginx.ingress.kubernetes.io/limit-connections: "50"    # 单 IP 最多 50 并发
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port: { number: 80 }

底层实现:limit_req_zone + limit_conn_zone,基于 binary_remote_addr 共享内存计数。

复杂限流(按 Header / Cookie / 用户):

# Ingress Annotation 仅支持:limit-rps / limit-rpm / limit-connections / limit-burst-multiplier
nginx.ingress.kubernetes.io/limit-rps: "10"
# 自定义限流 key(如按 Header / Cookie)需通过 ConfigMap 配合 Snippet
# 在 ConfigMap 中使用 limit-req-key 等自定义 key

Traefik 限流(中间件):

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: rate-limit
spec:
  rateLimit:
    average: 100
    burst: 200
    period: 1s

APISIX 限流(插件):

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: api-route
spec:
  http:
  - name: api
    match:
      hosts: [api.example.com]
      paths: ["/api/*"]
    backends:
    - serviceName: api-svc
      servicePort: 80
    plugins:
    - name: limit-count                       # 计数限流
      enable: true
      config:
        count: 100
        time_window: 60
        key: remote_addr
        rejected_code: 429

Higress 限流: 基于 Envoy local_ratelimit filter,支持 Header/Path/IP 维度的 RPS/连接数限流。

生产建议:

  • 多层限流:Ingress 边缘(粗粒度 IP 维度)+ 应用层(细粒度用户/业务)双层防护。
  • 返回 429:限流触发时必须返回 429 Too Many Requests + Retry-After 头,告知客户端降级。
  • 分布式限流:单 Controller 限流只覆盖该节点,多实例需要 Redis Token Bucket(如 APISIX redis-limit-count、Higress 配合 Sentinel)。
  • 白名单豁免:内部监控/CDN/支付回调等 IP 需放行,避免误杀。
8 Ingress 与 Gateway API 的核心区别是什么?迁移路径如何规划?

答案:

Gateway API 是 Kubernetes 官方主推的 下一代 L4/L7 流量管理标准,由 SIG-Network 在 2022 年发起,2023 年 v1.0 GA。

核心区别:

维度IngressGateway API
协议支持仅 HTTP/HTTPSHTTP/HTTPS/TCP/UDP/gRPC/TLS
资源模型单 Ingress 混合声明按角色拆分为 4 类(见下)
多租户弱(靠 Annotation)原生支持(namespace 隔离 + ReferenceGrant)
后端引用仅 ServiceService/Pod/任意 Object(BackendTLSPolicy)
流量切分靠 Annotation 扩展原生 TrafficSplit、HTTPRouteFilter
跨命名空间不支持通过 ReferenceGrant 显式授权
表达式path prefix/exact/regex完整 CEL 表达式 + Header/Query 匹配
实现成熟度高(10+ 年生态)中(2023 GA,主要 Controller 1.0+ 稳定)

Gateway API 资源拆分:

  • GatewayClass:集群级,定义"用什么 Controller 实现"(由云厂商/平台管理员管理)。
  • Gateway:网络基础设施实例(监听端口、TLS 配置、跨命名空间共享)。
  • HTTPRoute:HTTP 路由规则(应用开发者创建,可跨 namespace 引用 Gateway)。
  • ReferenceGrant:跨 namespace 引用的显式授权(安全设计,避免任意引用)。
# GatewayClass(平台管理员)
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
# Gateway(基础设施)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
spec:
  gatewayClassName: envoy
  listeners:
  - name: http
    port: 80
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            gateway-access: "true"
# HTTPRoute(应用开发者)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: team-a
spec:
  parentRefs:
  - name: prod-gateway
  hostnames: ["app.example.com"]
  rules:
  - matches:
    - path: { type: PathPrefix, value: /api }
    backendRefs:
    - name: app-svc
      port: 80

迁移路径:

  1. 共存期(推荐 6-12 个月):新业务直接用 Gateway API,老业务保留 Ingress,通过不同 Controller / 不同 IngressClass / 不同 LB 隔离。
  2. 过渡期:用 ingress2gateway 工具(kubernetes-sigs/ingress2gateway)自动将 Ingress YAML 转 HTTPRoute,逐个迁移。
  3. 收敛期:删除 Ingress Controller,回收 LoadBalancer IP。
  4. Gateway API + 多协议:将 TCP/UDP/gRPC 业务从 NodePort 迁到 TCPRoute/UDPRoute,统一入口。

选型建议:

  • 新集群(2024+):直接上 Gateway API,Envoy Gateway / Istio / Higress 是当下最成熟实现。
  • 存量集群:保留 Ingress 不动,新业务用 Gateway API,逐步替代。
  • 金融/政企:先评估 Gateway API 生态成熟度(部分 Controller 仍处于 0.x → 1.0 过渡期),稳定性敏感场景暂用 ingress-nginx。
9 Ingress 生产部署的最佳实践有哪些?

答案:

1. 高可用与伸缩

  • 多副本 Controller:Deployment 副本数 ≥ 2(生产建议 3),反亲和性打散到不同 Node。

  • Pod 反亲和

    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector: { matchLabels: { app.kubernetes.io/name: ingress-nginx } }
          topologyKey: kubernetes.io/hostname
    

- **HPA**:CPU > 70% 或 RPS 突增时自动扩容;MinReplicas ≥ 2 防单点。
- **LoadBalancer 健康检查**:云厂商 LB 配置 `/healthz` 探测,Controller 滚动期间流量平滑。

**2. 容量规划**

- **Controller 资源**:单 Pod 起步 `requests: { cpu: "500m", memory: "1Gi" }`,根据 QPS 调优。
- **Nginx worker 数**:ConfigMap `worker-processes: "auto"`(与 CPU 核数对齐)。
- **共享内存**:`proxy-body-size` 大文件上传需配大 `proxy-buffering` 与 `client-body-buffer-size`。
- **连接数上限**:内核 `net.core.somaxconn` ≥ 65535,`net.ipv4.tcp_max_syn_backlog` 同步调大。

**3. 可观测性**

- **Metrics**:开启 Prometheus `/metrics`(v1.9+ 默认启用,端口 **10254**,与 Nginx 业务端口隔离),关键指标 `nginx_ingress_controller_requests`、`nginx_ingress_controller_request_duration_seconds`。Helm 部署需配置 `controller.metrics.serviceMonitor.enabled=true` 才能被 Prometheus Operator 自动发现。
- **日志**:access log 输出 JSON 格式(`log-format-upstream` 自定义),接 Loki/ES,包含 `request_id`、`upstream_addr`、`upstream_response_time`。
- **Tracing**:开启 OpenTelemetry(OTel)透传,关联后端 TraceID。
- **Dashboard**:Grafana 官方 Dashboard ID 9614(nginx-ingress)。

**4. 安全加固**

- **真实 IP 透传**:`use-forwarded-headers: "true"` + `compute-full-forwarded-for: "true"`,后端 Service 用 `X-Forwarded-For` 取客户端真实 IP。
- **关闭 SNAT**(保留客户端源 IP):`Service.spec.externalTrafficPolicy: Local`(K8s 层),或 ingress-nginx 启动参数 `--enable-snat=false`(v1.10+ 默认已为 false)。注意 `enable-ssl-chain-completion` 是 NGINX Plus 的**证书链补全**参数,与 SNAT 无关,**不可**用作 SNAT 关闭。
- **真实 IP 透传**:`use-forwarded-headers: "true"` + `compute-full-forwarded-for: "true"`,后端 Service 用 `X-Forwarded-For` 取客户端真实 IP。
- **WAF 联动**:与 ModSecurity/Coraza 集成(ingress-nginx 通过 Sidecar 注入),防 SQL 注入/XSS。
- **Admin API 隔离**:Nginx Plus / APISIX / Kong 的 Admin API 绝不暴露公网,必须走 `kubectl port-forward` 或内网 Ingress。

**5. 配置管理**

- **GitOps 化**:所有 Ingress YAML 入 Git(ArgoCD/Flux),避免 `kubectl apply` 漂移。
- **变更审计**:Critical 路径(支付、登录)配置变更需 Code Review + 灰度。
- **回滚预案**:Controller 升级或 ConfigMap 变更失败时,5 分钟内一键回滚(Git 仓库 + ArgoCD 同步窗口)。

**6. 灰度与多环境**

- **环境隔离**:dev/staging/prod 用 **独立 IngressClass + 独立 Controller + 独立 LB**,避免测试流量污染生产。
- **Header 灰度**:使用 `canary-by-header`(如 `X-Canary: true`)做内部人员先行验证,再按权重放量。
- **流量录制**:生产环境通过 **ingress-nginx + go-httpbin** 录制真实流量到 staging 回放。
10 Ingress 常见故障排查思路与高频问题是什么?

答案:

排查三板斧:

  1. 看状态kubectl describe ingress <name> 确认 Events 无报错、Controller 正确接管。
  2. 看配置:通过 Controller 暴露的 nginx -T/configuration 路径)查看渲染后的实际配置。
  3. 看流量:抓包 tcpdump、看 access log、对比 Service 是否有 Endpoints。

高频故障 Top 10:

现象根因排查命令
Ingress 创建成功但 404pathType 不匹配 / 后端 Service 无 Endpointskubectl get endpoints <svc>
503 Service Temporarily Unavailable后端 Pod 未就绪 / 端口配错kubectl describe svc + kubectl logs
TLS 握手失败Secret 证书链不完整 / SNI 未配openssl s_client -connect host:443 -servername host
502 Bad Gateway后端 Service 健康检查失败 / 应用启动慢kubectl get pod + 应用 readiness probe
504 Gateway Timeoutproxy-read-timeout 过短 / 后端慢 SQLaccess log upstream_response_time 字段
客户端 IP 是 Pod IP 而非真实 IP未配 use-forwarded-headerskubectl logs$remote_addr 字段
灰度规则不生效canary Annotation 拼写错误kubectl describe ingress 看 Events
配置变更后部分路由失效Admission Webhook 拒绝 / ConfigMap 语法错kubectl logs -n ingress-nginx admission-webhook
Controller OOMKilledproxy-body-size 过大 / 共享内存爆kubectl describe pod + /metrics go_memstats_*
多 Controller 抢同一 IngressingressClassName 字段 / 旧版 Annotation 混淆kubectl get ingressclass + 检查 Annotation

黄金排查命令集:

# 1. 确认 Controller 状态
kubectl -n ingress-nginx get pods -l app.kubernetes.io/name=ingress-nginx

# 2. 查看 Ingress 是否被接管
kubectl describe ingress <name> | grep -A 5 "Events"
kubectl describe ingress <name> | grep "Class"

# 3. 看 Controller 渲染后的 Nginx 配置
kubectl -n ingress-nginx exec <pod> -- cat /etc/nginx/nginx.conf | less

# 4. 验证 Service 后端 Endpoints
kubectl get endpoints <svc-name> -o wide
kubectl get pod -l app=<label> -o wide

# 5. 从 Controller Pod 内访问后端 Service
kubectl -n ingress-nginx exec <pod> -- curl -v http://<svc>.<ns>.svc.cluster.local/

# 6. 抓包看真实流量
kubectl -n ingress-nginx exec <pod> -- tcpdump -i eth0 -nn -s 0 -w /tmp/cap.pcap port 80

# 7. 看 access log 实时
kubectl -n ingress-nginx logs -f <pod> | grep "<host>"
```text

**应急止血:**

- 路由异常:临时回滚 Ingress YAML(`kubectl rollout undo` ArgoCD Application)。
- Controller 故障:`kubectl -n ingress-nginx rollout restart deployment` 触发滚动重启。
- 证书过期:`kubectl create secret tls` 临时续命,配合 cert-manager 排查续期失败原因。

**生产排障原则:**

- 任何变更**先在 staging 复现**,再在生产动手。
- 变更前后**对比 metric**(QPS / P99 latency / 5xx rate),避免"修了 A 坏了 B"。
- **保留现场**:Controller 故障时先 `kubectl describe` + `kubectl logs --previous`,不要急着重启。