k8s 奇怪问题的解决过程

[buffzty]

ingress route 中某个域名证书过期了,准备换一下 结果换了 2 个小时 尝试了 n 种方法都没换成功,最后成功很戏剧性

1. 将 secret 中 证书和私钥更新 无效
2. 重启 ingress controller 无效
3. 删除 tls secret 并 新建 同名 tls secret 无效
4. 重启 ingress controller 无效
5. 新建 tls secret2 并将某个 ingress route 的 secret name 换成 secret2 无效
6. 重启 ingress controller 无效 这时候我有点蒙了,开始怀疑证书是用的阿里云负载均衡的,上去看了一下不是. 并将 ingress controller pod 缩减到一个 并抓包那台主机 tls server.hello.cert 消息 发现 nginx 返回的 tls 证书还是旧的.
7. 添加新 ingress route 域名用新的比如 api-2.xx.com 使用 tls secret2 证书 访问时证书显示是最新的 说明新域名没问题 tls secret2 也没问题 但是旧的 ingress route 访问还是旧证书 无效
8. 将所有 ingress route secret name 全部换成 secret2 并重启 ingress controller 无效
9. 删除 secret1 并重启 ingress controller 此时 k8s 中已经没有旧证书的信息了,但是访问还是返回旧证书 无效
10. 将 ingress controller pod 切换到一台全新的主机 证书还是老的 无效
11. 更新 ingress controller 为最新版 并重启 无效 此时再次崩溃 去查 ingress github 的 issue,也有跟我遇到一样问题的人 他们说的方法我都试过了 此时我怀疑是 ingress class 的 bug 了.因为我都把证书删光了还给我返回
12. 新建 ingress class 用另一个版本 并将 ingress route 的 ingress class 更新为新建的 ingress 无效

刚开始我还进 ingress pod 中 查看了 nginx.conf 搜索了 tls 证书加载方式 发现是 lua 从 k8s 集群中给他返的 在 pod 里根本没有 crt 和 key 这 2 个文件 不像其他的直接弄个目录挂载

此时我已经在怀疑我自己了,是不是第 8 步我改名的时候 有漏的没改的 我已经准备再改一遍了 就去喝了水眺望一下 回来时 1 分钟解决!

我们应用层所有的 depo 都在 beta 和 prod2 个 ns 中,default ns 是不用的. 但是 default 中有个 ingress route 用到了 tls secret1. 这个 route 是我搭建 k8s 时测试的.一直没删. 我准备检查第 8 步的时候发现了这个!

最终. 将 default 下 ingress route secret name 更新为 secret2 重启 ingress controller 成功!

这个问题太搞人了,我之前就搜过更新证书方式 基本都说是更新一下 secret 就行了 也有说要将全部 route 更新 secret name 的 我觉得这个不现实,我们成百上千个 route 一个个改 改到什么时候. k8s 没有这种弱智.就不相信. 没想到还就得这么改 我真是服了漏一个都不行. 我个人的最大错误在于思维定式 没想到除了 beta 和 prod 还有其他 ns 有 ingress route 用着旧的证书,以后一定注意.做就要做全部