实际上 ingress-nginx 在处理后端 endpoint slices 变化时已经尽可能想办法避免频繁的 reload ，参考： https://kubernetes.github.io/ingress-nginx/how-it-works/#avoiding-reloads-on-endpoints-changes

但是在 endpoint slices 从 0 -> 1 或是从 1 -> 0 的这两种情况下依然会触发 Reload, 或许楼主当时要是能给 Pod 多整几个副本就能正好绕过这个问题 :)

当然正经解决方案还是可以考虑用 envoy 这类真正不用 reload 的中间件，或者直接把 TCP/UDP 流量直接通过 SLB 打到 nodeport 上

个人经验，电子烟比真烟容易戒断。之前抽真烟时尝试戒烟几乎没有超过一星期的，但是电子烟曾经几个月不抽，感觉没太大难度。同时我的身体能明显感觉到真烟比电子烟带来了更大的负担。

当然，电子烟最后也因为别的原因复吸了 :)

opcache 开了吗？从火焰图上看似乎和文件系统有点关系，如果没有打开的话可以打开试试

@adoyle

提示是 DST Root CA X3 这张 root 证书过期了，我用 Safari 打不开，这张证书是之前 Let's Encrypt 旧的根证书，will expire on September 30, 2021

很奇怪的是如果用 Firefox 或是 Chrome ，打开是 ISRG Root X1 签发的一张证书，这张是 ok 的

同时我用 curl 在本地和广州腾讯云的机器上试了一下也是拿到的 DST Root CA X3 签发的证书，我也有点奇怪这是什么情况

域名的根证书过期了大佬

将备份内容加密，多一层保险可能是一个解决方案

200+微服务 springboot 应用和 20+周边服务如（ redis/rabbitmq/ng 等等）+ 所有类型数据库（ Mysql/SQLServer/Oracle/PG 等）


这么大一堆东西，能一天部署完调试好也算你们厉害了。

想要再提高效率，容器化和声明式 API 部署应该是唯一的路，就算客户不给你 kubectl 权限，通过 jenkinsfile 调用 kubectl 和你通过 jenkinsfile 调用 shell 实际上是一码事，所以还是可行的。

有点意思。

@kestrelBright 监控的覆盖度如果够高，可以第一时间告警有故障的部分

取一个折中的办法： 在服务端或是客户端改造都行，每条长链接用过多少次之后就销毁（取值取决于你的负载情况），比如每条长链接处理过 1000 个请求就主动关闭，促使其重新建立连接，这样即能保证效率，与能保证大致的负载均衡

https://github.com/valeriansaliou/sonic 或 https://github.com/meilisearch/meilisearch

信息密度太高了，赞

你开车弄个车充不就好了吗，还要充电宝干啥

哦，我看的是 2 楼的例子


不过我试了一下，以下这个例子是 OK 的，在 ./postgresql/data 出现了数据，无法复现你的问题

```yaml
version: '3'

services:
db:
image: postgres:12-alpine
restart: on-failure
environment:
POSTGRES_USER: demo
POSTGRES_DB: demo
POSTGRES_PASSWORD: demo
volumes:
- ./postgresql/data:/var/lib/postgresql/data
```

因为 postgresql 的数据实际存储在 /var/lib/postgresql/data 下，它直接在 Dockerfile 中声明了一个 VOLUME 是在 /var/lib/postgresql/data

而你挂载的是 /var/lib/postgresql ，由于 UnionFS 的特性，挂载 /var/lib/postgresql 并不影响下边再挂一个 /var/lib/postgresql/data


最后你的数据实际上没有丢，在宿主机上的 /var/lib/docker/volumes 下找找有惊喜

通过某种手段标记请求并将这些请求走特殊分支的方法实际上是有隐患的：因为有可能这条分支没有 bug ，但真实用户走的分支有问题，导致问题测不出来


这个问题个人看法，暂时没什么特别好的办法，如果会影响到普通用户，只能手动清理一下

给得很高啊，这价格还能 955 ，比 T9 都爽