Kubernetes Ingress 完全解析：从原理到实战的外部流量接入方案

Kubernetes Ingress 完全解析从原理到实战的外部流量接入方案一、开篇为什么需要 IngressKubernetes 中 Pod 和 Service 仅能在集群内部访问外部流量接入面临三大痛点多服务暴露需多个 LoadBalancer成本高且难管理缺乏 HTTP/HTTPS 层路由如域名、路径转发无统一的 SSL 终结、虚拟主机配置能力。Ingress 应运而生—— 它是 Kubernetes 中管理外部访问集群服务的 API 对象本质是「七层负载均衡规则集合」通过 Ingress Controller 实现流量路由解决上述痛点HTTP/HTTPS 流量路由规则互联网Ingress ControllerIngress 配置Service AService BService CPod 集群Pod 集群Pod 集群二、核心概念Ingress 关键组件与原理2.1 两大核心组件Ingress 资源定义路由规则域名、路径、后端服务映射是「声明式配置」Ingress Controller实现路由规则的核心组件如 Nginx、Traefik需单独部署无 Controller 则 Ingress 配置无效。关键区别Ingress 是「规则」Controller 是「执行器」—— 类比Ingress 是交通信号灯Controller 是交警二者缺一不可。2.2 核心功能清单基于域名的虚拟主机路由多个域名共享一个 IP基于路径的流量转发同一域名下不同路径映射不同服务SSL/TLS 终结统一管理证书无需每个服务单独配置负载均衡内置 L7 层负载均衡策略默认后端处理无匹配规则的流量如 404 页面。2.3 与其他暴露方案的对比选型关键方案层级核心优势缺点适用场景Ingress推荐L7应用层单 IP 暴露多服务、支持域名 / 路径路由、SSL 终结需部署 Controller配置稍复杂生产环境、多服务暴露、HTTPS 需求NodePortL4传输层配置简单、无额外组件依赖端口范围限制30000-32767、节点 IP 动态变化测试环境、临时暴露服务LoadBalancerL4传输层云厂商托管、高可用单服务一个 LB、成本高、无 L7 路由能力单服务暴露、对成本不敏感Port ProxyL4传输层直接代理 Pod无需 Service无负载均衡、稳定性差调试场景、临时访问三、实战步骤Ingress 核心配置与操作3.1 先决条件集群版本 ≥ Kubernetes 1.1Ingress 最低支持版本部署 Ingress Controller如 Nginx、Traefik云厂商集群GKE/EKS/AKS通常默认内置。3.2 四种核心 Ingress 配置实战3.2.1 基础配置单路径路由将http://Ingress-IP/testpath转发到test:80服务apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress spec: rules: - http: paths: - path: /testpath # 匹配路径 backend: serviceName: test # 目标服务名 servicePort: 80 # 目标服务端口创建并验证kubectl apply -f ingress.yaml kubectl get ing test-ingress # 输出NAME RULE BACKEND ADDRESS # test-ingress - test:80 10.xx.xx.xx3.2.2 多路径路由同一域名下多服务转发将http://foo.bar.com/foo转发到s1:80http://foo.bar.com/bar转发到s2:80apiVersion: extensions/v1beta1 kind: Ingress metadata: name: multi-path-ingress spec: rules: - host: foo.bar.com # 绑定域名需解析到 Ingress IP http: paths: - path: /foo backend: serviceName: s1 servicePort: 80 - path: /bar backend: serviceName: s2 servicePort: 803.2.3 基于名称的虚拟主机多域名共享 IP同一 Ingress IP 绑定两个域名分别转发到不同服务apiVersion: extensions/v1beta1 kind: Ingress metadata: name: virtual-host-ingress spec: rules: - host: foo.bar.com # 域名1 http: paths: - backend: serviceName: s1 servicePort: 80 - host: bar.foo.com # 域名2 http: paths: - backend: serviceName: s2 servicePort: 80核心原理通过 HTTP 请求头中的Host字段匹配路由。3.2.4 TLS 加密HTTPS 终结配置先创建 TLS 证书 SecretapiVersion: v1 kind: Secret metadata: name: tls-secret type: Opaque data: tls.crt: 基础64编码的证书内容 # echo -n 证书内容 | base64 tls.key: 基础64编码的私钥内容Ingress 引用 Secret 启用 HTTPSapiVersion: extensions/v1beta1 kind: Ingress metadata: name: tls-ingress spec: tls: - secretName: tls-secret # 引用 TLS Secret rules: - host: foo.bar.com http: paths: - backend: serviceName: s1 servicePort: 80关键特性支持 SNI 扩展同一端口可绑定多个 HTTPS 域名。3.3 常用运维操作3.3.1 更新 Ingress 规则# 编辑现有 Ingress 配置 kubectl edit ing test-ingress # 或替换配置文件 kubectl replace -f updated-ingress.yaml3.3.2 查看 Ingress 状态与规则# 查看基本信息 kubectl get ing # 查看详细路由规则 kubectl describe ing test-ingress3.3.3 删除 Ingresskubectl delete ing test-ingress # 注意仅删除规则不影响后端 Service 和 Pod四、高级特性Ingress 进阶用法4.1 分区路由金丝雀发布通过annotations配置以 Nginx Ingress 为例metadata: name: canary-ingress annotations: nginx.ingress.kubernetes.io/canary: true nginx.ingress.kubernetes.io/canary-weight: 10 # 10% 流量转发到金丝雀服务 spec: rules: - host: foo.bar.com http: paths: - backend: serviceName: s1-canary servicePort: 804.2 默认后端配置处理无匹配规则的流量如返回 404spec: backend: serviceName: default-backend # 自定义 404 服务 servicePort: 80 rules: - host: foo.bar.com http: paths: - backend: serviceName: s1 servicePort: 80五、生产环境最佳实践Controller 选型云厂商环境优先使用内置 Controller如 GKE 的 GLBC自建集群推荐 Nginx Ingress功能全、生态成熟或 Traefik动态配置、易用性高。高可用配置Ingress Controller 部署多个副本结合 NodePort 外部负载均衡器如阿里云 SLB、AWS ALB。证书管理使用 Cert-Manager 自动签发和续期 Let’s Encrypt 证书避免手动维护。安全加固禁用 HTTP强制跳转 HTTPS配置 CORS 策略限制跨域访问启用速率限制防止 DDoS 攻击。监控告警监控 Ingress Controller 日志、请求成功率、延迟配置告警阈值如 5xx 错误率 1% 告警。六、核心结论Ingress 核心价值以声明式方式统一管理外部流量实现「单 IP 多服务、L7 层路由、SSL 终结」是生产环境暴露服务的首选方案选型原则测试环境用 NodePort 快速暴露单服务生产环境用 LoadBalancer 简单高效多服务生产环境用 Ingress 降低成本、简化管理关键注意事项必须部署 Ingress Controller否则 Ingress 配置无效域名需解析到 Ingress Controller 的外部 IP不同 Controller 支持的 annotations 不同需参考对应文档。