1. Kubernetes Ingress：集群外部访问的流量指挥官

当你在Kubernetes集群中部署了十几个微服务后，第一个头疼的问题就是：外部用户如何访问这些服务？总不能让每个服务都占用一个公网IP。这就是Ingress存在的意义——它像机场的塔台调度员，统一管理所有进入集群的流量，根据规则将请求精准路由到对应的服务。

与NodePort和LoadBalancer这类直接暴露服务的方式不同，Ingress工作在应用层（HTTP/HTTPS），通过域名和路径实现智能路由。比如将 /api 开头的请求转发到后端API服务， /static 开头的请求交给静态资源服务器。这种基于规则的流量管理方式，让集群对外暴露的入口从N个减少到1个，大幅降低了安全风险和管理成本。

1.1 Ingress的核心能力拆解

一个标准的Ingress控制器通常具备以下核心功能：

• 基于Host的路由 ：根据HTTP头中的 Host 字段（如 shop.example.com ）分流到不同服务
• 路径重定向 ：将 /v1/api 重写为 /api 后再转发给后端
• TLS终止 ：在Ingress层统一处理HTTPS证书，避免每个服务单独配置
• 流量分配 ：按权重将请求分发给不同版本的服务（如90%流量走v1，10%走v2）
• 基础防护 ：支持IP黑白名单、速率限制等安全策略

以电商场景为例，你可以通过一个Ingress规则同时处理：

api.example.com/v1/orders → 订单服务v1版
api.example.com/v2/orders → 订单服务v2版（灰度发布）
static.example.com → CDN边缘节点

这种灵活性让Ingress成为微服务架构中不可或缺的流量管理枢纽。

2. 主流Ingress控制器选型指南

2.1 Nginx Ingress：K8S原生方案的扛把子

作为Kubernetes社区官方维护的Ingress控制器，Nginx Ingress的特点是：

• 成熟稳定 ：基于Nginx开发，继承其高性能特性（单节点可处理5000+ RPS）
• 配置灵活 ：支持Annotations扩展（如 nginx.ingress.kubernetes.io/rewrite-target ）
• 监控完善 ：内置Prometheus指标暴露（如 nginx_ingress_controller_requests ）

部署示例：

helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

典型配置片段：

annotations:
  nginx.ingress.kubernetes.io/affinity: "cookie"
  nginx.ingress.kubernetes.io/proxy-body-size: "20m"

踩坑提示：Nginx Ingress默认会丢弃包含下划线的Header（如 X_AUTH_TOKEN ），需要通过 enable-underscores-in-headers 配置项显式开启。

2.2 Traefik：云原生时代的轻量之选

相比Nginx，Traefik的优势在于：

• 动态配置 ：支持自动发现服务变化，无需reload配置
• 内置Dashboard ：实时可视化查看路由状态（默认端口8080）
• 中间件机制 ：通过CRD实现鉴权、重试等扩展功能

关键性能对比：

特性	Nginx Ingress	Traefik
配置生效速度	需要Reload	实时生效
内存占用	较高	较低
WebSocket支持	需手动开启	原生支持
灰度发布	通过Annotation	原生支持

2.3 企业级方案选型建议

对于生产环境，还需要考虑：

• 多集群管理 ：如AWS ALB Ingress Controller可跨AZ分配流量
• WAF集成 ：F5 BIG-IP提供L7层攻击防护
• 全链路加密 ：Istio IngressGateway支持mTLS双向认证

我们的经验是：中小规模集群用Nginx Ingress足够；需要服务网格集成时选择Istio；有云厂商托管服务优先用ALB/NLB方案。

3. Ingress高级配置实战

3.1 金丝雀发布实现技巧

通过 canary 注解实现灰度发布：

annotations:
  nginx.ingress.kubernetes.io/canary: "true"
  nginx.ingress.kubernetes.io/canary-weight: "10" # 10%流量导流

更精细化的控制方案：

nginx.ingress.kubernetes.io/canary-by-header: "X-Env"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"

3.2 流量镜像配置

将生产流量复制到测试环境（不影响主流程）：

annotations:
  nginx.ingress.kubernetes.io/mirror-target: "http://test-svc.default.svc.cluster.local"
  nginx.ingress.kubernetes.io/mirror-request-body: "true"

3.3 自定义错误页面

替换默认的502错误页：

annotations:
  nginx.ingress.kubernetes.io/custom-http-errors: "502"
  nginx.ingress.kubernetes.io/default-backend: "custom-error-pages"

4. 性能调优与问题排查

4.1 关键性能参数优化

在 ConfigMap 中调整全局参数：

data:
  keep-alive-requests: "10000"
  upstream-keepalive-connections: "200"
  worker-processes: "4"

针对大文件上传的特殊配置：

annotations:
  nginx.ingress.kubernetes.io/proxy-body-size: "50m"
  nginx.ingress.kubernetes.io/proxy-read-timeout: "600"

4.2 常见问题排查手册

症状1：503 Service Unavailable

• 检查后端服务Endpoint是否就绪
• 查看Ingress控制器日志： kubectl logs -n ingress-nginx <pod-name>
• 验证Service的selector标签匹配

症状2：413 Request Entity Too Large

• 增加 proxy-body-size 注解值
• 检查客户端是否正确发送Content-Length

症状3：重定向循环

• 检查 ssl-redirect 与后端服务TLS配置冲突
• 验证 rewrite-target 规则是否符合预期

4.3 监控指标关键项

Prometheus需要重点监控的指标：

• nginx_ingress_controller_requests ：按状态码分类的请求量
• nginx_ingress_controller_request_duration_seconds ：请求延迟分布
• nginx_ingress_controller_connections ：当前活跃连接数

Grafana仪表盘配置示例：

sum(rate(nginx_ingress_controller_requests[1m])) by (status)

5. 安全加固最佳实践

5.1 网络层防护

• 通过 whitelist-source-range 限制源IP：

annotations:
  nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.0.0/24"

• 启用ModSecurity WAF规则：

annotations:
  nginx.ingress.kubernetes.io/enable-modsecurity: "true"
  nginx.ingress.kubernetes.io/modsecurity-snippet: |
    SecRuleEngine On
    SecRule REQUEST_URI "@contains /wp-admin" "id:1001,deny,status:403"

5.2 证书管理方案

使用Cert-Manager自动续期Let's Encrypt证书：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-tls
spec:
  secretName: example-tls-secret
  dnsNames:
  - example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

5.3 审计日志配置

记录详细访问日志：

data:
  log-format-upstream: |
    $remote_addr - $remote_user [$time_local] "$request" 
    $status $body_bytes_sent "$http_referer" 
    "$http_user_agent" $request_length $request_time 
    [$proxy_upstream_name] $upstream_addr 
    $upstream_response_length $upstream_response_time 
    $upstream_status

6. 架构演进：从Ingress到Gateway API

随着Kubernetes 1.20+版本推出Gateway API，Ingress的下一代替代方案已经出现。主要改进包括：

• 角色分离 ：基础设施团队管理Gateway，应用团队管理Route
• 跨命名空间支持 ：打破Ingress只能绑定同Namespace服务的限制
• 协议扩展 ：原生支持HTTP、gRPC、TCP等

示例HttpRoute配置：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-app
spec:
  parentRefs:
  - name: shared-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /shop
    backendRefs:
    - name: shop-v1
      port: 80
      weight: 90
    - name: shop-v2
      port: 80
      weight: 10

迁移建议：新集群直接采用Gateway API；现有集群可并行运行Ingress和Gateway，逐步迁移。