K8s实战：利用Ingress-nginx实现多域名服务暴露与流量管理
1. 为什么需要Ingress-nginx？
刚开始接触Kubernetes时，我总被一个问题困扰：如何优雅地把集群内的服务暴露给外部访问？试过NodePort，发现端口管理是个噩梦；用过LoadBalancer，又受限于云厂商的收费方案。直到遇到Ingress-nginx，才发现这才是生产环境该有的解决方案。
简单来说，Ingress-nginx就像集群的智能门卫。想象你住在一个有多个住户的小区（集群内的多个服务），如果给每家都单独开个大门（NodePort），不仅浪费资源还不安全。Ingress-nginx相当于在小区门口设了个统一的接待处，根据访客要找的人（域名或路径）准确引导到对应住户家。
它的核心价值在于：
- 单入口管理：所有外部流量通过80/443端口进入，内部再根据规则分发
- 七层路由能力：能识别HTTP/HTTPS协议内容，实现基于域名、URL路径的精细路由
- TLS终结：可以在入口统一处理HTTPS加密，减轻后端服务压力
- 流量管控：支持限速、重定向、灰度发布等高级功能
2. 快速搭建Ingress-nginx环境
2.1 安装部署实战
第一次部署时踩过不少坑，这里分享验证过的稳定方案。建议使用Helm 3安装，比手动YAML省心很多：
# 添加官方仓库 helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update # 安装到ingress-nginx命名空间 helm install ingress-nginx ingress-nginx/ingress-nginx \ --namespace ingress-nginx \ --create-namespace \ --set controller.service.type=NodePort \ --set controller.service.nodePorts.http=30080 \ --set controller.service.nodePorts.https=30443关键参数说明：
controller.service.type：生产环境建议用LoadBalancer，测试环境用NodePortnodePorts.http/https：指定固定NodePort避免端口随机分配
安装完成后检查Pod状态：
kubectl get pods -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx应该看到controller容器处于Running状态。
2.2 验证基础功能
做个快速测试确保组件正常工作：
# 创建测试服务 kubectl create deployment demo --image=nginx kubectl expose deployment demo --port=80 # 创建Ingress规则 cat <<EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo spec: rules: - host: demo.test http: paths: - path: / pathType: Prefix backend: service: name: demo port: number: 80 EOF本地修改hosts文件添加记录：
<节点IP> demo.test访问 http://demo.test:30080 应该能看到Nginx欢迎页。
3. 多域名路由实战配置
3.1 基础域名路由
实际项目中经常需要同时管理多个域名。假设我们有两个服务：
- 官网服务：website-svc（端口80）
- API服务：api-svc（端口8080）
对应的Ingress配置如下：
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-domain spec: rules: - host: www.example.com http: paths: - path: / pathType: Prefix backend: service: name: website-svc port: number: 80 - host: api.example.com http: paths: - path: / pathType: Prefix backend: service: name: api-svc port: number: 8080这个配置实现了：
- 访问 www.example.com 流量到官网服务
- 访问 api.example.com 流量到API服务
- 自动处理路径前缀匹配和流量转发
3.2 路径重写技巧
有时候后端服务的路径前缀与外部暴露的不一致，比如希望访问 /shop 时实际请求发送到 /。这时候就需要路径重写：
annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: rules: - host: store.example.com http: paths: - path: /shop(/|$)(.*) pathType: Prefix backend: service: name: shop-svc port: number: 80这个配置会把：
- /shop → /
- /shop/products → /products
4. HTTPS安全加固方案
4.1 自动证书管理
现代网站没有HTTPS简直寸步难行。用Cert-Manager可以自动申请和续期Let's Encrypt证书：
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: admin@example.com privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: class: nginx --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: tls-demo annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod" spec: tls: - hosts: - www.example.com secretName: example-tls rules: - host: www.example.com http: paths: - path: / pathType: Prefix backend: service: name: website-svc port: number: 80关键点：
- 先部署cert-manager（详见官方文档）
- 创建ClusterIssuer定义证书颁发机构
- Ingress中通过tls字段指定域名和证书存储的Secret
- 注解cert-manager.io/cluster-issuer触发证书申请
4.2 强制HTTPS跳转
有了证书后，应该强制所有HTTP请求跳转到HTTPS：
annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: "true" nginx.ingress.kubernetes.io/ssl-redirect: "true"5. 高级流量管理技巧
5.1 基于权重的灰度发布
需要上线新版本时，可以通过权重逐步切流：
annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "30" spec: rules: - host: api.example.com http: paths: - path: / backend: service: name: api-v2 port: number: 8080这样30%的流量会路由到api-v2服务，剩余70%继续走默认后端。
5.2 按Header路由
更精细化的控制可以通过请求头实现：
annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "X-Env" nginx.ingress.kubernetes.io/canary-by-header-value: "test"只有包含X-Env: test头的请求才会被路由到新版本。
6. 常见问题排查指南
6.1 连接超时问题
如果遇到504 Gateway Timeout，重点检查：
后端服务是否健康：
kubectl get endpoints <service-name>确保有正常的Endpoint列表
Ingress到Service的网络连通性：
kubectl port-forward service/<service-name> 8080:80本地访问8080端口测试
nginx控制器日志：
kubectl logs -n ingress-nginx <controller-pod-name>
6.2 配置不生效
当修改Ingress后规则没有更新：
检查Ingress资源状态：
kubectl get ingress kubectl describe ingress <name>查看nginx配置是否同步：
kubectl exec -n ingress-nginx <controller-pod-name> -- cat /etc/nginx/nginx.conf常见错误包括：
- 注解拼写错误
- 路径类型(pathType)配置不当
- 端口定义不匹配
7. 性能优化建议
生产环境部署时，这几个参数调优很关键：
controller: config: # 保持长连接 keep-alive: "75s" # 工作进程数 worker-processes: "4" # 每个worker的最大连接数 max-worker-connections: "2048" resources: requests: cpu: "500m" memory: "512Mi" limits: cpu: "2000m" memory: "2Gi"监控指标建议：
- 请求吞吐量（RPS）
- 平均响应时间
- 5xx错误率
- 证书过期时间
8. 真实案例分享
最近帮一个电商客户迁移到Ingress-nginx，他们原有架构是：
- 10个独立域名
- 混合使用NodePort和云负载均衡器
- 证书手动管理经常过期
迁移后实现：
- 统一入口点，节省了7个云LB费用
- 通过注解实现自动HTTPS
- 路径重写简化了前端配置
- 基于Header的灰度发布流程
关键转折点是解决了WebSocket的长连接问题：
annotations: nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" nginx.ingress.kubernetes.io/proxy-send-timeout: "3600" nginx.ingress.kubernetes.io/websocket-services: "ws-svc"