ELB Ingress管理的核心在于将Kubernetes集群内的服务流量通过ELB暴露到外网，实现灵活的七层路由转发与高可用负载均衡，从而解决传统Nginx Ingress在公网入口层面的性能与运维瓶颈。参考2
ELB Ingress管理基础与工作原理
搞云原生的兄弟们都知道,把K8s集群里的服务暴露给外网访问，是日常运维的基本操作，以前咱们大多用Nginx Ingress，自己搞个SLB/EIP挂载到Worker节点上，再通过Nginx Pod做反向代理，但随着业务流量越来越大，这种模式的短板就露出来了，ELB Ingress把负载均衡这活儿直接交给了云厂商的ELB服务来做，咱们只需要管理Ingress资源，云上的ELB控制器就会自动帮你建监听器、配后端服务器组。
为什么选择ELB Ingress替代传统Nginx Ingress
咱们先看传统Nginx Ingress的痛点，流量先打到NodePort，再转给Nginx Pod，最后才到业务Pod，这一套链路太长，网络跳数多，延迟自然就上去了，而且Nginx Pod本身需要占用集群的计算资源，流量突发时很容易把Nginx Pod打满，导致整个集群入口不可用。
换成ELB Ingress，情况就大不一样了，ELB直接接管七层（或者四层）流量，请求到了ELB就直接转发给后端的业务Pod（通过ENI或者弹性公网IP直通），这种直连模式，去掉了中间的Nginx转发环节，网络损耗极低，行业共识认为，在处理高并发短连接时，云原生Ingress方案在吞吐量上有明显优势。
ingress绑定elb的核心工作流程
当你在集群里创建一个Ingress资源时,流程其实挺直观的：
- 你提交一段YAML文件,告诉K8s你要哪个域名、哪个路径对应哪个Service。
- 集群里的Ingress Controller（比如CCE的CCM插件）监听到这个变化。
- Controller调用云厂商的API,去ELB服务里创建或更新监听器。
- ELB配置好转发规则,把流量按你写的规则导向后端Pod。
- 流量从公网进来,直达ELB，再直达Pod。
ingress绑定elb后如何配置路由转发规则
光说不练假把式,咱们直接看看怎么把ingress绑定elb这件事儿落地，这里以常见的云厂商CCE为例，讲讲具体操作。
准备工作与ELB实例创建
在绑定之前,得先有个ELB实例，你可以选择在创建Ingress时让系统自动创建一个ELB，也可以用命令行或者控制台手动建好一个ELB，然后再通过注解把它和Ingress绑在一起。
通常情况下,生产环境建议手动创建ELB，这样规格、带宽这些参数自己能把控，创建好ELB后，记下它的ID。
编写YAML文件实现绑定与路由
下面是一段典型的Ingress YAML配置，直接把流量路由到指定的Service：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo-ingress
namespace: default
annotations:
kubernetes.io/ingress.class: cce
kubernetes.io/elb.id: "你的ELB_ID" # 这里写上ELB的ID
kubernetes.io/elb.port: '80'
kubernetes.io/elb.path: '/app(/|$)(.)'
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
rules:
- host: www.demo.com
http:
paths:
- path: /app
pathType: Prefix
backend:
service:
name: demo-service
port:
number: 8080
这段配置里,最关键的就是annotations里的kubernetes.io/elb.id，你把这个值填对，Ingress Controller就知道该把规则下发到哪个ELB上了，应用这段YAML后，用kubectl get ingress看一眼，ADDRESS那一栏就会显示ELB的公网IP。参考2
华为云elb ingress和nginx ingress哪个更适合生产环境
咱们在选型的时候,经常纠结到底用哪个，其实这俩不是水火不容，但确实各有千秋。
性能与稳定性对比
Nginx Ingress本质上是跑在Pod里的软件负载均衡，它的上限完全取决于你分配给Nginx Pod的CPU、内存以及Worker节点的网络带宽，一旦流量超过节点上限，Nginx就会成为瓶颈，甚至OOM。
而ELB Ingress用的是云厂商的硬件级或专属实例级负载均衡，据统计，近年来大型互联网企业在核心网关层采用云原生ELB直连Pod的架构比例在上升，主要就是为了应对双十一、秒杀这种突发流量，ELB的并发处理能力是Nginx没法比的，且后端长连接复用率更高。
运维成本与功能差异对比
咱们用表格来对比一下,看着更直白：
| 对比维度 | ELB Ingress | Nginx Ingress |
|---|---|---|
| 运维复杂度 | 低，无需维护Nginx Pod | 高，需自己扩缩容、升级版本 |
| 网络链路 | ELB直连Pod，跳数少 | ELB -> NodePort -> Nginx -> Pod |
| 高级路由功能 | 依赖云厂商ELB支持的功能 | 极其丰富，可通过Lua脚本扩展 |
| 计费方式 | 按ELB实例规格和流量计费 | 仅消耗集群计算资源 |
| 日志获取 | 需在云控制台配置ELB日志 | 可直接在集群查看Nginx日志 |
如果你的业务对定制化要求极高,比如需要复杂的流量染色、灰度逻辑，Nginx Ingress更灵活，但如果你追求极致的稳定性和低延迟，且不想操心网关层的扩缩容，ELB Ingress绝对是首选。
ingress绑定elb报错怎么排查
搞运维最怕的就是配置提交了,结果不通，ingress绑定elb报错的情况不少，咱们挑几个典型的说说。
常见报错场景与定位思路
第一种,Ingress创建成功了，但访问域名报502或者504，这通常是ELB到后端Pod的链路不通，重点查后端Service的Endpoint是不是空的，以及Pod的健康检查接口有没有正常响应。
第二种,kubectl get ingress发现ADDRESS一直pending，这大概率是注解写错了，或者那个ELB_ID根本不在当前集群所在的VPC里，导致Controller调API失败。参考2
实操排查命令与日志分析
遇到问题别慌,按步骤来。
- 先查Ingress事件：
kubectl describe ingress <ingress-name>，拉到最底下的Events，看看有没有报错提示，ELB not found”或者“Service not found”。 - 查后端Service状态：
kubectl get endpoints <service-name>，如果ENDPOINTS是，说明你的Pod没起来或者Selector标签没对上。 - 查Ingress Controller日志：
kubectl logs -n kube-system <cce-cloud-controller-manager-pod-name>，这里面会详细记录它调用ELB API的过程，如果API报错，这里会有具体的HTTP状态码和错误信息。 - 检查安全组规则：确保ELB所在的安全组允许访问Pod所在节点的安全组，或者如果使用了安全组直通模式，确保Pod的安全组放行了ELB的入站请求。
业内专家指出,大部分ELB Ingress故障的根因在于网络插件配置不当或安全组拦截了ELB到Pod的流量，检查安全组规则也是排查的必选项。
自建k8s集群绑定elb ingress成本高吗
很多兄弟自己买服务器搭K8s集群,也会想挂个ELB，那这玩意儿到底费不费钱？
资源消耗与计费模式拆解
咱们算笔账,自建集群用Nginx Ingress，你不用额外付网关软件费，但你要占用ECS的CPU和内存，还要承担EIP的带宽费用。
如果用ELB Ingress，你得买一个ELB实例，现在云厂商的ELB一般分按需计费和包年包月，按需的话，主要是实例费加上LCU（流量处理单元）费以及公网流量费，对于小流量业务，每个月几十块钱搞定；但如果是大流量业务，LCU费用会随着并发连接数和新建连接数水涨船高。
考虑到省去了Nginx Pod占用的ECS资源开销，以及省下的运维人力成本，综合来看，多数情况下ELB Ingress的性价比是更高的，尤其是当你需要多可用区容灾时，ELB自带跨可用区容灾能力，自己用Nginx搞一套这玩意儿成本极高且容易出故障。
合理配置ELB Ingress不仅能提升流量分发效率，更能大幅降低集群入口层的运维负担，是云原生架构演进的必然选择。
关于ingress绑定elb_ELB Ingress管理的常见问题
Q1: ingress绑定elb后，修改Service的端口会自动同步到ELB吗？
会的,当你修改了Ingress关联的Service端口时，Ingress Controller会监听到这个变化，并自动调用云API更新ELB监听器的后端服务器组端口，但前提是，ELB健康检查能正常通过，否则即使端口同步了，后端节点也会被标记为不可用。
Q2: 为什么ELB健康检查总是异常导致后端服务器组不可用？
这通常是因为ELB的探测路径配置不当,ELB健康检查会向后端Pod发送HTTP请求，如果Pod没有配置对应的探针路径，或者返回了非200状态码，ELB就会认为后端挂了，建议将健康检查路径配置为业务Pod的liveness probe同款路径，并确保该路径无需鉴权即可返回200。
Q3: 使用ELB Ingress时，是否支持基于URL路径的灰度发布？
支持,这通常通过Ingress的注解来实现，你可以创建两个Ingress，指向同一个域名但不同的路径，或者使用特定的灰度发布注解（如nginx.ingress.kubernetes.io/canary等，具体取决于云厂商Controller的实现），将部分流量导入新版本Pod，ELB会根据你下发的规则，在七层进行URL匹配和流量转发。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/532454.html
