1. 先来点背景：为什么你的请求总是迷路？

想象一下，你开了一家网红餐厅（集群），客人（流量）通过服务员（Ingress）指引到不同的桌子（Pod）。但突然有些客人抱怨找不到座位，或者被分到了错误的位置——这就是路由失效。还有客人投诉服务员说方言（证书不匹配）导致沟通失败。要解决这些问题，得先理清Ingress的核心逻辑。

技术栈说明：本文示例统一基于Nginx Ingress Controller，其他Ingress控制器（如Traefik）的原理类似，但配置细节可能不同。

2. 路由失效的三大场景与实战排障

2.1 路径匹配的"鬼打墙"
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: coffee-shop
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: coffee-v1
            port:
              number: 80
      - path: /v1/special
        pathType: Prefix
        backend:
          service:
            name: coffee-special
            port:
              number: 80

问题分析：
当用户访问cafe.example.com/v1/special时，会被第一个/v1规则截胡，因为Prefix匹配优先级按顺序执行。此时咖啡特供版永远无法触达。

修复方案：
将更精确的路径放在前面，或改用Exact匹配模式：

# 正确配置示例
- path: /v1/special
  pathType: Exact  # 精准匹配
2.2 域名解析的"双重人格"
# 错误示例：相同的host配置冲突
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: duplicate-host
spec:
  rules:
  - host: bar.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend: ... 
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: another-ingress
spec:
  rules:
  - host: bar.example.com  # 重复的host
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend: ...

问题现象：
两个Ingress都声明了bar.example.com，Nginx会合并配置但可能覆盖部分规则，导致访问/api时返回404。

排查工具：
使用kubectl exec查看实际生效的Nginx配置：

kubectl exec -n ingress-nginx <nginx-pod> -- cat /etc/nginx/nginx.conf | grep 'bar.example.com'
2.3 注解配置的"隐形杀手"
# 错误示例：注解缺失导致路径重写失效
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tea-service
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2  # 正则捕获组替换
spec:
  rules:
  - host: teahouse.example.com
    http:
      paths:
      - path: /shop(/|$)(.*)  # 缺少正则标记
        pathType: Prefix
        backend: ...

问题表现：
预期将/shop/admin重写为/admin，实际转发路径仍为/shop/admin。

核心要点：
必须同时在path和注解中声明正则表达式：

path: /shop/(.*)  # 添加正则表达式
annotations:
  nginx.ingress.kubernetes.io/use-regex: "true"  # 启用正则解析

3. 证书问题：HTTPS背后的猫鼠游戏

3.1 证书链不完整的连环套
# 查看证书链完整性（在客户端执行）
openssl s_client -connect teahouse.example.com:443 -showcerts

# 常见错误提示
Verify error:num=20:unable to get local issuer certificate

解决方案：
确保Secret中同时包含服务器证书和中间CA证书：

apiVersion: v1
kind: Secret
type: kubernetes.io/tls
metadata:
  name: fullchain-tls
data:
  tls.crt: |
    -----BEGIN CERTIFICATE-----
    # 服务器证书
    ...
    -----BEGIN CERTIFICATE-----
    # 中间CA证书
    ...
    -----END CERTIFICATE-----
  tls.key: ...
3.2 SAN列表里的漏网之鱼
# 错误示例：证书未包含备用域名
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-domain-ingress
spec:
  tls:
  - hosts:
    - store.example.com
    - api.example.com  # 证书未覆盖该域名
    secretName: wrong-secret

检查工具：
解析证书包含的SAN（Subject Alternative Name）：

openssl x509 -in tls.crt -noout -text | grep DNS:

经验准则：
生产环境推荐使用通配符证书或通过Let's Encrypt自动续签。

4. 关联技术深度解析

4.1 探活机制的暗流涌动
# 正确配置健康检查
apiVersion: v1
kind: Service
metadata:
  name: coffee-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: coffee

---
# Ingress需要依赖Endpoint状态
kubectl get endpoints coffee-service  # 确认Pod IP已注册

典型故障链：
如果后端服务的readinessProbe配置错误 → Endpoint列表为空 → Ingress返回503。

5. 技术选型中的"甜点与陷阱"

方案 优点 缺点
Nginx Ingress 高性能、社区活跃 配置复杂度较高
Traefik 动态配置更新快 大规模集群性能稍逊
AWS ALB Ingress 深度云集成 仅适用于AWS环境

6. 避坑备忘录（血的教训总结）

  1. 证书轮换的死亡30秒
    更新Secret后，使用以下命令强制刷新Nginx配置：

    kubectl rollout restart deploy -n ingress-nginx

  2. 多环境配置的隐身差异
    在开发环境测试通过的Annotation，可能在生产环境因版本不同失效：

    kubectl describe ingress <name> | grep Annotations  # 检查实际生效参数

  3. 浏览器缓存的双面性
    HTTPS故障时，Chrome可能缓存错误的HSTS策略，导致强制重定向无法测试：

    chrome://net-internals/#hsts  # 手动清除缓存

7. 终极防御：构建你的排查兵器库

  1. 实时流量镜像工具
    通过注解开启调试模式：

    annotations:
  nginx.ingress.kubernetes.io/enable-access-log: "true"
  nginx.ingress.kubernetes.io/configuration-snippet: |
    proxy_set_header X-Original-URI $request_uri;

  2. 全链路追踪方案
    在Ingress和后端服务中注入TraceID：

    annotations:
  nginx.ingress.kubernetes.io/service-upstream: "true"

8. 总结：运维的哲学之道

路由与证书问题本质是配置的精确性和完整性之战。推荐建立标准化检查清单：

  1. 使用OpenSSL验证证书链
  2. 通过curl -v逐层测试路由
  3. 定期审计Annotation与K8s版本的兼容性

最终解决方案是人的认知提升与工具化建设并重。就像优秀的餐厅经理既需要熟悉菜单，也要懂得维护点餐系统。