自從上次開始腳踏兩隻船（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 的新船也出現了同樣的問題。