Ingress 面试题
10 道题- 分类
- Kubernetes
- 子分类
- services-network
- 题目数
- 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.ingressClassName | spec.ingressClassName: nginx | 官方推荐(v1+),强一致 |
kubernetes.io/ingress.class Annotation | annotations: 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-nginx | Traefik | Higress | APISIX |
|---|---|---|---|---|
| 数据面 | Nginx + Lua | 自研(Go) | Envoy + WASM/Istio | Apache APISIX(Lua + etcd) |
| 配置热加载 | Lua reload(毫秒级) | Go 原生(无 reload) | xDS 推送(零重启) | etcd watch(毫秒级) |
| 配置 API | Ingress + CRD | Ingress + 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 特定的 Annotation 或 CRD 实现。
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_uri改proxy_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: ops@example.com
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"
注解作用域优先级:
- Ingress 级 Annotation(最优先)
- IngressClass 的
parameters引用 ConfigMap - 全局 ConfigMap(如
nginx-configuration) - 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。
核心区别:
| 维度 | Ingress | Gateway API |
|---|---|---|
| 协议支持 | 仅 HTTP/HTTPS | HTTP/HTTPS/TCP/UDP/gRPC/TLS |
| 资源模型 | 单 Ingress 混合声明 | 按角色拆分为 4 类(见下) |
| 多租户 | 弱(靠 Annotation) | 原生支持(namespace 隔离 + ReferenceGrant) |
| 后端引用 | 仅 Service | Service/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
迁移路径:
- 共存期(推荐 6-12 个月):新业务直接用 Gateway API,老业务保留 Ingress,通过不同 Controller / 不同 IngressClass / 不同 LB 隔离。
- 过渡期:用
ingress2gateway工具(kubernetes-sigs/ingress2gateway)自动将 Ingress YAML 转 HTTPRoute,逐个迁移。 - 收敛期:删除 Ingress Controller,回收 LoadBalancer IP。
- 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 常见故障排查思路与高频问题是什么?
答案:
排查三板斧:
- 看状态:
kubectl describe ingress <name>确认Events无报错、Controller 正确接管。 - 看配置:通过 Controller 暴露的
nginx -T(/configuration路径)查看渲染后的实际配置。 - 看流量:抓包
tcpdump、看 access log、对比 Service 是否有 Endpoints。
高频故障 Top 10:
| 现象 | 根因 | 排查命令 |
|---|---|---|
| Ingress 创建成功但 404 | pathType 不匹配 / 后端 Service 无 Endpoints | kubectl 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 Timeout | proxy-read-timeout 过短 / 后端慢 SQL | access log upstream_response_time 字段 |
| 客户端 IP 是 Pod IP 而非真实 IP | 未配 use-forwarded-headers | kubectl logs 中 $remote_addr 字段 |
| 灰度规则不生效 | canary Annotation 拼写错误 | kubectl describe ingress 看 Events |
| 配置变更后部分路由失效 | Admission Webhook 拒绝 / ConfigMap 语法错 | kubectl logs -n ingress-nginx admission-webhook |
| Controller OOMKilled | proxy-body-size 过大 / 共享内存爆 | kubectl describe pod + /metrics go_memstats_* |
| 多 Controller 抢同一 Ingress | 无 ingressClassName 字段 / 旧版 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`,不要急着重启。