easterfan

@rushssss 感谢回复！很靠谱的方案
不过”UDP 流量直接通过 SLB 打到 nodeport 上“，这个方案可能不太合适

1. 集群规模 100 多台机器，除了管控 node 常驻外，其他 worker node ，都是会存在主机上下线场景，nodeport 的 EIP 不好固定，UDP 流量都打到管控 node 的话，这几台机器高峰期压力很大

2. 还是集群规模上，100 多台机器上都开 nodeport 端口，实际只有 1 2 台机器开 EIP + nodeport ，为一个业务开这么多端口，开销大，也显得浪费，所有供应商的对外服务暴露，没有必要情况，都要求首先走 ingress ，不走 nodeport

3. 现在架构设计是 SLB 下挂了 2 台 ingress 主机，如果用 机器 EIP+nodeport 方式，让业务流量直接打到 worker 机器上，那现在这种负载均衡设计就没意义了啊

cc @sampeng

@huihuimoe 主要是一开始 ingress 定位就是所有流量入口，没调研到 udp 场景，也是出了事故后，才知道供应商有 UDP 应用~
metallb 我们目前还没有生产使用经验，感谢提醒，后面会调研下

@cheng6563 感谢提醒，我回去找一下这个报错
1. annotation 引起格式问题导致 ngixn 挂
2. 频繁 reload 场景耗尽 worker 进程，导致 ingress 挂

使用 nginx-ingress 做全局流量入口，这两种场景是全局宕机的风险

@adamwym 这个不太确定，nginx 频繁 reload ，是副本数变化导致的，跟 upstream 地址来源应该没关系吧？

@cheng6563 我也遇到过，最后发现是格式问题，最后好像是加了个 | 还是去掉个 | 解决的

@svatyvabin websocket 暂时还没观察到，reload 把 worker 进程耗尽，倒是非常明显，ingress 独占的 8C16G 机器，worker 数是 8 ，基本 10 次左右，1min 内就可以复现 worker 进程耗尽的现象了

@jqknono 坏的经验和好的经验一样 具有参考价值

@anubu 是的，我们有 csb ，做熔断限流，路由转发，比 ingress 功能更丰富，但是现在还没启用

@billzhuang 是的，这个 bug 也是提在 ingress-ingress-controller 下的 https://github.com/kubernetes/ingress-nginx/issues/5492