自从上次开始脚踏两只船（2个独立的k8s集群同时运行），园子暂时用奢侈的土豪方式过上了安稳的船上生活。
这种方式除了费钱之外，还带来一个问题，我们的集装箱自动装船系统（基于gitlab-ci的自动化部署）不灵了，不支持同时向2艘船装同样的货（2个gitlab-runner运行同1个job），后来，我们通过 gitlab 的秘密武器 parallel-matrix 解决了。
deploy-prod:
stage: deploy
tags:
- k8s-prod
variables:
DEPLOY_CLUSTER: ${DEPLOY_CLUSTER}
parallel:
matrix:
- DEPLOY_CLUSTER: [k8s-cluster0, k8s-cluster1]注：上面的 DEPLOY_RUNNER 变量在部署中并没有实际用到，只是为了欺骗 gitlab-runner 以实现多个 runner 运行同一个 job。
这2艘船，一艘是旧船，引擎用的是 kubernetes 1.17.0。一艘是新船，引擎用的是 kubernetes 1.23.3，新船是今年春节后投入使用的，出现因大量 pod 同时 CrashLoopBackOff 而翻船的是新船。
上次翻船的博文中园友 Dicky_Zhang 的评论：
版本不对吧，一般不是建议使用1.23.5以上得版本吗，你们使用得.3，虽然说可能问题不大
让我们对新船产生了更多的怀疑，现在有了2只船，就更好验证了。
上周末我们停航了旧船（下线旧k8s集群），只投用新船，周六一切正常，周日又出现部分 pod 无缘无故 CrashLoopBackOff，后来投用新船恢复，证明了单独航行新船肯定会出问题。
这周一2艘船并驾齐驱，一天平稳航行，一切正常。
今天周二依然是2艘船并驾齐驱，上午的访问高峰，新船又出问题了，整个集群有近 40% 的 pod 突然 CrashLoopBackOff（只有新闻应用因为所有 pod 都挂了，部分访问受影响），而旧船稳如泰山，证明了同时航行新旧船，新船会出问题，旧船不会。
接下来，进行更重要的验证，将新船下线，在没有负载的情况下新船上的那些 CrashLoopBackOff 的 pod 很快就恢复正常。而没有新船相伴、独自航行的旧船，面对访问高峰的狂风暴雨，依然稳如泰山地如风平浪静般航行，证明了单独航行旧船不会出问题。
通过今天的验证，我们推断 kubernetes 1.23.3 可能存在稳定性问题，接下来我们会尝试看能不能将新船的引擎降级为 1.22.8。
【更新1：18:00】
没找到降级的方法，准备铤而走险反其道行之——升级至 1.23.5，于是看了看 1.23.5 的 CHANGELOG ，有一个重大发现，竟然修复了一个内存泄漏(goroutine leaks)问题：
- Bump sigs.k8s.io/apiserver-network-proxy/konnectivity-client to v0.0.30, fixing goroutine leaks in kube-apiserver. (#108438, @andrewsykim) [SIG API Machinery, Auth and Cloud Provider]
联系到我们遇到的翻船问题，我们推断内存泄漏引发翻船的嫌疑更大，升级到 1.23.5 正好可以验证。
【更新2：19:45】
引擎升级到 1.23.5 的新船已上线航行。
【更新3：3-23 10:21】
升级到 1.23.5 的新船也出现了同样的问题。