自从上次开始脚踏两只船（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。