@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

@defunct9 是的，pod 没上测试集群，直接带缺陷上生产集群了；也是巧合，但是因为全平台入口宕机，事故影响面大，PaaS 平台得背锅 80% QAQ

@lsk569937453 感谢指正，哈哈哈 标题有点激进了，更正《冒死分析：nginx Ingress 没有准备好成为"统一流量入口"》

@oaa 是的，后端 pod 副本是 1 ，Crash 后，副本数 1->0; 然后 k8s 会重启这个 pod ，把他的副本又从 0->1; 但是 0->1, 1->0, 都会触发 ingress reload ，触发的很频繁

to 2024-27
1. 坚持总结、写博客、题材没有限制，尝试一些技术之外的文章
2. 能够独当一面，做项目的负责人，不仅是接口人
3. CKS 考试费已经交了，尽量上半年考完
4. 雅思考到 7 分
5. 践行断舍离，拒绝消费主义，存钱
6. 理性炒股
7. 提高情商！

@Kevin2 @wxw752 @caliburn1994 @mason1984 @adian @lzllingchen @twofox @xiaoliu926
目标越具体、可量化、有明确 deadline 越好，比如先立个 2024 年底雅思考到 7 分；
我是拖延了 2 年，今年在考虑加上惩罚措施，考不到 7 分就给朋友发 500 块钱；
否则我是不会开始行动的。

a goal without a plan is a wish.

共勉

@asche910 OP 我帮你把立英语 flag 的人圈出来了

@cyaki 感谢提醒，过两天试试 aws

@Alliot
博客是直接从本地导出 html ，样式比较极简😂

一开始没用 svc ，主要是考虑到有环路依赖，kubelet apiserver 依赖 ipvs ipvs 依赖 kubeproxy 写入规则 kubeproxy pod 的存活依赖 kubelet ，如果 kubeproxy 挂了规则被刷新了，会有死锁问题~

太水了 都把我淹死了

阿里云的 cnstack2.0 即将上线

@assassins1234567 感谢评论！

这个 datasource 是阿里云资源管理产品产品下的，返回的是 2 个目录，我先拿到这两个目录，然后分别在 2 个目录下建账号；

建账号时需要传目录 ID ，我是通过 list[0] 下标的方式取目录的；
但是由于这个 datasource 返回的目录是无序的，加上我又通过下标取目录，经常出现把 B 账号一会建到 A 目录下，一会建到 B 目录下；

为了解决这个问题，我想对 datasource 的返回值根据目录名排序，这样就能保证 list[0] 取到的永远是确定的目录；

在官网上有看到 datasource 有 filter 字段，但就是没有 sort 字段；

然后我就不会排序了，一想到 java 里 3 秒钟就能实现的功能，搞了 3 小时没搞出来，就很痛苦🤧

@lambdaq 大佬，刚刚去 terraform 官网找了一圈，没看到付费的入口，你是不是被人骗钱了~