秀云南1. 为什么需要Kubernetes Ingress？
在Kubernetes集群中，Pod是动态创建和销毁的，它们的IP地址也是动态分配的。当我们需要从集群外部访问这些Pod提供的服务时，直接使用Pod IP显然不现实。Service资源虽然提供了稳定的访问端点，但随着微服务架构的普及，一个集群可能运行着数十甚至上百个服务，每个服务都使用独立的NodePort或LoadBalancer显然会造成端口管理和成本问题。
Ingress的出现就是为了解决这个痛点。它相当于集群的"智能路由器"，可以根据请求的主机名、路径等规则，将外部流量路由到集群内部不同的服务。想象一下，Ingress就像是一个高级的酒店前台，能够根据客人的需求（访问路径）将他们引导到正确的房间（后端服务）。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Ingress的核心组件解析
2.1 Ingress资源
Ingress资源是Kubernetes中的一种API对象，用于定义路由规则。一个典型的Ingress YAML示例如下：
yaml复制apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /service1
pathType: Prefix
backend:
service:
name: service1
port:
number: 80
- path: /service2
pathType: Prefix
backend:
service:
name: service2
port:
number: 80
这个配置表示：
- 访问myapp.example.com/service1的请求会被路由到service1
- 访问myapp.example.com/service2的请求会被路由到service2
2.2 Ingress Controller
Ingress资源本身并不处理流量，真正干活的是Ingress Controller。它是一个监听Ingress资源变化的代理服务，会根据Ingress定义的规则配置底层的负载均衡器。常见的Ingress Controller有：
- Nginx Ingress Controller：基于Nginx，功能丰富，社区活跃
- Traefik：轻量级，支持动态配置
- HAProxy Ingress：高性能，适合大规模部署
- AWS ALB Ingress Controller：与AWS ALB集成
选择哪种Controller取决于你的具体需求。如果是在云环境，建议优先考虑云厂商提供的Controller；如果是本地部署，Nginx Ingress Controller是个不错的起点。
3. 生产环境中的Ingress实践
3.1 TLS终止配置
在生产环境中，为Ingress配置TLS加密是基本要求。我们可以通过Kubernetes的Secret资源来存储证书：
bash复制kubectl create secret tls myapp-tls \
--cert=path/to/cert.pem \
--key=path/to/key.pem
然后在Ingress中引用这个Secret：
yaml复制spec:
tls:
- hosts:
- myapp.example.com
secretName: myapp-tls
重要提示：证书需要定期更新，建议使用cert-manager等工具实现自动证书管理。
3.2 路径重写与正则匹配
不同的后端服务可能有不同的URL结构，这时就需要路径重写。以Nginx Ingress为例：
yaml复制annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
rules:
- http:
paths:
- path: /service1(/|$)(.*)
pathType: ImplementationSpecific
backend:
service:
name: service1
port:
number: 80
这个配置会将/service1/abc重写为/abc后转发给service1。
3.3 流量切分与金丝雀发布
Ingress可以实现流量的百分比分配，非常适合金丝雀发布场景：
yaml复制annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20"
这个配置会将20%的流量路由到这个Ingress定义的后端，剩余80%走默认路由。
4. 性能优化与问题排查
4.1 性能调优参数
对于高流量场景，需要对Ingress Controller进行调优。以Nginx Ingress为例：
yaml复制kind: ConfigMap
apiVersion: v1
metadata:
name: nginx-configuration
data:
worker-processes: "4"
keep-alive-requests: "10000"
upstream-keepalive-connections: "200"
这些参数可以根据实际负载情况进行调整。建议通过压力测试找到最佳配置。
4.2 常见问题排查
-
503 Service Unavailable
- 检查后端服务是否健康
- 检查Endpoint是否正常：
kubectl get endpoints <service-name>
-
404 Not Found
- 检查Ingress规则中的host和path是否匹配请求
- 检查后端服务是否监听正确的路径
-
证书相关问题
- 检查Secret是否存在且包含正确的证书
- 检查证书是否过期：
openssl x509 -enddate -noout -in cert.pem
-
性能瓶颈
- 监控Ingress Controller的CPU和内存使用情况
- 检查Nginx的error.log和access.log
5. 高级场景与最佳实践
5.1 多租户隔离
在大规模集群中，可能需要为不同团队或项目提供独立的Ingress资源。可以通过以下方式实现：
- 使用不同的hostname：team-a.example.com vs team-b.example.com
- 使用Annotations定义不同的upstream配置
- 为每个团队部署独立的Ingress Controller
5.2 全局负载均衡
对于跨地域部署的应用，可以结合云厂商的全局负载均衡器（如AWS Global Accelerator、Google Cloud Global LB）与Ingress实现最优路由。
5.3 安全加固
- 启用WAF（Web应用防火墙）规则
- 限制客户端IP范围
- 设置请求速率限制
- 禁用不安全的HTTP方法
yaml复制annotations:
nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.0.0/24"
nginx.ingress.kubernetes.io/limit-rpm: "100"
nginx.ingress.kubernetes.io/server-snippet: |
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 405;
}
6. 监控与日志
完善的监控是生产环境不可或缺的部分。建议：
- 收集Ingress Controller的指标（请求数、延迟、错误率等）
- 设置关键指标的告警（如5xx错误率超过1%）
- 集中存储和分析访问日志
可以使用Prometheus和Grafana搭建监控系统：
yaml复制# Prometheus scrape配置示例
scrape_configs:
- job_name: 'nginx-ingress'
metrics_path: '/metrics'
static_configs:
- targets: ['nginx-ingress-controller:10254']
对于访问日志，可以考虑使用EFK（Elasticsearch+Fluentd+Kibana）或Loki+Promtail+Grafana方案。
7. 替代方案比较
虽然Ingress是Kubernetes中管理外部访问的标准方式，但也有其他选择：
-
Service Type: LoadBalancer
- 简单直接，每个服务获得独立的外部IP
- 成本高，缺乏高级路由功能
-
API Gateway
- 如Kong、Apigee等
- 提供更丰富的API管理功能
- 复杂度更高，学习曲线陡峭
-
Service Mesh Ingress
- 如Istio Ingress Gateway
- 与Service Mesh深度集成
- 适合已经采用Service Mesh的架构
选择哪种方案取决于你的具体需求。对于大多数Kubernetes应用，Ingress + Ingress Controller已经足够。