K8s 多站點分支 Image 部署診斷¶
概念概覽
多站點環境的 CrashLoopBackOff 診斷優先順序¶
核心知識¶
多站點環境的 CrashLoopBackOff 診斷優先順序¶
當某個站點出現 CrashLoopBackOff 而其他站點正常時，正確的診斷順序：
- 第一步：比對 image 版本（
./compare-image-versions.sh） - 各站點可能使用不同 image tag（分支 build vs 穩定版）
- 案例：syuejun 使用
pocketstore:26.03.syuejun，而 snapshot/dev/beta 使用pocketstore:0.14.0 -
分支 image 基於
feat/2026/refactor-mission_Tutorial，分支程式碼本身有問題才是根因 -
第二步：確認 build 來源（AutoBuildSiteDeploy Pipeline 日誌）
buildBranch=feat/2026/refactor-mission_Tutorial，SkipBuildImage=false確認每次都重 build-
找到 BuildServer job 確認具體 commit
-
最後才看 ConfigMap 差異
- 使用
compare-site-config.sh替換站點名稱後 diff - 某些差異（如 RedisDBIndex）是正常的站點隔離設計，不是問題
RedisDBIndex 站點隔離設計¶
不同站點的 RedisDBIndex 值不同（如 syuejun=15，snapshot=8）是**正常設計**，代表該站點被分配到的 Redis DB 編號。驗證方式：
AutoBuildSiteDeploy 的 image 行為¶
每次 AutoBuildSiteDeploy 都從指定分支重新 build image，因此若分支程式碼有問題，每次 deploy 都會產生問題 image。修復方式：cherry-pick 修復提交或 revert 問題 commit，再重新觸發 build。
經驗教訓¶
-
CrashLoopBackOff 診斷順序：image 版本 > 分支程式碼 > ConfigMap，不要一開始就 diff ConfigMap
-
RedisDBIndex 站點間數值不同是正常設計，需用 checkRedisIndex.py 確認 index 釋放狀態
-
AutoBuildSiteDeploy 每次重 build，分支有問題時每次 deploy 都會失敗，需從根源修分支
常見陷阱¶
-
直接看 ConfigMap diff 容易被正常的站點隔離差異（如 RedisDBIndex）誤導
-
分支 image 每次 deploy 都重 build，若不修分支程式碼，問題會持續復現
最佳實踐¶
-
維護 compare-image-versions.sh 和 compare-site-config.sh 作為標準診斷工具
-
站點 CrashLoopBackOff 優先執行 compare-image-versions.sh，5 秒內確認是否為版本問題
-
分支 image 站點出現問題時，優先 cherry-pick 修復或 revert，再重 build，而非改 ConfigMap
相關概念¶
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-04-01 | e9680a7b-7572-4a2f-949b-d4d7c75a4e96 | 建立了「某站點 CrashLoopBackOff 而其他站點正常」的診斷優先順序：先比對 image 版本，再看 ConfigMap，並澄清了 RedisDBIndex 站點隔離設計不是問題根因。 |