冒死分析： Ingress 没有准备好成为"统一流量入口"

[easterfan]

目前在做的专有云领域，一个基于 k8s 的容器云迁云项目， 集群稳定运行一年后，有天突然出现 P0 事故，全平台入口宕机，事后将 ingress 架构一拆为三，写了一篇博客记录； 但是对 ingress 了解不深，观点可能有失偏颇

所以发到 v2 上，给大佬们批评指正

原文地址（博客托管在 github pages 上，加载可能很慢，请见谅）：👇🏻

冒死分析：Ingress 没有准备好成为"统一流量入口"

[oaa]

有点没懂。
“
同时 Ingress 本身有一个 reload 机制，当检测到副本数从 N -> 0 或者 0 -> N 时，Ingress Controller 会同时触发两个 Ingress 的重载，开辟新的 worker 进程，并关闭老的 worker 进程；
”
你的意思是，如果后端 pod 挂了，Nginx-Ingress 会 reload ？

[Zaden]

第一反应是 ingress 游戏……

[JoeJasper]

试试基于 envoy 的 Higress

[easterfan]

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

[lsk569937453]

有这么多 Ingress controller 的实现，包括但不限于 envoy,traefik,kong 。你不能因为一个 nginx ingress controller 出问题就否定整个 ingress 啊。

[billzhuang]

TIL
"Ingress 本身有一个 reload 机制，当检测到副本数从 N -> 0 或者 0 -> N 时，Ingress Controller 会同时触发两个 Ingress 的重载，开辟新的 worker 进程，并关闭老的 worker 进程"

这个是 nginx ingress controller 干的么？

[easterfan]

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

[defunct9]

pod crash ，这个才是要命的原因吧。说的更极端点，后端的 pod 掉光了，前面有啥也没用啊。

[easterfan]

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

[iv2ex]

@Zaden Ingress 游戏还能玩不？我登录上去，地图资源加载不出来。攒了 3 、400 个 AXA

[Zaden]

@iv2ex afk 多少年了，游戏群都变成吹水群了

[adamwym]

如果 nginx 直接使用 service cluster ip 做 upstream 地址是不是就可以避免 pod 重启导致的 nginx 频繁 reload 了

[adamwym]

@adamwym
不知道这个选项能不能达到这个效果
https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md#service-upstream

[isno]

看到 [冒死分析] ，有点眼熟...

你把 ingress 一分为三，但再碰到个“请求 CDP” 就 Crash 的 Pod 呢？

这个问题的 root cause 是频繁重启的 Pod ，如果监测到这样的 Pod ，就临时把这个服务从 ingress 摘掉，这样是不是更好点？或者看看 kong 、apisix 怎么解决的

[egen]

可以看看 easegress

[defunct9]

要命也不是 ingress ，UDP 用 ng 来转发也不对，根本无状态。换成 haproxy 估计会好。

[cheng6563]

nginx ingress 不知是不是非云原生的原因，好像是这类问题不少，我之前还见过在 ingress annotations 配置的东西插入了 nginx 的全局配置把 nginx 搞挂的。


话说我司是用的 daemonset 跑的 traefik ingress

[feedcode]

> 一处理 UDP 请求，马上就 Crash 。首先出于 kubernetes 的自愈机制，deploy 控制器检测到副本数从 1 -> 0 后，会自动重启 pod ，控制副本数从 0 -> 1 ；

pod crash 后不是 kubelet 负责重启的吗，与 Deploy Controller 没啥关系。deploy 变动会触发 replicate set 变动，然后 Replication Controller 负责 pod 更新, 也就是说 Deploy Controller 管不到 pod 副本数

pod crash 后影响的是 Service 的 EndpointSlice ， 不会直接影响 nginx config, 为啥会导致 nginx 重启

[feedcode]

@cheng6563 nginx ingress controller 有 validation webhook, enable 之后可以挡掉 99%的无效 annotation

[lasuar]

```
再同时供应商将 UDP 请求设置了一个超时机制，超时时间为 600s ，由于 pod 已经 crash ，所以连接一直在等待响应，虽然 Ingress 本身也有 worker 进程的超时时间，为 240s ，两者取最短，实际上 pod crash 状态出现时，每个 UDP 请求最多只等待 240s ，老的 worker 进程就会被关闭。但 240s 也是很长的时间了，已经足够发 N 多 UDP 请求，足够触发 N 次副本数 1->0, 0->1 的变化使 Ingress reload 多次，足够发生老的 nginx worker 进程被占用一直处于释放中，新的 worker 已经被用尽到无法创建。
```

恕我直言，真看不太懂你这段描述，能否提供一个稳定复现的步骤呢？我和它们的疑问一样，为何服务 pod 重启会导致 ingress pod 重启。