从Service到Ingress：手把手教你为K8s应用配置Nginx反向代理与域名访问

从Service到Ingress：Kubernetes网络暴露实战指南

在Kubernetes集群中部署Web应用后，如何安全高效地对外提供服务是每个开发者必须掌握的技能。本文将带你从零开始，逐步实现从ClusterIP内部服务到Nginx Ingress域名访问的完整链路，涵盖NodePort、Service反向代理与Ingress三种方案的对比与实践。

1. Kubernetes网络基础架构解析

1.1 Pod网络通信原理

Kubernetes网络模型要求每个Pod都拥有唯一的IP地址，这个IP在集群内可直接路由。理解这一底层机制对后续服务暴露至关重要：

• 同Pod内容器通信：共享网络命名空间，通过localhost直接访问
• 同节点Pod间通信：通过CNI插件创建的虚拟网桥（如cni0）实现二层互通
• 跨节点Pod通信：依赖Overlay网络（如Flannel的VXLAN隧道）或Underlay方案

# 查看节点网络接口（Flannel示例） ip addr show flannel.1

1.2 Service抽象层工作原理

Service作为Kubernetes的核心抽象，解决了Pod动态IP带来的连接问题：

服务发现流程：

1. 客户端查询DNS获取Service ClusterIP
2. kube-proxy通过iptables/ipvs规则将请求转发到后端Pod
3. 负载均衡算法（默认轮询）选择目标Pod

提示：生产环境建议使用ipvs代理模式，相比iptables有更好的性能表现

2. 基础服务暴露方案对比

2.1 NodePort直连方案

最简单的服务暴露方式，适合快速验证场景：

apiVersion: v1 kind: Service metadata: name: web-nodeport spec: type: NodePort ports: - port: 80 targetPort: 80 nodePort: 30080 selector: app: nginx

优缺点分析：

• ✅ 快速验证：无需额外组件，分钟级暴露服务
• ❌ 端口管理：需手动管理30000-32767端口范围
• ❌ 缺乏灵活性：无法实现基于域名的路由

2.2 Nginx反向代理方案

在NodePort基础上增加Nginx层，实现更灵活的7层路由：

# nginx.conf片段 server { listen 80; server_name app.example.com; location / { proxy_pass http://web-nodeport.default.svc.cluster.local; proxy_set_header Host $host; } }

性能实测数据（ab测试，100并发）：

注意：Nginx代理会增加约30%的延迟，但提供了URL路由等高级功能

3. Ingress高级路由方案

3.1 Ingress Controller部署

以Nginx Ingress Controller为例的部署步骤：

1. 安装Helm包管理器
2. 添加Ingress-nginx仓库
3. 定制化安装Controller

helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace \ --set controller.service.type=LoadBalancer

3.2 Ingress资源定义

实现基于域名的HTTP路由和TLS终止：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: tls: - hosts: - app.example.com secretName: example-tls rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: web-service port: number: 80

关键注解说明：

• nginx.ingress.kubernetes.io/affinity：启用会话保持
• nginx.ingress.kubernetes.io/limit-rps：限流配置
• nginx.ingress.kubernetes.io/proxy-body-size：调整上传大小限制

4. 生产环境最佳实践

4.1 性能优化方案

连接池配置（在Ingress Controller的ConfigMap中）：

data: keep-alive: "75" keep-alive-requests: "100" upstream-keepalive-connections: "1000"

内核参数调优：

# 增加连接跟踪表大小 sysctl -w net.netfilter.nf_conntrack_max=131072

4.2 安全加固措施

1. TLS配置：

   • 使用cert-manager自动管理证书
   • 启用HSTS和TLS 1.3

2. 访问控制：

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

3. 防护配置：

   • 限制Body大小
   • 启用WAF模块
   • 配置速率限制

4.3 监控与日志

Prometheus监控指标：

• nginx_ingress_controller_requests：请求量统计
• nginx_ingress_controller_request_duration_seconds：延迟分布

日志收集方案：

# Fluentd配置示例 <match nginx.**> @type elasticsearch host elasticsearch port 9200 logstash_format true </match>

5. 方案选型决策树

根据实际场景选择最适合的暴露方案：

1. 开发测试环境：

   • 直接使用NodePort
   • 或Minikube的minikube tunnel

2. 预发布环境：

   • Nginx反向代理+基础路由
   • 手动管理的Ingress

3. 生产环境：

   • Ingress Controller+自动证书管理
   • 云厂商LoadBalancer集成
   • 多集群流量分发

典型迁移路径： 开发环境 → NodePort → 测试环境 → Nginx代理 → 生产环境 → Ingress+CDN