Day 30: 完賽感言：技術成長、架構反思與未來展望

回顧這 30 天做了什麼、學到什麼。

1. 這 30 天完成的事

盤點一下動手做過的事：

• 把一個異構技術棧（Java、Python、Node.js、React）從本機 Docker Compose 一路搬上 Kubernetes
• 建了完整的 GitOps 閉環：GitHub Actions 建置 image、回填 Helm values、ArgoCD 偵測並同步部署
• 用 Argo Rollouts 跑過一次金絲雀發布（25% → 50% → 100%，中途可暫停）
• 把「回滾」這件事測清楚了（Day 20）：在開了 selfHeal 的 GitOps 架構下，kubectl rollout undo 只撐了 2 秒就被 ArgoCD 蓋回壞版本，唯一有效的是 git revert
• 部署過 Prometheus、Grafana、Jaeger、Velero，並餵流量進去驗證行為
• 把「機密怎麼進 Git」做到底（Day 13）：Sealed Secrets 封裝驗證無損、刪掉明文會自動補回；再往上一層用 OpenBao 的 Transit 引擎讓簽章私鑰從不離開 KMS
• 用 Trivy 掃出 CRITICAL 漏洞（CVE-2025-24813），修過兩輪才清零
• 故意弄壞過一次服務（密碼設錯），走完整套 CrashLoopBackOff 排查流程

2. 這系列踩過、也修過的問題

過程中發現的問題，都當場修掉了：

• API Gateway 的 JWT 驗證其實沒生效（Day 6）：中介層寫成 proxy 的 option 屬性，根本不會被執行
• 根目錄的 docker-compose.yml 早就是壞的（Day 7）：引用不存在的服務，clone 下來直接建置失敗
• Helm 化之後，CI 還在改沒人在看的舊目錄（Day 19）：ArgoCD 看的是 helm/wafer-bi/，CI 卻還在更新 k8s/base/，兩條線各自運作正常，兜在一起卻是空轉
• 本機開發叢集的 hostPath 卷，Velero 檔案系統備份不支援（Day 27）：本機測過的流程不代表雲端環境行為一致
• 以為在跑 GitOps，其實在跑 17 天前的手工部署（Day 29）：ArgoCD 的 Pod 都健康，但 Application 早就不在了；所有 Pod 也都 Running，沒有任何一項監控會為這件事亮紅燈
• JVM 的記憶體佔用不等於 Heap 大小（Day 28）：Metaspace、Thread Stack、JIT Code Cache 都要算進去

這些狀況沒有一個是刻意設計的教學情境，都是在準備截圖、寫文章的路上撞到的。後來也因此多寫了一支 scripts/check-config-sync.py，在 CI 裡強制檢查「本地開發設定」與「K8S 部署設定」有沒有對齊，這是從 Day 19 那次事故學到的教訓。

3. 異構架構的代價與收穫

30 天走下來，異構架構帶來的複雜度不小：Java 有自己的 Heap 調優邏輯，Python 沒有；三種語言要接上同一套 OpenTelemetry 標準才能串出跨語言的 Trace；CI 的 build matrix 要照顧六個完全不同的建置流程。但換來的是每個服務都能用最適合它的工具：Python 處理 Delta Lake 的大數據運算、Java 處理需要事務保證的認證邏輯、Node.js 當輕量的路由層。

這個系列最大的心得是：工具與流程能解決的是「怎麼做」，「哪裡會出錯」則要靠跑過一次才知道。

4. 接下來還沒做的事

列一下這個專案目前還缺的部分，留給未來：

• Sealed Secrets 上雲後要重封一次：Day 13 已經在本機叢集實作完成（controller + kubeseal 封出 app-secrets），但密文是跟「某一座叢集的金鑰」綁定的，部署到雲端時必須拿新叢集的公鑰重新封裝。另外 controller 的私鑰（kube-system 裡的 sealed-secrets-key*）要納入 Day 27 的備份範圍，那把掉了所有封過的東西就都廢了
• CSI 卷的 Velero 備份：Day 27 的限制是本機環境特有的，上雲之後要重新驗證一次完整流程
• AnalysisTemplate 自動化金絲雀決策：Day 20 提到的下一步，讓 Argo Rollouts 接上 Prometheus 指標自動判斷要不要繼續放行，取代人工盯盤
• Multi-arch image 的部署驗證：Day 16 的 CI 已經備好 linux/amd64,linux/arm64 兩條產線，但目前還沒有一顆 arm64 節點跑過它，等雲端部署（見下一點）成行才有機會驗證
• 雲端部署：Day 9 記錄過完整過程，OKE 不在 Always Free 帳號的方案內，自架 K3s 的替代方案又卡在 Ampere A1 運算容量連續缺貨，最後這 30 天選擇留在本機。Helm Chart 從 Day 10 就是照著「隨時可以搬遷」的方向設計，所以技術上沒有阻礙；部署上雲、有了對外連結之後，會回來這篇補上

5. 結語

謝謝看到這裡的讀者。這個系列沒有一次寫完美，中間改過設定、修過 bug、也踩過幾次自己挖的坑，維護一套系統大概就是這樣。

如果你也在做類似的異構微服務專案，希望這 30 天記錄下來的東西（尤其是踩坑的部分）能幫你少走一點冤枉路。