概念位置

跟其他 LLM deployment 形態的對比：

主流 client-side runtime（2026/5）：

設計責任

讀靜態網站 / 前端 RAG / 離線 LLM 教學看到「WebGPU LLM」「browser-side embedding」「offline LLM」就是這 paradigm。寫 code 場景的判讀：

1. 首訪載入慢：browser 第一次要下載模型權重（embedding 模型 ~50MB、LLM 1-5GB）、首訪體驗差；後續訪問 cache 起來、變快
2. WebGPU 支援度：2026/5 仍非所有 browser / 裝置都穩定支援、Safari iOS 較弱；fallback 到 WASM 但速度降一個量級
3. 模型完整性沒簽章：使用者下載到的模型權重沒類似 GGUF model card 的官方驗證、要靠 CDN + HTTPS 信任、不像本地 Ollama 有 hash 比對
4. 適合「embedding + 小 LLM」、不適合「30B reasoning」：browser 記憶體跟 WebGPU 算力都遠不如本地 Ollama、選 < 4B 模型較實際
5. 跟資安的關係：client-side 不需要 server API key、隱私強；但模型分發鏈（CDN → browser）成為新的供應鏈面、見 4.16 靜態 RAG deployment 的資安段

觀察

Tradeshift 從 self-hosted Kubernetes 遷移到 Amazon EKS，legacy 叢集上運行 409 個 service。遷移以零停機為硬性前提，且要求對應用程式碼零修改——遷移的複雜度由平台層吸收，服務團隊不改程式碼。

遷移採用 parallel cluster 架構：新舊叢集同時運行，透過 Linkerd service mesh 的 multi-cluster 能力橋接。Linkerd 在新叢集中建立 mirrored service（帶叢集後綴），讓跨叢集服務呼叫對應用層透明。流量切換用 Linkerd 的 traffic splitting policy 分批控制，不需要修改個別服務的路由邏輯。

跨叢集延遲實測：從 EKS 叢集存取 legacy 叢集的 gateway，P50=2ms、P95=8ms、P99=9ms。這個延遲水平足以支撐遷移期的跨叢集服務呼叫，但對延遲敏感的路徑仍需要在同一叢集內完成切換才能消除這層額外延遲。

判讀

這類遷移的難點在跨叢集服務依賴與流量切換，Kubernetes API 相容性反而是最容易處理的部分。Linkerd multi-cluster 在這個案例中解決了三個問題：跨叢集 service discovery（mirrored service 自動同步）、流量分批控制（traffic splitting 不改應用碼）、遷移期 rollback（切回舊叢集只需調整 traffic split 比例）。

409 個 service 的遷移不是一次完成——service 之間有依賴關係，遷移順序要按依賴拓樸規劃。被多個服務依賴的基礎 service（auth、config）通常最後遷移或在兩邊都保留，避免跨叢集呼叫成為所有服務的共同瓶頸。

遷移期最大的隱性風險是「跨叢集延遲累積」。單次跨叢集呼叫 P99=9ms 看似可接受，但一條請求路徑如果串接 5 個跨叢集呼叫，累積延遲可達 45ms。遷移規劃要把服務依賴鏈上的跨叢集呼叫次數納入切換順序考量。

策略

1. 建立 parallel cluster + mesh bridge：新叢集用 EKS 建立，Linkerd multi-cluster 連接新舊叢集，mirrored service 讓跨叢集呼叫透明。
2. 按依賴拓樸排序遷移批次：葉子服務（無下游依賴）先遷，基礎服務最後遷或雙邊保留。每批遷移後驗證跨叢集延遲是否在可接受範圍。
3. Traffic splitting 分批切流量：每個服務遷移後，用 traffic split 從 0% 開始逐步把流量導向新叢集。觀察 per-service error rate 與 latency，確認穩定後提高比例。
4. 保留 rollback 路徑：舊叢集服務不立即下線，traffic split 隨時可切回 100% 舊叢集。rollback 操作是調整 split 比例，不需要重新部署。
5. 遷移完成後拆除 mesh bridge：所有服務切換完成且穩定觀測後，移除跨叢集 Linkerd 連線，舊叢集下線。

可回寫的章節段落

• 5.2 分階段平台遷移：traffic split 的分批切換與回退策略
• 5.4 跨叢集 Discovery：Linkerd mirrored service 是跨叢集 discovery 的 service mesh federation 做法
• 6.8 Release Gate：每批切換的放行條件與停損訊號

引用源

• Tradeshift migration to EKS without downtime using Linkerd

對「多服務多實例 container orchestration、需要 rolling update / blue-green / canary、跨雲 / 跨環境統一抽象」這條路徑、Kubernetes 是首選。

本章目標

讀完本章後、你應該能：

1. 用 kubectl 部署 Deployment + Service、配置 probe / resource limit
2. 設計 rolling update / pod disruption budget 避免服務中斷
3. 選 Ingress controller（nginx / traefik / GLBC / ALB Controller）
4. 看懂 pod stuck / probe fail / OOMKilled / drain timeout 訊號
5. 評估 managed（GKE / EKS / AKS）vs 自管 vs Operator 進階場景

最短路徑：5 分鐘把 Kubernetes 跑起來

 1# 1. 本機跑 kind（需先安裝 kind + docker）
 2kind create cluster --name dev
 3
 4# 2. 部署 Deployment + Service
 5kubectl create deployment nginx --image=nginx:stable-alpine
 6kubectl expose deployment nginx --port=80 --type=ClusterIP
 7
 8# 3. 驗證
 9kubectl get pods,svc,deploy
10kubectl port-forward svc/nginx 8080:80

日常操作與決策形狀

kubectl 核心指令

子議題：

• 資源生命週期：apply / create / delete / get / describe / logs / exec
• Rolling update：set image / rollout status / rollout undo
• Debug：events / port-forward / cp / top
• 對應指令範例：kubectl get pods -A、kubectl describe pod <name>、kubectl logs -f

Workload 設計

Pod lifecycle 是 K8s 的核心抽象。子議題：

• Deployment（stateless）/ StatefulSet（stateful）/ DaemonSet（per-node）/ Job / CronJob
• Pod 多 container（sidecar / init container）
• 對應 5.2 K8s deployment

Probe / Resource limit / QoS

子議題：

• Liveness（活著嗎）/ Readiness（接流量嗎）/ Startup（啟動完了嗎）— 三 probe 各自責任
• Resource limit（requests / limits）+ QoS class（Guaranteed / Burstable / BestEffort）
• 對應 Platform lifecycle contract

進階主題（按需閱讀）

Rolling update / disruption budget

對應案例 5.C9 反例：cutover without drain。子議題：

• maxSurge / maxUnavailable 配置
• PodDisruptionBudget 限制 voluntary disruption
• Preemption / priority class

Ingress / Service mesh integration

子議題：

• Ingress controller 選擇（nginx / Traefik / ALB Controller）
• Gateway API（next gen Ingress）
• Service mesh integration（Envoy-based Istio / Linkerd）
• 對應 5.C7 Airbnb Istio

Operator pattern / CRD

子議題：

• CRD（CustomResourceDefinition）+ Controller 模式
• Operator framework（OperatorSDK / kubebuilder）
• 常見 Operator：Prometheus / Cert-manager / Argo CD

Managed vs self-managed

對應案例 5.C1 Tradeshift self-managed → EKS、5.C2 Condé Nast EKS、5.C3 Orbitera managed K8s、5.C4 Mobileye EKS、5.C5 Miro EKS。子議題：

• Self-managed（kubeadm / Cluster API）的 control plane 維運成本
• Managed（GKE / EKS / AKS）的限制（版本鎖定 / managed addon）
• 遷移路徑跟回退設計

Multi-cluster / Federation

子議題：

• Federation v2 / Cluster API multi-cluster
• Cross-cluster service mesh（Istio multi-cluster）
• 對應 5.C6 Airbnb cluster scaling

Cluster autoscaling

子議題：

• Horizontal Pod Autoscaler / Vertical Pod Autoscaler
• Cluster Autoscaler / Karpenter
• 跟 09 performance capacity 對照

排錯快速判讀

Pod stuck（Pending / CrashLoopBackOff）

操作原則：先 kubectl describe pod 看 events、再 kubectl logs 看 container 訊息。

1kubectl describe pod <name>           # 看 Events 段的 scheduling / pull / probe 訊息
2kubectl logs <name> --previous        # 看 crash 前一輪的 container log

判讀路徑：Pending → resource 不足 / nodeSelector 不匹配；CrashLoopBackOff → exit code + log 找原因。

Probe failure 造成不停 restart

操作原則：probe path / initial delay / timeout 配置錯。判讀：describe pod 看 probe events。

OOMKilled

操作原則：memory limit 太低、container 被殺。判讀：describe pod 看 last state reason。修法：raise limit 或優化 application memory。

Rolling update stuck

對應 5.C9 反例。判讀路徑：新 pod 起不來 → readiness 失敗 → 舊 pod 不下線 → 卡住。

Drain timeout

操作原則：kubectl drain 失敗、PDB 限制太緊。判讀：kubectl describe pdb。

何時改走其他服務

不在本頁內的主題

• 完整 kubectl 指令 reference
• YAML manifest 完整 schema
• 各 Operator 細節
• 各語言 client-go API

案例回寫

直接相關案例

下一步路由

• 上游概念：5.2 K8s deployment
• 平行 vendor：Docker、Envoy
• 下游能力：6 reliability（release gate）、8 incident response

image 與建置責任

image 的責任是固定依賴、執行入口與檔案結構，讓同一版本在不同環境行為一致。建置流程要回答三件事：基底映像是否可維護、建置產物是否可追溯、敏感資訊是否被隔離。

映像層數、套件來源、編譯參數都會影響啟動時間與安全邊界。部署策略在後面才有效，前提是 runtime 產物本身可預測。

基底映像選擇

基底映像（base image）決定 image 的安全維護基線與啟動時體積。選擇的核心取捨是體積 / 啟動速度與除錯便利性：

• 語言官方映像（python:3.12、node:20）：套件齊全、除錯方便，但體積大（通常 800MB+）、攻擊面廣。適合開發環境與 CI。
• slim / alpine 變體（python:3.12-slim、node:20-alpine）：體積壓到 100-200MB、啟動快、攻擊面小。代價是缺少除錯工具（strace、curl、dig），生產事故時 exec 進容器排查會受限。Alpine 用 musl libc 而非 glibc，某些 C extension 需要額外處理。
• distroless（gcr.io/distroless/base）：只包含 runtime 必要檔案，無 shell、無套件管理器。攻擊面最小，但除錯只能靠 ephemeral debug container 或外部觀測。適合安全要求高且觀測基礎建設完備的生產環境。
• 自建基底：組織統一維護的基底映像，可以固定安全基線、預裝觀測 agent、統一 timezone / locale。代價是基底維護本身是持續工作，版本更新節奏要有明確 owner。

選完基底後要確認兩件事：upstream 的更新節奏是否可追蹤（CVE 修補從上游到自家 image 的時間），以及團隊是否有能力在基底更新後快速重建並驗證所有服務 image。

建置可重現性

同一份 source code 在不同時間建置出不同 image，會讓 rollback 的假設失效——「回退到上一版」回退的是哪一版，取決於當時 build 環境的狀態。

可重現建置的關鍵實踐：

1. 鎖定依賴版本：go.sum、package-lock.json、poetry.lock 要進 git。依賴解析在建置時不從 registry 重新 resolve。
2. Multi-stage build：把建置環境（compiler、dev dependencies）和執行環境分開。最終 image 只包含 runtime 必要檔案，體積小且攻擊面收窄。
3. 避免 image 中殘留敏感資訊：build arg、環境變數、中間層都可能殘留 secret。secret 不進 Dockerfile，用 runtime mount 或 secret manager 注入。
4. image 標記策略：latest tag 不可重現——同一個 tag 指向的 image 會隨時間改變。用 git commit SHA 或語意版本號標記，讓每個 tag 指向唯一 image。

對應 5.C3 Orbitera managed K8s migration：揭露「跨平台遷移本質是能力遷移」。遷移到新平台時，CI/CD pipeline 可能換了 runner 環境、換了 registry——建置可重現性的前提是依賴鎖定與 multi-stage build 本身不依賴特定 CI 環境。

entrypoint 與啟動行為

entrypoint/command 的責任是定義容器如何啟動與退出。啟動流程應顯式處理初始化步驟、配置載入、依賴檢查與失敗退出。退出流程應處理信號中斷、在途請求收斂與資源釋放。

若啟動行為隱藏在 shell script 且無可觀測訊號，部署平台很難判斷 readiness 與失敗原因。

PID 1 與信號處理

容器內 PID 1 有特殊語意：它是 init process，負責接收平台送來的 SIGTERM / SIGINT 並轉發給子進程。PID 1 的問題出在三種情境：

Shell 作為 PID 1：ENTRYPOINT ["sh", "-c", "java -jar app.jar"] 讓 sh 成為 PID 1。SIGTERM 送到 sh、sh 預設不轉發、java 進程收不到信號、等到 terminationGracePeriodSeconds 到期後被 SIGKILL 強殺。修法是用 exec 或直接用 exec form：ENTRYPOINT ["java", "-jar", "app.jar"]。

多進程容器：一個容器跑多個進程時，PID 1 要負責信號轉發與子進程回收（zombie reaping）。如果 PID 1 不做 wait()，結束的子進程會變成 zombie。解法是用 tini 或 dumb-init 作為輕量 init，或在 Kubernetes 設 shareProcessNamespace: true 讓 kubelet 處理。

啟動腳本的信號遮蔽：entrypoint script 在初始化階段（下載 config、等依賴就緒）捕捉 SIGTERM 做清理，但如果清理邏輯卡住，整個 shutdown 會被阻塞。啟動腳本的 trap handler 要有 timeout，避免把 graceful shutdown 變成 ungraceful hang。

啟動時間對部署策略的影響

啟動時間直接影響 rollout 的最短觀察窗。一個啟動需 60 秒的服務，rollout 每批至少要等 60 秒 + 觀察窗口才能確認新版本穩定。啟動時間的組成與壓縮策略見 5.6 Platform Lifecycle Contract。

image 體積也影響啟動時間——image pull 在冷啟動（節點上沒有這個 image 的快取）時占啟動時間的顯著比例。1GB image 在 100Mbps 網路下需要 ~80 秒 pull。壓縮 image 體積同時改善啟動速度與節省 registry 頻寬。

resource limit

CPU/memory Resource Limit 隔離資源競爭並保護叢集穩態。限制過低會導致頻繁節流與重啟，過高會壓縮同節點容量並放大鄰近工作負載風險。

限制設計要依服務流量型態與 GC/執行時特性調整，並與 autoscaling、rollout 批次策略一起評估。

CPU request 與 limit 的設定策略

CPU 限制有兩個參數：request（排程保證）與 limit（硬上限）。兩者的關係決定服務在負載變動下的行為：

• request = limit（guaranteed QoS）：CPU 用量穩定可預測，不會被 throttle 也不會超用。代價是無法在閒時借用節點剩餘 CPU。適合延遲敏感的 API 服務。
• request < limit（burstable QoS）：平時用 request 保證的份額，高峰時可用到 limit。代價是當節點 CPU 競爭激烈時，所有 burstable pod 同時被 throttle，延遲會一起劣化。適合批次處理或對延遲要求不高的服務。
• 不設 limit（只設 request）：服務可用到節點全部剩餘 CPU。Kubernetes 社群近年傾向這個做法——CPU throttle 常比 CPU contention 更難排查。代價是需要良好的觀測來偵測 noisy neighbor。

Memory limit 與 OOM 的判讀

memory limit 是硬邊界——超過就 OOM kill，不走 graceful shutdown。OOM kill 的判讀分兩種情境：

真正的 memory leak：記憶體使用量隨時間單調上升，GC 無法回收。修法在程式碼層。memory limit 只是延後問題爆發，不是解法。

memory limit 設太低：服務在高峰流量下的正常記憶體使用超過 limit。常見於 JVM 服務——JVM heap + metaspace + native memory + thread stack 的總和超出 container memory limit。設 limit 時要用「峰值實際使用 + headroom」而非「平均使用」。

GC-based runtime（JVM、.NET、Go）要注意 container-aware memory 設定。早期 JVM 不認 cgroup memory limit，會按宿主機記憶體計算 heap 大小，導致 heap 配置超過 container limit。現代 JVM（Java 10+）預設啟用 container awareness（-XX:+UseContainerSupport），Go runtime 1.19+ 支援 GOMEMLIMIT。

資源設定與 autoscaling 的協同

resource request 同時決定 HPA（Horizontal Pod Autoscaler）的觸發基線。request 設太高時，CPU utilization % 會偏低，HPA 不會觸發擴容，導致服務在真正需要擴容前已經出現延遲。request 設太低時，utilization % 容易衝高，HPA 頻繁擴容，造成 pod 數量抖動。

穩定做法是先在 staging 環境跑負載測試確認服務的實際資源消耗曲線，再以 p90 負載的 CPU / memory 使用作為 request 基線。

runtime config

環境差異要顯式化才能追蹤——Runtime Config 承擔這個責任。配置來源、版本、更新節奏都應可追蹤。高風險設定需配合 Config Rollout 策略，避免同批大規模變更。

runtime 配置與映像版本要保留相容窗口，讓部署與回退可分步進行。

配置注入方式與取捨

配置注入容器有三條路徑，各自有不同的版本追蹤與更新語意：

環境變數最簡單但更新需要 restart。ConfigMap mount 可以動態更新但應用要能偵測檔案變化並 reload。外部 config store（Consul KV、AWS AppConfig、Feature Flag service）最靈活但引入了額外依賴。

設定變更跟 image 變更走不同路徑時，要確保兩者的版本可以交叉相容。版本 v2 的 image 搭版本 A 的 config 能跑、版本 v1 的 image 搭版本 B 的 config 也能跑——rollback image 但 config 沒回退、或 rollback config 但 image 沒回退的情境下、服務不應崩潰。這個相容窗口的設計責任見 5.7 Config Boundary。

遷移期的 Runtime 穩定性

對應 5.C5 Miro managed EKS 遷移：揭露「平台託管化的價值在讓團隊把心力從底層維護轉到交付效率與可靠性策略」。遷移到 managed 平台後，runtime 層面的變化包含 container runtime 版本（containerd vs Docker shim）、node OS、storage driver、network plugin。這些變化可能改變 image pull 速度、filesystem 行為、DNS 解析路徑。

遷移前後的 runtime 驗證應包含：

1. image pull 時間比較：新 registry / 新 node 的 pull 速度是否在 startup timeout 內。
2. filesystem 行為：log 寫入路徑、tmp 目錄、volume mount 行為在新 runtime 下是否一致。
3. DNS 解析：新叢集的 CoreDNS / node-local DNS 設定是否影響服務的依賴連線建立速度。
4. resource 行為：新 node type 的 CPU 架構（x86 vs ARM）、memory page size 是否影響服務性能特性。

判讀訊號

常見誤區

Container 常被簡化成「打包完就好」的步驟，結果是部署風險被後移到 rollout 階段。runtime 產物穩定性不足時，後續 probe、canary、rollback 都只能被動補救。

把資源限制設成平台預設值，也常造成高峰期不穩。限制應反映服務真實耗用模式，不應只追求表面資源利用率。

把 latest tag 當成版本標記，會讓 rollback 指向無法預測的 image。image tag 在 registry 上是 mutable——同一個 tag 可以被覆蓋指向新 image。用 immutable tag（commit SHA、content digest）才能保證 rollback 的確定性。

把所有配置都用環境變數注入，會讓設定變更跟 image 部署綁在一起。需要動態更新的設定（feature flag、rate limit 閾值）應該用 ConfigMap mount 或外部 config store，讓設定變更不需要 pod restart。

案例回寫

runtime 穩定性可用 5.C1 Tradeshift：self-managed K8s -> EKS 回寫。先看遷移期內啟動行為與資源限制如何影響切流，再對照本章檢查 image、entrypoint、limit 與 config 相容窗口。這個案例主要支撐的是「執行環境可重現性」判讀——遷移到新叢集時，image 不變但 runtime 環境變了（node OS、container runtime 版本、network plugin），runtime 穩定性的前提是 image 本身不依賴特定宿主環境的行為。

5.C5 Miro managed EKS 遷移 從另一個角度支撐：managed 平台接管 runtime 基礎設施後，container runtime 版本升級由平台控制，團隊要能驗證自家 image 在新 runtime 版本下行為一致。

若同版容器在不同節點出現分歧行為，先追建置來源與 runtime config 版本鏈，確認是依賴漂移還是環境漂移，再把關鍵證據收斂到 4.20 Observability Evidence Package。不直接支撐 service discovery TTL 或 queue replay 邏輯；若根因在定位鏈路或重播流程，應轉到 5.4 或 3.4。

跨模組路由

1. 與 5.2 的交接：部署批次與探針策略回到 Kubernetes 部署策略。
2. 與 5.3 的交接：流量進出與連線收斂回到 load balancer 合約。
3. 與 5.6 的交接：startup / readiness / drain 的生命週期定義回到 Platform Lifecycle Contract。
4. 與 4.20 的交接：啟動與資源證據回到 Observability Evidence Package。
5. 與 6.8 的交接：放行與回退條件回到 Release Gate。
6. 與 7.3 的交接：image 安全基線與攻擊面回到 7.3 入口治理與伺服器防護。

下一步路由

要把 runtime 行為接到部署收斂，接著讀 5.2 Kubernetes 部署策略。要看切流與退場條件，接著讀 5.3 load balancer 合約。要看 runtime 層的生命週期如何被平台表達，接著讀 5.6 Platform Lifecycle Contract。

本章目標

學完本章後，你將能夠：

1. 把 OS signal 轉成 root context 取消
2. 用 http.Server.Shutdown 停止接受新 request
3. 讓 worker、hub、WebSocket pump 觀察同一個停止訊號
4. 設計 shutdown timeout 與強制退出邊界
5. 測試 server 與 worker 的停止流程

【觀察】直接結束 process 會留下不確定狀態

Shutdown 的核心風險是停止流程不明確。服務可能正在處理 request、WebSocket client 仍在線、worker 正在寫資料、queue message 尚未 ack、diagnostics 還以為服務可接流量。

不完整停止常見後果：

• 新 request 在服務即將關閉時仍被接受。
• WebSocket client 沒收到 close，server 端 goroutine 殘留。
• 背景 worker 寫到一半被中斷。
• readiness 還是 200，負載平衡器繼續送流量。
• 測試結束後留下 goroutine 或開放 port。

Graceful shutdown 是讓停止策略可預期。

【判讀】shutdown 是多階段流程

Graceful shutdown 的核心流程是先停止接新工作，再讓既有工作收尾，最後釋放資源。

建議順序：

 1receive SIGINT/SIGTERM
 2        │
 3        ▼
 4cancel root context
 5        │
 6        ├── readiness becomes false
 7        ├── HTTP server stops accepting new requests
 8        ├── workers stop consuming new jobs
 9        ├── WebSocket hub unregisters clients
10        └── diagnostics/log records shutdown reason
11        │
12        ▼
13wait within timeout
14        │
15        ▼
16process exits

不同服務會有不同細節，但核心不變：停止訊號要集中，元件各自完成自己的 cleanup，整體流程要有 timeout。

【執行】signal 轉成 root context

Signal handling 的核心責任是把作業系統訊號轉成應用程式可理解的取消訊號。Go 1.16 之後可以使用 signal.NotifyContext。

1func main() {
2    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
3    defer stop()
4
5    if err := run(ctx); err != nil {
6        log.Fatal(err)
7    }
8}

ctx 是 root context。HTTP server、worker、hub、diagnostics 都應從它派生出自己的 lifecycle，而不是每個元件各自監聽 signal。

Signal handler 不應放大量清理邏輯。它只負責發出停止意圖；實際清理由各元件在自己的 ownership 邊界內完成。

【執行】HTTP server 用 Shutdown 停止接新 request

http.Server.Shutdown 的核心行為是停止接受新連線，並等待既有 request 在 timeout 內完成。它比直接 Close 更適合 graceful shutdown。

 1func RunHTTPServer(ctx context.Context, handler http.Handler) error {
 2    server := &http.Server{
 3        Addr:    ":8080",
 4        Handler: handler,
 5    }
 6
 7    errCh := make(chan error, 1)
 8    go func() {
 9        errCh <- server.ListenAndServe()
10    }()
11
12    select {
13    case <-ctx.Done():
14        shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
15        defer cancel()
16        return server.Shutdown(shutdownCtx)
17
18    case err := <-errCh:
19        if errors.Is(err, http.ErrServerClosed) {
20            return nil
21        }
22        return err
23    }
24}

Shutdown timeout 是必要邊界。沒有 timeout 的 shutdown 可能永遠等待某個卡住 request；timeout 太短則可能讓合理 request 來不及收尾。

【策略】readiness 應先變成 false

Readiness 的核心用途是控制服務是否應接新流量。Shutdown 開始後，readiness 應先變成 false，再停止 server 或等待既有工作。

 1type Lifecycle struct {
 2    shuttingDown atomic.Bool
 3}
 4
 5func (l *Lifecycle) BeginShutdown() {
 6    l.shuttingDown.Store(true)
 7}
 8
 9func (l *Lifecycle) Ready() bool {
10    return !l.shuttingDown.Load()
11}

Signal 收到後：

1lifecycle.BeginShutdown()
2cancel()

這讓負載平衡器或監控能知道服務不應再接新流量。Process 還活著，但 readiness 已經反映操作狀態。

【執行】背景工作要觀察 context

背景 worker 的核心 shutdown 條件是每個 loop 都能觀察停止訊號。Ticker、queue consumer、WebSocket hub 都應該有退出路徑。

 1func RunWorker(ctx context.Context) error {
 2    ticker := time.NewTicker(time.Minute)
 3    defer ticker.Stop()
 4
 5    for {
 6        select {
 7        case <-ctx.Done():
 8            return ctx.Err()
 9        case <-ticker.C:
10            if err := RunOnce(ctx); err != nil {
11                return err
12            }
13        }
14    }
15}

若 RunOnce 可能執行很久，也應接收 context。否則外層 loop 看到 cancel，內層 I/O 或計算仍可能卡住。

【策略】WebSocket cleanup 要回到 hub owner

WebSocket shutdown 的核心原則是讓 hub 或 connection manager 統一清理 client。不要讓 signal handler 直接遍歷各種 connection 並隨意 close。

 1func (h *Hub) Run(ctx context.Context) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            h.closeAllClients()
 6            return
 7        case client := <-h.register:
 8            h.registerClient(client)
 9        case client := <-h.unregister:
10            h.unregisterClient(client)
11        }
12    }
13}

closeAllClients 應透過 hub 的既有 owner 邏輯關閉 send、移除訂閱、關閉 connection。這延續前面模組的 ownership 原則。

【測試】shutdown 測試要觀察明確條件

Shutdown 測試的核心是確認停止訊號能讓元件退出，而不是等待固定時間。

 1func TestWorkerStopsOnContextCancel(t *testing.T) {
 2    ctx, cancel := context.WithCancel(context.Background())
 3    done := make(chan struct{})
 4
 5    go func() {
 6        defer close(done)
 7        _ = RunWorker(ctx)
 8    }()
 9
10    cancel()
11
12    select {
13    case <-done:
14    case <-time.After(time.Second):
15        t.Fatalf("worker did not stop")
16    }
17}

HTTP server 測試可以啟動 server 後 cancel context，確認 RunHTTPServer 回傳。測試應使用隨機 port 或 httptest.Server，避免固定 port 造成衝突。

本章不處理

本章先處理服務內部的 shutdown 順序與 cleanup owner；平台 hook、timeout 與 load balancer 合約，會在下列章節再往外延伸：

• Go 進階：Kubernetes、systemd 與 load balancer 合約

和 Go 教材的關係

這一章承接的是 goroutine lifecycle、ticker cleanup 與 platform handoff；如果你要先回看語言教材，可以讀：

• Go：goroutine：輕量並發工作
• Go：defer 與資源清理
• Go：select：同時等待多種事件
• Go：goroutine leak 偵測
• Backend：部署平台與網路入口

小結

Graceful shutdown 是多階段流程：signal 轉成 root context，readiness 先關閉，HTTP server 停止接新 request，worker 和 WebSocket hub 觀察 context 收尾，整體流程受 timeout 保護。停止訊號越集中，元件 ownership 越清楚，服務在部署、測試與本機開發時越不容易留下殘存 goroutine 或未釋放連線。

自架 vs 商業的判斷決策表用四個維度（使用者數 / 網路範圍 / 功能需求 / 合規）做二元分流。本章把光譜展開成四條路徑，讓中間的 BaaS 和 PaaS 選項浮現。Backend 選型模組已建立了完整的交付形態光譜（交付形態選型）和逐能力判斷外包深度的框架（能力級買 vs 建）。本章把那個框架特化到監控場景。

四條路徑

路徑 A 和 D 分別是光譜的兩端 — Sentry 深入、Firebase 套件和模組四 Collector 設計已完整討論。以下展開路徑 B 和 C。

路徑 B：BaaS + Serverless

APP 上線初期用 Supabase + Vercel（或 Cloudflare Workers）搭監控後端：serverless function 接收 SDK 送來的事件、驗證 schema 後寫入 Supabase 的 PostgreSQL。整條鏈路在免費方案額度內可以零成本運作。

架構差異

Serverless function 沒有常駐 process。模組四假設的 Go single binary 架構 — channel 背壓、single-writer goroutine pattern、in-memory buffer — 在 serverless 環境都不適用。每個 HTTP request 是獨立的 function invocation，沒有跨 request 的記憶體狀態。

背壓機制需要重新設計：Go collector 用 channel 容量做背壓（channel 滿回 429），serverless 版改用 DB-level 的 rate limit（PostgreSQL 的 advisory lock 或外部 rate limiter 如 Upstash Redis）或 platform-level 的 quota（Vercel 的 concurrency limit）。SDK 端的 429 處理邏輯不需要改 — 不管背壓訊號來自 channel 還是 DB quota，SDK 都是收到 429 後降採樣。

Downsample 和 purge 在 Go collector 是 background goroutine 定期執行。Serverless 沒有 background job — 需要外部 cron trigger（Vercel Cron / Supabase pg_cron / GitHub Actions scheduled workflow）。

免費方案限額

以下為 2026-06 查詢的各平台免費方案限額。平台定價會變動，決策前以官方定價頁為準。

Audit date: 2026-06。平台免費方案限額可能調整，決策前以官方定價頁為準。

適合情境

路徑 B 適合以下組合：APP 上線初期（使用者數 < 100）、團隊熟悉前端和 SQL 但不想管 server、想保留自訂 schema 和查詢彈性（商業 SaaS 的 schema 是 vendor 定義的）、零成本起步但未來可能遷到自架。

撞牆訊號

以下訊號出現時，代表路徑 B 的天花板已到、該評估遷到路徑 C 或 D：

連線數瓶頸：Supabase Free 的 PostgreSQL 約 20 個 concurrent connection。Serverless function 每次 invocation 開新連線，高併發時可能耗盡連線池。Supabase 內建 PgBouncer 做 connection pooling 可緩解，但免費方案的 pooler 有自己的連線上限。

Cold start 延遲：Vercel serverless function 的 cold start 約 200ms、Supabase Edge Function 約 100ms。對監控 ingestion（不是使用者面向 API）通常可接受，但如果 SDK 的 flush timeout 設得很短（< 1s），cold start 可能造成偶發超時。

Background job 限制：Downsample 和 purge 需要外部 cron。Vercel Hobby 支援最多 2 個 cron job、每個最頻繁每天觸發 1 次 — 如果需要每小時 downsample，要用 Supabase pg_cron（Free 方案支援）或外部 scheduler。

免費額度耗盡：Supabase 的 500K Edge Function invocations/月 ≈ 每天 16K requests。如果每個 request 攢批 100 筆事件，可處理每天 160 萬筆事件。超過後進入按量付費。Vercel Hobby 無明確 invocation 上限、瓶頸在 bandwidth（100GB/月）和 execution duration。

合規限制：Supabase Free 的 PostgreSQL 部署在特定 region。有 GDPR data residency 需求的 app（歐盟使用者的資料必須留在 EU）需確認 vendor 的 region 支援 — 免費方案的 region 選擇可能有限。

路徑 C：PaaS

PaaS 跑的是和完全自架相同的 Go collector 原始碼，差異只在部署方式。git push 觸發自動 build 和 deploy，平台管 server provisioning、TLS 憑證、process supervision。Collector 的 channel 背壓、single-writer pattern、SQLite storage 全部適用 — 和本機開發環境的行為一致。

Railway 和 Fly.io 都支援 persistent volume — Railway Hobby 含 1GB、Fly.io Free 含 1GB（限單 region）。SQLite 的 WAL 檔案需要持久化，persistent volume 是必要條件。Render 的免費方案沒有 persistent disk — SQLite 在每次 deploy 後重置，不適合需要保留歷史事件的場景。PaaS 平台以 container 形式運行 collector，SQLite 在 container 中的 I/O 和持久化考量見 Container 部署設計。

路徑 C 適合：想用自架 collector 但不想管 server / TLS / systemd 的團隊。程式碼完全相同，遷到自架（路徑 D）的成本接近零 — 把 binary 複製到 VPS、設定 systemd service 就完成。

路徑 C 的天花板在平台定價 — Railway Hobby 有 $5/月的資源上限、Fly.io Free 有 3 個 shared VM。流量成長到免費額度不夠時，PaaS 的按量付費和 VPS 月租費的交叉點是遷到自架的判讀訊號。

路徑間的遷移

遷移成本取決於起點和終點之間有多少層需要重寫。

路徑 B → C 或 B → D 的遷移代價主要在 collector 邏輯的重寫 — serverless function 的 request-level 處理和 Go binary 的 channel-based pipeline 是不同的架構，不能直接搬。資料層的遷移代價較低 — Supabase 的 PostgreSQL 資料可以用 pg_dump 匯出、匯入自管 PostgreSQL。

交付形態遷出的通用框架（資產線盤點、並行期設計、回切窗口）見 託管形態遷出。

外包深度對照

用 外包深度 的三層框架（managed 基礎設施 / feature SaaS / BaaS bundle）看四條路徑：

路徑 B 在外包深度上介於 managed 基礎設施和 BaaS bundle 之間 — DB 和 runtime 交給平台，但 collector 邏輯和 schema 仍由開發者控制。這和 BaaS 的「前端 SDK 直連平台資料庫」模式不同 — 監控場景的路徑 B 仍然有一個自己寫的中間層（serverless function），只是這個中間層跑在平台上而非自己的 server。

選擇建議

APP 上線初期選 B 或 A 取決於自訂需求 — 需要自訂 schema 和查詢邏輯（例如自定義 error fingerprint、行為事件命名規範）選 B，只需要開箱即用的 error tracking 或行為分析選 A。B 保留遷到自架的彈性（資料在自己的 PostgreSQL），A 的功能完成度更高（dashboard、告警、session replay 開箱即用）。

下一步路由

• 自架 vs 商業的詳細決策 → 自架 vs 商業的判斷決策表
• 自架 collector 的完整設計 → 模組四 Collector 設計
• Backend 交付形態光譜 → 交付形態選型
• 能力級買 vs 建判斷 → 能力級買 vs 建
• 外包深度概念 → 外包深度
• BaaS 概念 → BaaS
• 遷出劇本 → 託管形態遷出
• Vendor lock-in 概念 → Vendor Lock-In

觀察

Condé Nast 旗下多個小團隊各自維護獨立的 Kubernetes 環境，各團隊使用不同的 Kubernetes 版本、操作模型、部署流程與存取模式。Self-managed Kubernetes 跑在 EC2 上，每個團隊自行維護 control plane、AMI、安全修補與 IAM credential 管理（使用 kube2iam 等開源工具）。

整併後成立一個 single global platform team，遷移到 Amazon EKS。技術棧標準化為 Bottlerocket OS、VPC CNI、AWS Load Balancer Controller、IRSA（IAM Roles for Service Accounts）。Multi-tenancy 用 Kubernetes namespace 隔離，搭配 resource quotas 與 limits 防止 noisy neighbor。

結果面：搭配 CloudFront 與 AWS Global Accelerator 後，end user latency 降低達 50%。團隊可以在 guardrails 內快速建立新叢集，operational overhead 顯著降低。

判讀

平台碎片化的代價分兩層。表面層是重工——每個團隊各自處理安全修補、版本升級、credential 管理，相同工作做了 N 遍。深層是一致性缺失——不同團隊的安全基線不同，某個團隊漏修的 CVE 可能成為整個組織的入口。

整併的工程價值在於把「每個團隊各自解決平台問題」變成「平台團隊解決一次、所有團隊共用」。這個轉換的前提是平台團隊能提供足夠彈性的 multi-tenancy 模型——resource quotas 防止資源搶占、namespace 隔離防止互相影響、IRSA 讓每個 workload 有獨立的 AWS 權限而非共用 node-level credential。

kube2iam → IRSA 的切換是這個案例中安全基線提升最顯著的一步。kube2iam 依賴 iptables 攔截 metadata endpoint，在多租戶環境下有 race condition 與 credential leak 風險。IRSA 用 OIDC federation 讓每個 service account 直接取得 scoped IAM role，消除了 node-level 的 credential 共用。

策略

1. 盤點既有叢集的差異維度：Kubernetes 版本、CNI、ingress controller、credential 管理方式、部署流程、監控工具。差異清單是遷移計畫的輸入。
2. 定義統一平台基線：選定 EKS + Bottlerocket + VPC CNI + IRSA 作為所有叢集的共通配置。基線要涵蓋安全（pod 唯讀 filesystem、禁 root）、資源（quotas、limits）、網路（CNI、LB controller）。
3. 用 namespace multi-tenancy 取代獨立叢集：每個團隊一個 namespace，resource quotas 限制資源用量。這比一個團隊一個叢集的運維成本低，但需要在 namespace 層級做好隔離（NetworkPolicy、ResourceQuota、RBAC scope）。
4. 漸進切換業務流量：按 region / 市場分批遷移，每批遷移後驗證 latency 與 error rate。搭配 CloudFront 做 edge 層的流量管理。

可回寫的章節段落

• 5.2 大規模 K8s 的設計取捨：single-cluster multi-namespace 的治理單位選擇
• 5.7 Managed 平台跟團隊職責邊界：global platform team 的職責重訂
• 5.3 Load Balancer Contract：AWS LB Controller + CloudFront 的流量入口配置

引用源

• How Condé Nast modernized its container platform on Amazon EKS

對「Local dev / CI container 工具、image build pipeline、小規模 dev 環境」這條路徑、Docker 是首選。

本章目標

讀完本章後、你應該能：

1. 寫 Dockerfile + 跑 docker build / run
2. 用 multi-stage build / BuildKit 優化 image
3. 用 Docker Compose 編排 dev 環境
4. 配置 image registry + scanning + SBOM
5. 評估 Docker Desktop license 對團隊的影響、選替代（Podman / Rancher Desktop）

最短路徑：5 分鐘把 Docker 跑起來

 1# 1. 安裝（macOS 擇一）
 2brew install --cask docker            # Docker Desktop（商業企業需付費授權）
 3# brew install podman                 # 替代方案：Podman（無 daemon、免費）
 4
 5# 2. 跑 container
 6docker run -d -p 8080:80 --name web nginx:stable-alpine
 7docker ps && docker logs web
 8
 9# 3. Build + push image
10docker build -t myapp:1 .
11docker tag myapp:1 ghcr.io/<org>/myapp:1
12docker push ghcr.io/<org>/myapp:1

日常操作與決策形狀

Dockerfile 設計

子議題：

• FROM / RUN / COPY / WORKDIR / EXPOSE / CMD / ENTRYPOINT
• Multi-stage build（build stage + runtime stage 分離）
• Layer cache 設計（COPY 順序影響 cache hit）
• 對應指令：docker build --no-cache、docker history <image>

BuildKit / Buildx

子議題：

• BuildKit：新 builder、parallel + cache mount + secret + SSH agent
• Buildx：cross-platform build（amd64 / arm64）
• Cache backend（local / registry / S3 / GHA）
• 對應指令：docker buildx create --use、docker buildx build --platform=linux/amd64,linux/arm64

Docker Compose

子議題：

• docker-compose.yml：service / network / volume 配置
• 適合：local dev 多 container（DB + cache + app）
• 不適合：production（用 K8s）
• 對應 5.2 K8s deployment

進階主題（按需閱讀）

Image security / scanning / SBOM

子議題：

• Trivy / Grype / Snyk image vulnerability scanning
• SBOM 產生（syft / Docker scout）
• Sign image（cosign / notary v2）
• 對應 07 security supply chain

Image registry 選擇

子議題：

• Docker Hub（public + rate limit issue）
• 雲端：ECR / GCR / Artifact Registry / ACR
• Self-host：Harbor / GitLab Container Registry / Nexus
• 對應 image pull credentials 管理

Docker Desktop license

子議題：

• 2021 改授權：商業企業（> 250 員工 / > $10M）需付費
• 替代：Podman Desktop / Rancher Desktop / Colima / Lima
• 替代品的 daemon / rootless 差異
• 對應企業 IT 採購決策

Containerd / CRI-O 在 production

子議題：

• K8s 1.24+ 移除 dockershim、改用 containerd / CRI-O
• Docker image 跟 containerd 相容（OCI standard）
• production 不用 Docker、用 containerd

Image size 優化

子議題：

• Base image 選擇（distroless / alpine / scratch）
• Multi-stage build + layer combine
• Build context（.dockerignore）
• 跟 image scanning 跟 deploy speed 對應

Rootless / 安全強化

子議題：

• Rootless mode（Docker / Podman 都支援）
• User namespace mapping
• Seccomp / AppArmor / SELinux profile
• 對應 07 security container security

排錯快速判讀

Image build cache 不命中

操作原則：COPY 順序錯、.dockerignore 缺、變動的 layer 在前面。

1docker build --progress=plain --no-cache -t myapp:debug .   # 逐層輸出、比對哪層吃時間
2docker history myapp:debug                                  # 看每層大小

Image 過大

操作原則：base image 太重 / 沒 multi-stage / build context 過大。判讀：docker history 看 layer 大小。

Container 起不來

操作原則：docker logs + docker inspect 看 exit code + state。

Network port 不通

操作原則：-p mapping vs EXPOSE 差異、host network vs bridge network、firewall。

Volume 權限問題

操作原則：container UID 跟 host UID 不對齊、rootless mode 特別容易踩。

何時改走其他服務

不在本頁內的主題

• Dockerfile 完整 reference
• Docker Compose v2 進階配置
• Container runtime spec（runc / OCI）
• 各 registry 完整 API

案例回寫

跨 vendor 對照

待補 Docker 案例：Docker Hub rate limit incident、企業 license 遷移到 Podman 案例、image scanning supply chain 案例。

下一步路由

• 上游概念：5.1 container runtime
• 平行 vendor：Kubernetes、systemd
• 下游能力：07 security（image scanning / SBOM）

deployment、replica 與 rollout

Deployment 的責任是宣告目標狀態：期望副本數、版本、更新策略。rollout 的責任是把現況收斂到目標狀態，並在過程中維持可服務能力。這兩者分開理解後，才能在異常時判斷是目標設定問題，還是收斂過程問題。

rolling update 常用來降低單次切換風險。rolling update 的判讀重點是批次大小與節奏：每批新增多少新副本、每批回收多少舊副本、每批觀察多長時間。這些參數以服務容量曲線與回退時間目標校準、名稱本身只是工具標籤、不是判讀條件。

probe 對齊服務生命週期

probe 要對齊服務生命週期，不同 probe 有不同責任：

1. startup probe：確認服務啟動完成，避免慢啟動服務被過早重啟。
2. readiness probe：確認服務可安全接流量。
3. liveness probe：確認服務仍可維持基本運作，必要時觸發重建。

probe 設計若只回傳固定成功，rollout 期間會出現「容器在線但服務未就緒」的流量抖動。穩定做法是讓 readiness 反映依賴就緒條件，例如資料庫連線池、必要配置、關鍵背景任務狀態。

Startup probe 設計注意事項

startup probe 跟 initialDelaySeconds 解決同一個問題（避免慢啟動服務被 liveness 殺掉），但機制不同。initialDelaySeconds 是 liveness / readiness probe 的延遲啟動——在等待期間 probe 完全不跑，無法觀測啟動進度。startup probe 在啟動期間持續探測，一旦成功就交棒給 liveness / readiness，啟動失敗時能更快偵測到。

startup probe 的總容忍時間 = failureThreshold × periodSeconds。例如 failureThreshold: 30, periodSeconds: 10 給服務 300 秒啟動窗口。設計時先量測服務在最差情境下的啟動時間（冷啟動 + image pull + 依賴連線建立），再加 20-30% headroom 作為總容忍時間。

Readiness probe 的深度選擇

readiness probe 的檢查深度決定它能攔截多少「可啟動但不可服務」的狀態。三個常見層級：

1. Port check（TCP probe）：確認進程在監聽。最淺，無法偵測依賴未就緒。適合依賴簡單、啟動快的服務。
2. Dependency check（HTTP endpoint 檢查必要依賴）：確認資料庫連線池、cache 連線可用。涵蓋多數「啟動完但依賴不通」的場景。常用做法是在 /ready endpoint 內驗證必要依賴的連線狀態。
3. Deep health（業務路徑驗證）：執行一次簡化的業務查詢確認端到端通路。最深但代價最高——probe 本身消耗資源，且可能被下游延遲拖慢導致 readiness 抖動。

依賴分類（必要 / 可降級 / 觀測）的判讀框架見 5.6 Readiness 設計的核心取捨。

config rollout 與版本相容

Config Rollout 需要和應用版本一起治理。設定先行、版本後行，或版本先行、設定後行，都要保留相容窗口。相容窗口存在時，才有漸進 rollout 與快速回退空間。

跨版本配置遷移要先定義停止條件：錯誤率上升、延遲尖峰、關鍵路徑失敗或下游壓力超標。停止條件明確後，部署決策才能一致。

N-1 相容與 Feature Flag Gating

版本相容窗口的操作基線是 N-1 相容：版本 N 的程式碼可以處理版本 N-1 的設定，反之亦然。這讓 rollback 從「版本 + config 必須同時回退」降級成「版本先回退、config 稍後再處理」，回退操作的原子性要求降低。

N-1 相容的實作通常搭配 feature flag gating：新功能在程式碼中預設關閉，先部署程式碼（版本 N 上線但新功能 off），確認版本穩定後再開啟 feature flag。這讓版本部署跟功能啟用分成兩個獨立決策，rollback 時只需關 flag 而不必回退版本。

N-1 相容窗口的壽命要有明確終點。長期維護雙版本相容會累積技術債——舊欄位不能刪、舊路徑不能移除。穩定做法是在 rollout 完成 + 觀測確認穩定後設定移除 deadline，把 N-1 相容視為暫時性保護而非永久設計。設定注入方式與版本追蹤見 5.1 配置注入方式與取捨。

Autoscaling 與部署策略協同

autoscaling 在部署期間扮演容量緩衝角色。部署批次若超過服務可承受變動幅度，autoscaling 會被動補償並延長收斂時間。穩定做法是讓 rollout 節奏與容量策略同時設計：先保證服務穩態，再提高切換速度。

長連線服務或有大量背景任務的 workload，通常需要比 stateless API 更保守的 rollout 策略，並額外搭配 drain 與 reconnect 設計。

擴縮策略的演進需要版本化跟可回放。對應 5.C6 Airbnb K8s 叢集擴縮演進：揭露「擴縮策略版本化跟可回放」「不同 workload 區分擴縮政策」「容量治理跟事故指標綁定」三個方向。以下基於通用工程知識展開。

可重複套用的做法：

1. 擴縮策略進 IaC：HPA / VPA / Karpenter / Cluster Autoscaler 的配置都進 git、變更走 release flow、避免手動調整在事故後被遺忘。IaC + 自動化的 ownership 邊界見 [5.7 control plane boundary](/backend/05-deployment-platform/traffic-config-control-plane-boundary/)。
2. workload 分群擴縮：stateless API、長連線服務、batch job、background worker 對擴縮的需求不同。把不同 workload 用不同 namespace + 不同 autoscaler policy 隔離，避免一套規則套全部。
3. 擴縮事件接事故指標：HPA 觸發、scale-up 延遲、scale-down 過快、cluster autoscaler 加 node 失敗，都該在事故 timeline 上可見。回到 4.13 service topology 的擴縮事件 vs 事故區分。

分階段平台遷移

平台遷移的本質是流量跟依賴的分段切換。遷移期內新舊叢集同時存在，rollout 策略要把跨叢集流量切換納入批次節奏、視為連續多批決策。本段聚焦流量 / 依賴切換時序；遷移期的團隊職責邊界重訂見 5.7 Managed 平台跟團隊職責邊界。

對應 5.C1 Tradeshift：self-managed K8s → EKS：揭露「零停機遷移要把切換做成分段策略」「難點通常在跨叢集服務依賴跟流量切換、不在 Kubernetes API 本身」。對應 5.C4 Mobileye workloads 遷移：揭露「分批遷移 workload、保留觀測對照」「明確切換 / 回退條件」「新平台先驗證容量跟恢復節奏」。以下基於通用工程知識展開。

可重複套用的分階段做法：

1. 新叢集 + 共通配置基線：先在新叢集上建立跟舊叢集對等的配置基線（namespace、ResourceQuota、NetworkPolicy、Ingress class、storage class），讓 workload 可以無縫部署。
2. 小流量先導服務：選擇影響面小、依賴單純的服務作為先導，先在新叢集跑完整 deployment cycle（rollout、drain、rollback 驗證）、累積信心後再擴大。
3. 可控流量分批切換：用 DNS 加權、service mesh 流量切分或 LB 規則把流量分批從舊叢集導到新叢集。每批切換後驗證 SLI 偏差、再進下一批。
4. 每批保留回退路徑：舊叢集服務不立即下線，保留作為回退目標。回退條件先驗證（rollback script、流量切回 DNS / LB 規則），再開始下一批切換。

延伸 5.C1 揭露的「跨叢集服務依賴是難點」、5.C10 中型組織判讀「服務本身切過去了、但資料面、認證面、觀測面還沒同步」也指向同類問題。跨叢集遷移最容易出的事故是「服務切過去了、依賴沒切過去」。Database、cache、message queue、observability pipeline、auth service 的切換時機要分別規劃，避免應用層在新叢集但仍跨網路打舊叢集的依賴，造成隱性 latency 或單點失效。規模差異下的同類問題見 5.C10 對照。

大規模 K8s 的設計取捨

K8s 在不同規模下的設計取捨會明顯分歧。小規模叢集追求簡單跟低運維成本，大規模叢集追求隔離跟自動化治理。同一套部署策略放到不同規模會在某個量級開始失效。

對應 9.C12 Riot Games：246 個 EKS cluster：揭露架構決策從 multi-tenant cluster 改成 single-tenant per game、Karpenter + Terraform 的 cluster 級自動化、35ms 延遲門檻 + Local Zones / Outposts 區域部署（case 中「35ms 反推 region 部署」屬作者判讀層、本章引用此推論）。對應 9.C34 GCP 130,000-node GKE cluster：揭露 control plane 極限取決於 storage backend（GCP 用 Spanner 替代 etcd）、AI workload 跟 web workload 容量規劃差異。對應 9.C33 Maersk + Bosch AKS：揭露 Maersk 工程訴求引語「focus on things that makes the most business impact」、傳統產業上 K8s 動機是治理一致性（作者判讀）、適合 single-cluster-multi-namespace。

可重複套用的取捨判讀：

1. single-tenant per workload vs single-cluster multi-namespace：高隔離需求（每個 workload 失效不能影響其他）、高延遲敏感度（需 region cluster）→ 多 cluster；治理一致性訴求（統一 release flow、合規邊界）→ 單一 cluster 多 namespace。
2. Cluster 容量極限取決於 control plane：data plane（worker nodes）擴容容易、control plane（API server、etcd / storage）擴容難、瓶頸通常在 control plane。etcd 撐 5K-10K node 後吃力、需要替換 storage backend（Spanner / PostgreSQL / 自家 KV）才能撐萬級節點（見 9.C34）。control plane 的 ownership 邊界由 5.7 control plane boundary 處理。
3. Multi-cluster 治理需要 IaC + 自動化：Terraform / Crossplane / Cluster API + Karpenter / Cluster Autoscaler 是基本工具。手動管理超過數十個 cluster 不可行。
4. AI workload 跟 web workload 容量規劃完全不同：AI workload 短時間爆量創建 Pods（萬級 / 秒）、preempt 頻繁；web workload 節點生命週期長、變動緩。把 web 經驗套到 AI workload 容量規劃會嚴重低估壓力。

關鍵判讀是「先決定 cluster 是隔離單位還是治理單位」。Riot Games 把 cluster 當隔離單位（246 個獨立 cluster），Maersk / Bosch 把 cluster 當治理單位（單 cluster 多 namespace）。同一個工具兩種用法、決定整體運維模型。

對應 5.C2 Condé Nast：EKS 平台整併與標準化：揭露多叢集整併到單一控制面的場景、跟 Maersk-Bosch 同屬「治理一致性」取捨方向（治理單位優先於隔離單位）。Condé Nast 的整併路徑是「盤點既有叢集差異 → 建立統一平台基線 → 藍綠或漸進切換業務流量」、對應前面「分階段平台遷移」段的批次節奏。

判讀訊號

常見誤區

把 Kubernetes 部署看成 YAML 套版，會忽略服務語意差異。相同 deployment 參數在不同服務上，可能代表完全不同風險。

把 probe 當成健康檢查 URL，會讓服務在邊界條件下過早接流量。probe 的工程價值在於反映服務真實可用條件。

把 cluster scale-up 想成「加 node 就好」也是常見誤判。當 cluster 規模超過 control plane 預設邊界，etcd / API server 會先撐不住，加 node 反而加重 control plane 負擔。

案例回寫

部署切換語意可用 5.C9 反例 做回寫。先看事件中的失敗是在 rollout 批次、probe 判斷、還是 drain 時序，再對照本章的 rollout 節奏與停止條件。

這個案例主要支撐的是「部署批次與切換時序」判讀，不直接支撐資料庫交易切分或 consumer 冪等；若問題落在提交一致性或重播補償，應轉到 1.3 或 3.4。

若版本已切換但錯誤率延遲上升，先回到 probe 與 config 相容窗口，再把證據欄位接到 4.20 Observability Evidence Package 與 8.19 Incident Decision Log。

跨模組路由

Kubernetes 部署策略要和觀測、驗證、事故流程同時對齊。

1. 與 5.6 的交接：startup / readiness / liveness / drain 的生命週期定義回到 Platform Lifecycle Contract。
2. 與 5.1 的交接：image、entrypoint、resource limit 的 runtime 層回到 container 與 runtime。
3. 與 5.3 的交接：流量承接與退出落在 load balancer 合約。
4. 與 5.4 的交接：endpoint 註冊與摘除回到 service discovery。
5. 與 5.7 的交接：control plane 跟 data plane 邊界落在 Traffic、Config 與 Control Plane Boundary。
6. 與 4.20 的交接：版本切換證據進入 Observability Evidence Package。
7. 與 6.8 的交接：放行與停損條件進入 Release Gate。
8. 與 8.19 的交接：部署中止與回退判斷進入 Incident Decision Log。

下一步路由

要把部署與流量切換一起治理，接著讀 5.3 load balancer 合約。要看切換失敗與回退判讀，接著讀 5.C9 反例。要看大規模 K8s 容量設計，接著讀 9.C12 Riot Games 跟 9.C34 GCP 130K-node。

本章目標

學完本章後，你將能夠：

1. 分辨 health、readiness、diagnostics 的語意
2. 設計快速穩定的 /health
3. 用 /ready 控制是否接新流量
4. 條件啟用 pprof、runtime stats 等診斷入口
5. 測試 status code 與 JSON response 合約

【觀察】所有狀態都塞進 health 會讓監控失真

Health endpoint 的核心風險是語意混亂。若 /health 同時檢查 process、database、queue、外部 API、cache、背景同步，任何依賴短暫波動都可能讓服務被判定死亡。

問題範例：

1/health
2  ├── process alive?
3  ├── database reachable?
4  ├── queue lag small?
5  ├── external API reachable?
6  └── background sync fresh?

這些問題不應全部塞進同一個 endpoint。Process 活著、可接流量、依賴降級、工程診斷，是不同操作訊號。

【判讀】health、ready、diagnostics 回答不同問題

操作 endpoint 的核心設計是每個 endpoint 只回答一個問題。

這樣切分後，某個外部依賴故障不一定要讓 process 被重啟；服務可能只是不 ready，或處於 degraded 狀態。

【執行】health endpoint 應簡單快速

Health endpoint 的核心責任是快速回答 process 是否能處理基本 HTTP request。它應該簡單、快速、穩定。

 1func HandleHealth(w http.ResponseWriter, r *http.Request) {
 2    if r.Method != http.MethodGet {
 3        http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
 4        return
 5    }
 6
 7    w.Header().Set("Content-Type", "application/json")
 8    w.WriteHeader(http.StatusOK)
 9    _, _ = w.Write([]byte(`{"status":"ok"}`))
10}

/health 不應執行昂貴查詢，也不應依賴大量下游服務。若健康檢查本身很慢，監控會把診斷工具變成新問題。

【執行】readiness 控制是否接流量

Readiness 的核心責任是回答「服務現在是否應該接新流量」。它可以檢查啟動狀態、必要依賴、shutdown 狀態。

 1type Readiness struct {
 2    ready        atomic.Bool
 3    shuttingDown atomic.Bool
 4}
 5
 6func (r *Readiness) Ready() bool {
 7    return r.ready.Load() && !r.shuttingDown.Load()
 8}
 9
10func HandleReady(readiness *Readiness) http.HandlerFunc {
11    return func(w http.ResponseWriter, r *http.Request) {
12        w.Header().Set("Content-Type", "application/json")
13
14        if !readiness.Ready() {
15            w.WriteHeader(http.StatusServiceUnavailable)
16            _, _ = w.Write([]byte(`{"status":"not_ready"}`))
17            return
18        }
19
20        w.WriteHeader(http.StatusOK)
21        _, _ = w.Write([]byte(`{"status":"ready"}`))
22    }
23}

服務啟動尚未完成、必要背景同步尚未就緒、或 graceful shutdown 已開始時，readiness 應回 503。Process 仍然活著，但不應接新流量。

【策略】dependency check 依照監控語意分層

依賴檢查的核心判斷是故障是否代表 process 應重啟。Database 暫時不可用不一定代表 process 壞掉；重啟可能無法修復，反而造成更多負載。

建議分層：

• /health：只確認 process alive。
• /ready：確認必要依賴是否足以接新流量。
• /diagnostics/dependencies：提供工程師查看細節。

診斷 response 可以包含穩定欄位：

1{
2  "status": "degraded",
3  "dependencies": {
4    "database": "ok",
5    "queue": "lagging"
6  }
7}

監控應依賴 status code 與穩定欄位，工程師再用 body 細節診斷問題。自由文字可以輔助閱讀，但不應成為監控規則的依據。

【執行】diagnostics endpoint 要條件啟用

Diagnostics endpoint 的核心用途是提供工程師排查問題的資料。pprof、runtime metrics、internal queue length、goroutine count 都屬於這類。

 1func RegisterDiagnostics(mux *http.ServeMux, enabled bool) {
 2    if !enabled {
 3        return
 4    }
 5
 6    mux.HandleFunc("/debug/runtime", HandleRuntimeStats)
 7}
 8
 9func HandleRuntimeStats(w http.ResponseWriter, r *http.Request) {
10    var stats runtime.MemStats
11    runtime.ReadMemStats(&stats)
12
13    response := map[string]any{
14        "heap_alloc":  stats.HeapAlloc,
15        "num_gc":      stats.NumGC,
16        "goroutines":  runtime.NumGoroutine(),
17    }
18
19    _ = json.NewEncoder(w).Encode(response)
20}

Diagnostics 可能揭露內部狀態、記憶體資訊、goroutine 數量、路徑與部署細節，不應公開給一般使用者。若需要長期保留，至少應限制在內網、管理 port、認證或防火牆後。

【判讀】status code 是監控合約

健康檢查的核心合約是 status code。監控系統通常先看 HTTP code 與 timeout，不會理解複雜 body。

Body 可以提供人類可讀資訊，但不應讓監控依賴自由文字。若要機器讀取，使用穩定 JSON 欄位，例如 status、reason、dependencies。

【測試】endpoint 測試要鎖定 status code

Endpoint 測試的核心是驗證 status code 與穩定 JSON 欄位，而不是完整自由文字。

 1func TestReadyReturnsUnavailableWhenShuttingDown(t *testing.T) {
 2    readiness := &Readiness{}
 3    readiness.ready.Store(true)
 4    readiness.shuttingDown.Store(true)
 5
 6    req := httptest.NewRequest(http.MethodGet, "/ready", nil)
 7    rec := httptest.NewRecorder()
 8
 9    HandleReady(readiness).ServeHTTP(rec, req)
10
11    if rec.Code != http.StatusServiceUnavailable {
12        t.Fatalf("status = %d, want %d", rec.Code, http.StatusServiceUnavailable)
13    }
14}

Diagnostics endpoint 也應測 gate 關閉時不註冊或回 404，避免診斷入口不小心暴露。

本章不處理

本章先處理 health、readiness 與 diagnostics 的語意切分；Prometheus、OpenTelemetry 與平台設定，會在下列章節再往外延伸：

• Go 進階：Observability pipeline、metrics 與 tracing

和 Go 教材的關係

這一章承接的是 pprof、runtime metrics 與 deploy readiness；如果你要先回看語言教材，可以讀：

• Go：pprof 基礎診斷流程
• Go：GC 與 memory limit
• Go：結構化日誌
• Go：graceful shutdown 與 signal handling
• Go 進階：Kubernetes、systemd 與 load balancer 合約
• Backend：可觀測性平台
• Backend：部署平台與網路入口

小結

/health、/ready、diagnostics endpoint 解決不同問題。Health 檢查 process 基本可用性，readiness 控制是否接新流量，diagnostics 支援工程排查且應限制存取。Status code 是監控合約，JSON body 是補充細節；把這些訊號混在一起會讓操作判斷與安全邊界都變模糊。

觀察

Orbitera 原本在 AWS 上以 EC2 為基礎運行 monolithic 架構，使用 EC2 + S3 + RDS + RedShift 組合。被 Google Cloud 收購後，在產品持續運作的前提下遷移到 Google Kubernetes Engine（GKE），同時從 monolith 重構為 microservices 架構。

遷移後的架構運行在 multi-zone 配置下，每個 zone 維持 3 個 replica，確保單一 zone 故障時服務不中斷。整合 Cloud SQL（取代 RDS）、Google 的 load balancer、Stackdriver（觀測）。遷移完成後取得的操作能力包含 on-demand scaling、快速部署到新 region/zone、以及快速 rollback 失敗的 build。

判讀

跨平台遷移本質是能力遷移：部署、觀測、恢復與團隊流程都需要同步重建。Orbitera 的遷移同時改變了兩個維度——平台（AWS → GCP）和架構（monolith → microservices）。雙維度同時改變放大了遷移風險，但也讓團隊避免了「先遷平台再拆架構」的兩階段成本。

這個案例揭露的隱性工作量在「能力對等重建」。原本在 AWS 上已經建好的觀測（CloudWatch → Stackdriver）、資料庫操作（RDS → Cloud SQL）、load balancing 都要在新平台上重新建立並驗證。這些能力不會隨著 workload 遷移自動出現——需要明確的 checklist 和驗證流程。

monolith → microservices 的架構重構改變了 runtime 的基本假設。Monolith 的 readiness 是單一進程啟動完成；microservices 的 readiness 涉及多個服務之間的依賴就緒。5.6 Platform Lifecycle Contract 的 readiness 設計取捨在這類重構後需要重新定義——哪些是必要依賴、哪些是可降級依賴，從 monolith 時代的「全部在同一個進程」變成需要顯式判斷。

Multi-zone HA（3 replicas/zone）是遷移後 managed 平台提供的基線能力。在 self-managed 環境下實現相同程度的跨 zone 冗餘需要大量手動配置（zone-aware scheduling、cross-zone load balancing）；managed 平台把這些收進平台層，團隊精力從「維持 HA 運作」轉向「定義 HA 目標」。

策略

1. 先驗證新平台的最小可行服務：選擇一個依賴少、風險低的服務在 GKE 上完成完整 deployment cycle（build → deploy → observe → rollback），驗證 CI/CD pipeline、觀測整合、rollback 路徑都可運作。
2. 建立能力對等 checklist：列出舊平台已有的操作能力（觀測、告警、backup、secret 管理、log 收集），逐一確認新平台有對應方案且經過驗證。未對等的能力是遷移的 blocking 條件。
3. 逐步搬遷核心工作負載：按依賴關係排序遷移批次，保留舊平台的回切路徑。每批遷移後在新平台上跑 load test 驗證容量與恢復能力。
4. 把平台能力納入日常治理節奏：遷移完成不是終點——GKE 版本升級、node pool 更新、Cloud SQL 維護窗口都要進入團隊的日常操作流程，避免遷移後進入「只部署不維護」的狀態。

可回寫的章節段落

• 5.1 Container Runtime — 遷移期的 Runtime 穩定性：monolith → microservices 改變 image 建置策略與啟動行為
• 5.6 Platform Lifecycle Contract — 遷移期的 Lifecycle 重新驗證：readiness 條件在架構重構後需重新定義
• 6.7 DR/Rollback Rehearsal：遷移後的回退路徑驗證

引用源

• Why we migrated Orbitera to managed Kubernetes on Google Cloud Platform

對「VM / bare metal 服務管理、邊緣 / appliance、單機 lifecycle + journal + cgroups」這條路徑、systemd 是 Linux 主流選擇。

本章目標

讀完本章後、你應該能：

1. 寫 service unit file、配置 Type / Restart / ExecStart
2. 設計 signal handling + graceful shutdown
3. 用 journald + journalctl 查 logs
4. 設定 cgroups v2 resource limit
5. 用 socket activation / timer 替代 inetd / cron

最短路徑：5 分鐘把 systemd service 跑起來

 1# 1. 建 unit file（需 root 或 sudo）
 2cat > /etc/systemd/system/myapp.service <<'UNIT'
 3[Unit]
 4Description=My Application
 5After=network.target
 6
 7[Service]
 8ExecStart=/usr/bin/myapp --config /etc/myapp/config.yaml
 9Restart=on-failure
10RestartSec=5
11
12[Install]
13WantedBy=multi-user.target
14UNIT
15
16# 2. 啟用 + 啟動
17systemctl daemon-reload
18systemctl enable --now myapp
19
20# 3. 驗證
21systemctl status myapp
22journalctl -u myapp -f

日常操作與決策形狀

Unit file 設計

子議題：

• Unit type：service / socket / timer / target / mount / path
• Service Type：simple / forking / oneshot / notify / dbus
• Restart：no / on-failure / on-abnormal / always
• ExecStart / ExecStop / ExecReload
• 對應指令：systemctl cat myapp.service、systemctl edit

systemctl 指令

子議題：

• Lifecycle：start / stop / restart / reload / enable / disable
• Status：status / is-active / is-enabled / list-units
• Reload after edit：daemon-reload
• 對應指令範例：systemctl status myapp、systemctl list-units --failed

journald 日誌

子議題：

• 結構化日誌（kv pairs）
• journalctl filter（-u / –since / -p / -f）
• 對應 logging：persistent vs runtime journal
• 跟外部 log forwarder（Vector / Fluent Bit）對接

進階主題（按需閱讀）

Signal handling + graceful shutdown

子議題：

• SIGTERM（default stop signal）/ SIGKILL（force kill after timeout）
• TimeoutStopSec：grace period
• 應用程式要 trap SIGTERM 做 cleanup
• 對應 Platform lifecycle contract（concept 通用）

cgroups v2 + resource limit

子議題：

• CPUQuota / MemoryMax / IOWeight / TasksMax
• Slice unit（樹狀 resource 限制）
• 跟 Kubernetes 的 resource limit 對比（K8s 用 cgroups 但抽象更高）
• 對應指令：systemd-cgls、systemd-cgtop

Socket activation

子議題：

• 用 .socket unit 持有 listening socket、service 啟動時繼承
• 啟動延遲：socket 一直在、service 按需起
• 替代 inetd
• 適合 occasional service / low-traffic

systemd timer

子議題：

• .timer unit 替代 cron
• OnCalendar / OnUnitActiveSec / RandomizedDelaySec
• 跟對應 .service unit 配對
• 比 cron 強：journal log / dependency / 失敗 restart

Portable services + systemd-run

子議題：

• systemd-run：ad-hoc 跑 transient unit
• Portable services：把 service + image 一起搬
• systemd-nspawn 容器（systemd 自家輕量容器）

跟 container 整合

子議題：

• 跑 podman container 在 systemd（quadlet / generators）
• Docker daemon 由 systemd 管
• K8s kubelet 由 systemd 管（cluster node）
• 對應 single-node container management

排錯快速判讀

Service start failure

操作原則：先 systemctl status、再 journalctl -u 看 log。

1systemctl status myapp                # 看 Active state + Main PID + 最近 log
2journalctl -u myapp --since=-5m       # 最近 5 分鐘的完整 log

Restart loop

操作原則：Restart 配置不當 + StartLimit 觸發。判讀：systemctl status 看 restart count + RateLimit。

journald disk full

操作原則：journal storage 超 SystemMaxUse 設定。判讀：journalctl --disk-usage、/etc/systemd/journald.conf 設限。

cgroup OOM

操作原則：MemoryMax 超過、系統 OOM kill。判讀：journalctl -k 看 kernel oom 訊息。

Dependency 不對

操作原則：unit 依賴 network / db 但 After= 沒設。判讀：systemctl list-dependencies myapp。

何時改走其他服務

不在本頁內的主題

• 完整 unit file directive reference
• systemd internals（dbus / pid 1）
• 各 distro systemd 版本差異
• systemd-resolved / systemd-networkd 等其他 component

案例回寫

跨 vendor 對照

待補 systemd 案例：大規模 fleet（HashiCorp Nomad 跟 systemd 整合）、IoT / edge appliance 案例、systemd portable services 落地案例。

下一步路由

• 上游概念：5.1 container runtime
• 平行 vendor：Kubernetes、Docker
• 下游能力：06 reliability（graceful shutdown）、4 observability（journald）

contract 組成

Load Balancer Contract 可以拆成四個部分：

1. routing contract：哪些路徑導向哪些服務，如何處理權重與版本。
2. health contract：哪些訊號代表可接流量，何時摘除節點。
3. connection contract：長短連線的 idle timeout、keepalive、重試規則。
4. drain contract：版本切換時如何讓 in-flight request 安全收斂。

這四個部分共同定義 rollout 的穩定性。服務端 readiness 與平台端健康檢查要對位，否則會出現「服務已啟動但尚未可服務」的切換抖動。

draining 與 shutdown

draining 的責任是讓舊實例在下線前完成現有請求。drain 視窗的 workload 分類詳見 5.6 Platform Lifecycle Contract，本段聚焦 LB 如何配合 drain：短請求 API 的 drain 視窗可較短；長連線、串流或 websocket 場景需要更長窗口與明確 reconnect 策略。

部署流程中，LB 摘流量、服務停止接新請求、服務完成在途請求、實例退出，這四步要有固定順序。順序穩定後，rollback 才能在同一套機制下運作。

timeout 與 sticky session

idle timeout 是連線資源與使用者體驗的平衡點。timeout 太短會增加重連與錯誤，太長會占用連線與資源。設定時依請求型態與峰值流量校準、按 SLI 訊號迭代閾值。

Timeout 層級串聯

一條請求路徑上的 timeout 分佈在多個層級，每層各自有預設值。全路徑的 timeout 設計原則是由外到內遞減：外層（離使用者近）的 timeout 要大於內層（離資料源近），否則外層先放棄，內層還在處理一個已經沒人等的請求。

這張表的每一層 timeout 都要比它的下一層大。如果 LB timeout 30 秒但 application 設了 60 秒，LB 會在 30 秒回 504 給使用者，但 application 仍然持有連線等 DB 回應——佔用連線資源卻無法交付結果。

timeout 設計的常見失誤是只調 LB 層：團隊看到使用者回報 timeout，直接把 LB timeout 從 30 秒調到 120 秒。結果是慢請求佔用 LB 連線更久、連線池被慢請求填滿、其他正常請求也開始排隊 timeout。穩定做法是先在 application 或 DB 層找出延遲根因，而非放大外層 timeout 來「等更久」。

sticky session 適合需要短期會話一致性的場景，但它會提高特定節點負載不均與失效轉移成本。採用 sticky policy 前要先定義會話狀態落點與失效時的回復路徑。

LB + CDN 連線生命週期協調

當 LB 上游有 CDN 時、兩層的 timeout / retry 行為要對齊、否則會出現「使用者已經 timeout 但 origin 還在處理」這類雙層不一致：

• CDN edge timeout 通常比 origin LB timeout 短（5-30 秒）— edge 認定 origin 慢就放棄。若 origin LB timeout 是 60 秒、edge 在 30 秒已放棄回 504、origin 還在處理一個沒人在意的 request。應對齊兩邊的 timeout 上限。
• CDN retry policy 在 edge miss 後若拿不到 origin response、預設不會重試（避免雙倍 origin 流量）— LB 端的 idle timeout 設計要假設「只有一次機會」、不依賴上游重試
• 長連線（WebSocket、SSE、gRPC）通常繞過 CDN — 直接連到 origin LB。這些連線的 idle timeout 跟一般 HTTP 不同、要單獨配置
• Edge cache HIT 時 LB 完全沒收到 request — 容量規劃時要把 cache hit ratio 算進 origin RPS、不是用使用者 RPS 直接 size LB

詳見 5.9 邊緣分發與靜態資源 的 origin protection 段。

切流失敗的回退判讀

切流失敗的回退判讀第一步是先分辨「平台問題」跟「流量生命週期問題」、再決定回退手法。平台問題用重啟服務恢復、流量生命週期問題用凍結切換並等待震盪收斂。回退手法錯位會把事故推進第二階段。

切流失敗的本質是 connection lifecycle 跟切換時序錯位、平台元件本身往往是健康的。對應 5.C9 反例：平台切流未先 Draining：揭露切流失敗常因 connection lifecycle 管理錯位、重啟動作會放大震盪。以下基於通用工程知識展開回退節奏。

回退節奏有兩個時序階段、性質不同。

第一階段：先讓震盪不擴大。發現切流失敗的第一動作是凍結 rollout（不再擴大切換範圍）跟恢復舊入口權重（把 LB 規則 / DNS 加權 / service mesh 流量切回舊版本主導）。新版本不立即關閉、保留作為對照證據。這個階段的目標是穩定當前狀態、為後續分析爭取時間、所有動作要在分鐘級內完成。

第二階段：再讓系統可恢復。震盪不擴大後、進入「等待 + 修正」狀態。長連線跟 reconnect 風暴需要時間消化、盲目重啟新版本實例會把重連集中在新一輪實例上、造成 thundering herd。觀察連線數、reconnect rate、5xx 趨勢回到 baseline 是進入修正階段的訊號。修正動作聚焦於 drain window、idle timeout、health check、client retry 之間的節奏錯位、找出後修正、重新進入小範圍驗證。這個階段的時間尺度通常是小時級、不能用第一階段的緊急節奏對待。

兩階段時序不能合併。把第一階段（凍結 + 切回）跟第二階段（等待 + 修正）並列執行、會在連線尚未穩定時嘗試修正、造成第二次震盪。

回退時最常見的誤判是「LB 顯示新節點 healthy = 服務可服務」。LB 的健康判斷通常是定期 health check 通過，跟「該節點能承受重連潮」是不同問題。事故中要把這兩個訊號分開看：節點層健康（health check pass）、連線層健康（reconnect rate、長連線錯誤率、tail latency）。

切流告警條件

對應 5.C9 反例 的「部署專屬告警條件」段：揭露切流期告警的三個核心訊號（批次內 5xx 突增、長連線重連率快速上升、rollback time 超過既定 RTO）。本段在 case 三條基礎上補第 4 條（per-version error rate 偏離）與操作建議。

切流期告警的核心責任是對應切流批次節奏、跟日常閾值分離。日常閾值在切流期會被切換本身的短暫波動觸發、變成 alert noise；切流期需要更嚴格的「批次內偏差」訊號。

可操作的切流期告警條件：

• 批次內 5xx 異常升高：當前批次相對於前一批的 5xx 升幅超過閾值、停止下一批。
• 長連線重連率飆升：reconnect rate 超過 baseline N 倍、暗示 drain / timeout 錯位。
• 回退時間超過 RTO：執行回退後恢復時間超過既定 RTO、升級為事故等級。
• per-version error rate 偏離：新舊版本 error rate 差距超過閾值、不收斂（屬本章補強、case 未明示）。

這些告警的閾值要在 release plan 中先定義、進事故時直接套用、避免臨時拍定。把切流告警跟一般日常告警分流到不同 channel，避免事故團隊在切流期被日常 noise 淹沒。

判讀訊號

「回退後 reconnect 風暴持續」是切流事故中最容易誤判的訊號。判讀順序：先看是否「凍結切換」已執行（rollout 是否真的停了）、再看「舊入口權重」是否回到主導比例（DNS / LB 規則是否切回）、最後看連線數曲線是否進入下降。三項都做完仍見風暴持續、才考慮新版本實例層級的問題（image / config / runtime 漂移）、而非反向重啟新版本。解凍切換的條件是「連線數曲線回到 baseline + reconnect rate 低於閾值連續 N 分鐘」、不是「等夠久了就解凍」的時間導向。

常見誤區

把 load balancer 當成「只做轉發」的元件，會忽略它在部署與事故中的決策角色。LB 設定定義了流量切換節奏、回退可行性與故障擴散速度。

Health check 跟 readiness 的混淆會在切換時暴露隱性風險。health contract 要反映服務真實 readiness — 含依賴連線池、必要 config、關鍵背景任務狀態 — 而非停在單一探針成功訊號。

把「LB 顯示節點 healthy」當作「服務可承受流量」的訊號，也是事故中的常見誤判。健康檢查通過跟承受重連潮是不同層級的訊號。

案例回寫

流量契約可用 5.C9 反例 回寫。先看事件中的摘流量順序、drain 視窗與連線重建節奏，再回到本章判讀 connection contract 與 drain contract 是否對齊。

這個案例主要支撐的是「連線生命週期與摘流量順序」判讀，不直接支撐 container build 可重現性；若根因在映像與 runtime 漂移，應回到 5.1。

當回退後錯誤率仍高或重連風暴延續，通常表示 timeout 與 sticky policy 仍在放大舊連線狀態。先重建連線生命週期時序，再把回退判斷同步到 8.19 Incident Decision Log。

跨模組路由

load balancer contract 是部署平台與操作控制面的匯流點。

1. 與 5.6 的交接：drain 的生命週期定義與 workload 分類回到 Platform Lifecycle Contract。
2. 與 04 的交接：版本切換訊號與錯誤率證據進入 Observability Evidence Package。
3. 與 06 的交接：canary 放行與回退條件進入 Release Gate。
4. 與 07 的交接：入口治理與管理面保護進入 7.3 入口治理與伺服器防護。
5. 與 08 的交接：切換與回退判斷記錄到 Incident Decision Log。
6. 與 5.9 邊緣分發 的交接：CDN 是 origin LB 的上游、edge miss 後流量進 origin LB、timeout / retry 設定要協調。

下一步路由

要把 LB 合約放進整體部署流程，接著讀 5.2 Kubernetes 部署策略 與 5.C9 反例。要把部署切換接到事故流程，接著讀 8.19 Incident Decision Log。

觀察

Mobileye 將大規模工作負載遷移到 EKS。遷移動機集中在運維一致性與可用性治理——原有環境中不同團隊各自維護部署流程，升級節奏、監控覆蓋、容量規劃的標準不統一。遷移目標是用 managed 平台統一這些操作基線，讓各團隊可以專注在 workload 本身。

遷移範圍涵蓋多種 workload 類型：API 服務、資料處理 pipeline、ML 推論服務。這些 workload 的啟動時間、資源需求、drain 條件差異顯著，同一套遷移策略無法直接套用。

判讀

工作負載遷移若缺乏分段驗證，容易在切流時放大依賴與資源風險。這個判讀的具體含義是：workload 從舊平台搬到新平台時，表面上看 pod 跑起來了、health check 通過了，但依賴路徑（資料庫連線、cache endpoint、queue consumer 註冊）可能還指向舊環境。這類錯位在小流量時不明顯，放大流量後才暴露延遲升高或認證失敗。

另一個判讀是容量假設需要重新驗證。舊平台的 resource request/limit、HPA 設定是在舊環境的 node type、網路拓樸下校準的。新平台的 node 規格、storage driver、CNI 可能不同，原本的容量假設可能過鬆或過緊。

策略

1. 分批遷移 workload、保留觀測對照：先遷移影響面小、依賴單純的 workload（如內部工具、非關鍵 API）。新舊平台同時跑相同 workload 時，比較 error rate、latency、資源使用率。觀測對照是驗證的基礎——沒有對照就無法判斷新平台行為是否符合預期。
2. 明確定義每批次切換與回退條件：每批遷移前寫下「什麼條件算成功」和「什麼條件觸發回退」。成功條件用 SLI 偏差衡量（error rate 不超過基線 + N%、p99 latency 不超過基線 + M ms）。回退條件要可操作——回退腳本事先驗證、DNS/LB 規則切回路徑事先測試。
3. 新平台先驗證容量與恢復節奏：在新平台上跑容量測試，確認 HPA 觸發、node scale-up、pod scheduling 的時間符合預期。恢復節奏驗證包含模擬 node 失效後 pod 重新調度的時間、模擬 deployment rollback 的完成時間。
4. workload 類型分群遷移：API 服務、batch job、ML 推論的遷移順序與驗證條件不同。API 服務看延遲與錯誤率；batch job 看完成時間與資料正確性；ML 推論看推論延遲與 GPU 資源分配。混在一批遷移會讓驗證條件模糊。

回退判讀

這類遷移的回退判讀重點是「回退到舊平台時，舊平台是否仍在可服務狀態」。遷移進行中若舊平台的資源已被縮減（node 數降低、monitoring 設定已移除），回退路徑就失效。穩定做法是在該批 workload 的新平台觀測窗口結束前，舊平台維持原規模不動。

下一步路由

回 5.2 kubernetes deployment 看分階段平台遷移的流量切換節奏。回 5.6 platform lifecycle contract 看不同 workload 類型的 lifecycle 差異。回 6.19 reliability readiness review 看遷移前的可靠性評估。

引用源

• Mobileye migration to Amazon EKS（原始 URL 已失效，內容基於骨架與通用工程知識擴充）

對「HTTP reverse proxy / LB、TLS termination、K8s ingress、API gateway 入門」這條路徑、nginx 是穩定首選。

本章目標

讀完本章後、你應該能：

1. 寫 nginx config（server / location / upstream）
2. 配置 TLS / mTLS + SNI
3. 設計 rate limiting + connection limit
4. 部署 ingress-nginx 到 Kubernetes
5. 評估 nginx vs nginx Plus / OSS fork（Freenginx / angie）

最短路徑：5 分鐘把 nginx 跑起來

 1# 1. 啟動 nginx（docker）
 2docker run -d --name nginx-demo -p 80:80 \
 3  -v "$(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro" nginx:stable-alpine
 4
 5# 2. 寫 reverse proxy config（nginx.conf 範例）
 6cat <<'CONF' > nginx.conf
 7events { worker_connections 1024; }
 8http {
 9  upstream backend {
10    server app:8080;
11  }
12  server {
13    listen 80;
14    location / {
15      proxy_pass http://backend;
16      proxy_set_header Host $host;
17      proxy_set_header X-Real-IP $remote_addr;
18    }
19  }
20}
21CONF
22
23# 3. reload + 驗證
24nginx -t            # test config syntax
25nginx -s reload     # reload without restart（zero-downtime config update）

日常操作與決策形狀

nginx config 設計

子議題：

• 階層：events / http / server / location / upstream
• 變數：$host / $remote_addr / $http_
• Include 拆分大 config
• 對應指令：nginx -T（dump full config）、nginx -t（test）、nginx -s reload

Reverse proxy 配置

子議題：

• proxy_pass / proxy_set_header / proxy_http_version
• proxy_buffering / proxy_request_buffering
• upstream load balancing（round_robin / least_conn / ip_hash）
• 對應 5.3 LB contract

TLS termination

子議題：

• ssl_certificate / ssl_certificate_key / ssl_protocols
• SNI（server_name + listen 443 ssl）
• mTLS：ssl_client_certificate + ssl_verify_client
• 對應 07 security TLS 章

進階主題（按需閱讀）

Rate limiting / connection limit

子議題：

• limit_req_zone + limit_req（leaky bucket）
• limit_conn_zone + limit_conn
• 跟 knowledge cards rate-limit 對照
• 對應威脅建模: 2.6 快取威脅建模

ingress-nginx for Kubernetes

子議題：

• Helm chart 部署
• Ingress resource + Annotations 配置
• ConfigMap + Snippets（power users）
• 跟 Traefik / Gateway API 對比

OpenResty / Lua extension

子議題：

• OpenResty：nginx + LuaJIT、可寫 Lua handler
• ngx_lua: access / content / log phase handler
• 適合：自訂 auth / dynamic routing
• 對應 envoy WASM extension 對比

nginx vs nginx Plus / Freenginx / angie

子議題：

• nginx OSS（F5 維護）：basic feature
• nginx Plus（商業）：active health check / dynamic config API / DNS upstream
• Freenginx：2024 社群 fork（不滿 F5 治理）
• angie：另一個 fork、多 commercial extension
• 選擇判讀：dynamic config 重要 → 看 Envoy / Plus；OSS 純社群 → Freenginx / angie

Performance tuning

子議題：

• worker_processes / worker_connections
• keepalive_timeout / keepalive_requests
• sendfile / tcp_nopush / tcp_nodelay
• 跟 09 performance capacity 對照

排錯快速判讀

502 Bad Gateway

操作原則：upstream 不可達 / 回應錯。判讀：error.log + upstream health。

504 Gateway Timeout

操作原則：proxy_read_timeout / proxy_send_timeout 超過。判讀：upstream 處理時間 vs timeout 配置。

Connection limit / 502 under load

操作原則：worker_connections 不夠、ephemeral port 耗盡、upstream keepalive 不對。判讀：netstat + nginx stub_status。

SSL handshake failure

操作原則：cipher / protocol mismatch、cert chain incomplete、SNI 不對。判讀：openssl s_client -connect host:443 -servername host。

Reload 不生效

操作原則：nginx -t 先 test、新 worker 起來舊 worker drain。若行為怪、檢查是否拿到舊 listening socket。

何時改走其他服務

不在本頁內的主題

• 完整 nginx directive reference
• ngx_lua / OpenResty 完整教學
• 各 distro nginx 版本差異
• nginx internal architecture

案例回寫

跨 vendor 對照

待補 nginx 案例：Cloudflare 為何 fork（freenginx）、大規模 ingress-nginx 客戶案例、OpenResty 在 production 的擴展案例。

下一步路由

• 上游概念：5.3 LB Contract
• 平行 vendor：Envoy、Traefik、AWS ELB
• 下游能力：07 security（TLS / WAF）、09 performance

DNS 與 registry

service discovery 常見兩種路徑：DNS 查詢與 service registry。DNS 提供簡化解析路徑，適合標準服務發現；registry 提供更細節的實例狀態與元資料，適合複雜路由與多租戶治理。

選擇重點是變更頻率與一致性需求。實例變動頻繁或跨區路由複雜時，registry 能提供更細控制；穩定內網服務可優先 DNS 路徑降低操作成本。

DNS-based Discovery 的運作與限制

Kubernetes Service 的 ClusterIP 模式是最常見的 DNS-based discovery：kube-dns / CoreDNS 回覆一個虛擬 IP，kube-proxy 用 iptables / IPVS 做 L4 負載均衡到實際 pod IP。Headless Service（clusterIP: None）則直接回傳所有 pod IP 的 A record，讓客戶端自行選擇目標。

DNS-based discovery 的限制來自 DNS 本身的語意：

1. TTL 與快取：DNS 回應帶 TTL，客戶端和中間 resolver 會快取。當 pod 被摘除但 DNS 快取尚未過期，客戶端仍會嘗試連到已不存在的 IP。Kubernetes CoreDNS 的 Service TTL 預設 30 秒，但客戶端語言 runtime 可能有自己的 DNS cache（JVM networkaddress.cache.ttl 預設 30 秒、有些版本預設 -1 代表永不過期）。
2. 無健康資訊：DNS A record 不帶健康狀態。回覆的 IP 可能對應已經 not-ready 但尚未被 endpoint controller 移除的 pod。這個時間窗口取決於 kubelet sync 頻率與 endpoint controller 的反應速度。
3. 無權重 / 元資料：DNS 不原生支援流量權重、版本標記、區域偏好。需要這些能力時要靠 service mesh 或 client-side load balancing。

DNS 路徑的工程價值在於零侵入——任何能解析 DNS 的程式碼都自動取得 discovery 能力，不需要額外 SDK 或 sidecar。缺點是控制粒度只到 IP 層，無法表達更豐富的路由語意。

Registry-based Discovery 的運作模式

Service registry（Consul、etcd、Eureka、Nacos）維護 key-value store，每個 service instance 主動註冊自己的地址、metadata 與健康狀態。Client 透過 registry API 或 local agent 取得可用 instance 清單。

Registry 的工程價值在於提供 DNS 無法表達的元資料：instance 的版本、區域、權重、標籤都可以作為路由條件。代價是所有 service 都需要 registry 連線邏輯（SDK 或 sidecar），且 registry 本身成為基礎設施依賴——registry 不可用時，新 instance 無法註冊、現有 instance 無法被發現。

Registry 跟 DNS 不互斥。常見做法是 registry 作為 source of truth，再用 DNS interface 對外提供查詢（Consul DNS Interface、CoreDNS 的 etcd plugin）。這讓簡單場景走 DNS、複雜路由走 registry API、兩者共用同一份 instance 清單。

選擇判讀框架

endpoint discovery

Internal Endpoint discovery 的責任是維持可連線目標集合。這包含註冊、健康檢查、摘除、重建後回註冊。服務端 readiness 與 discovery 健康判斷要對齊，否則會出現不可服務實例仍被路由的情況。

endpoint 變更需要可追溯訊號，讓事故期間能快速判讀是路由失真、註冊延遲，還是下游本身不可用。

註冊時序與 Readiness 對齊

endpoint 的註冊時機是 discovery 穩定性的關鍵變數。註冊太早（服務尚未 ready 就被加入可用集合）會導致客戶端打到未就緒實例；註冊太晚（服務已 ready 但尚未被 discovery 看到）會導致容量不足。

Kubernetes 的做法是把 endpoint 跟 readinessProbe 綁定：readiness pass 才把 pod IP 加入 Endpoints 物件。這個設計讓 readiness 定義直接決定 discovery 行為。但 readiness probe 的判斷到 Endpoints 更新之間仍有延遲（endpoint controller sync 週期 + kube-proxy rules 更新），這個延遲窗口內的行為要理解：

• Pod 剛從 not-ready 變 ready：endpoint controller 需要同步周期把 pod IP 加入 Endpoints → kube-proxy 更新 iptables / IPVS → 流量才會到。期間該 pod 不接流量但已可服務。
• Pod 從 ready 變 not-ready：同樣有延遲。期間客戶端仍可能打到已 not-ready 的 pod。drain 設計要覆蓋這段窗口。

摘除節奏與 Drain 的配合

endpoint 摘除不是瞬時的。從 pod 標記 not-ready 到所有 client 停止向它送流量，中間經過多個同步步驟。這段時間內，被摘除的 pod 仍會收到流量。

穩定做法是在 preStop hook 加入短暫等待（通常 5-15 秒），讓 endpoint 更新有時間傳播到所有 kube-proxy / envoy，然後再開始 graceful shutdown。這段 preStop 等待是 5.6 Platform Lifecycle Contract 中 drain 總窗口（短 API 通常 5-30 秒）的 endpoint 傳播子區間，drain 總窗口還要覆蓋 preStop 之後的在途請求收斂時間。

跨叢集 Discovery 的挑戰

對應 5.C1 Tradeshift self-managed K8s → EKS：揭露「遷移難點通常在跨叢集服務依賴與流量切換、不在 Kubernetes API 本身」。跨叢集 discovery 是遷移期的核心難題——服務 A 在新叢集、服務 B 在舊叢集，A 要能找到 B。

跨叢集 discovery 的常見做法：

1. 外部 DNS + 加權路由：兩個叢集的 service 都註冊到外部 DNS（Route 53、Cloud DNS），用權重控制流量比例。簡單但粒度粗，只能整體切、不能 per-service 切。
2. Service mesh federation：Istio multi-cluster、Linkerd multi-cluster 把跨叢集 endpoint 統一管理。粒度細、可以 per-service 切流量，但引入 mesh 的複雜度。
3. Application-level routing：應用自己管理多叢集 endpoint（通常透過 config 或 feature flag），切換時改 config。最靈活但最手動，適合遷移期的過渡方案。

遷移期最危險的狀態是「服務切過去了、discovery 沒切過去」——新叢集的服務 A 仍透過舊 discovery 找舊叢集的 B，跨網路延遲從微秒級跳到毫秒級，或在網路分區時完全斷開。discovery 切換要跟服務切換同批規劃。

failure fallback

fallback 在 discovery 層的責任是縮小定位失敗影響。常見策略包含本地快取最後可用集合、區域優先回退、受控重試與短暫降級。

fallback 設計要明確停止條件。長期依賴過期 endpoint 快取會造成隱性錯誤累積，事故期反而更難收斂。

Fallback 的三層防線

discovery 故障的 fallback 可分三層，每層有不同的代價與風險：

第一層：本地 endpoint 快取。Client 維持最後一次成功查詢的 endpoint 清單。discovery 服務不可用時，繼續用快取 endpoint。風險是快取中的 endpoint 可能已經下線或不健康。有效期要設上限——超過 N 分鐘的快取視為不可信，進入第二層。

第二層：區域降級。本區域的 endpoint 全部不可用時，降級到其他區域的 endpoint。代價是跨區延遲增加。風險是其他區域也可能因為同源故障而不可用。降級時要觀測跨區延遲是否在 SLO 內，超出則進第三層。

第三層：服務降級。discovery 完全失效時，服務本身降級——返回快取回應、靜態頁面、或明確的錯誤訊息。這一層的設計責任落在應用的 fallback 策略，discovery 只負責提供「目前無可用 endpoint」的訊號。

三層防線的共同原則是每一層都有明確的進入條件和退出條件。進入 fallback 不是終點——要持續嘗試恢復正常路徑，fallback 狀態持續時間要被觀測和告警。

判讀訊號

常見誤區

Service discovery 跟 DNS 設定的混淆，會讓註冊時序、健康判斷與摘除節奏的缺口在平時被忽略。這類缺口在平時不明顯，通常在切版、擴縮容或區域異常時集中爆發。

把 fallback 命中率視為穩定指標也容易誤判。fallback 長期偏高代表主路徑問題被遮蔽，應回頭檢查 endpoint 新鮮度與註冊健康，而不是只放寬重試。

把 DNS TTL 設成 0 試圖取得即時一致性，會大幅增加 DNS 查詢量。DNS 的設計前提是快取——TTL 0 在高流量服務下會讓 DNS server 成為瓶頸。穩定做法是設合理 TTL（5-30 秒）搭配 client-side 主動刷新。

把 JVM 的 DNS cache 當成 OS 的 DNS TTL——JVM networkaddress.cache.ttl 的預設值在不同版本不同（有些版本是 30 秒、有些是永不過期）。容器化部署時要顯式設定，避免 pod IP 變了但 JVM 還在打舊 IP。

定位邊界

service discovery 專注「找到可用實例」。當問題進入設定分發、版本切換、策略開關，責任轉到 Config Rollout 與部署策略章節。邊界分明能避免故障排查時把不同控制面混為一談。

discovery 跟 load balancing 的邊界：discovery 回答「有哪些 endpoint 可用」，load balancing 回答「在可用 endpoint 中選哪一個」。DNS round-robin 把兩者混在一起，registry-based 方案通常把兩者分開，讓 LB 策略（round-robin、least-connection、consistent hash）在 discovery 結果之上獨立運作。

案例回寫

發現與定位鏈路可用 5.C3 Orbitera：managed K8s migration 回寫。先看遷移期間實例註冊、摘除與 DNS/registry 同步節奏，再對照本章判讀 endpoint 新鮮度與 fallback 壽命是否合理。

5.C1 Tradeshift self-managed K8s → EKS 從跨叢集角度支撐：揭露遷移期的 discovery 挑戰——「難點在跨叢集服務依賴與流量切換」。遷移期 discovery 要處理新舊叢集的 endpoint 共存、切換時序、回退路徑。

這些案例主要支撐「定位集合新鮮度」與「跨叢集 discovery 同步」判讀。不直接支撐 LB 連線 timeout 或 runtime 建置一致性；若問題在連線生命週期或映像漂移，應轉到 5.3 或 5.1。

遇到「查詢成功但連線失敗率高」時，應拆成註冊時序、TTL 與快取刷新三條線同步驗證，避免把定位問題誤判成下游異常，再把證據分流到 8.18 Incident Intake & Evidence Triage。

跨模組路由

1. 與 5.2 的交接：實例註冊與可用判定回到 Kubernetes 部署策略。
2. 與 5.3 的交接：路由目標與流量合約回到 load balancer 合約。
3. 與 5.6 的交接：endpoint 註冊時序與 readiness 的對齊回到 Platform Lifecycle Contract。
4. 與 5.7 的交接：discovery 與 control plane boundary 的分責回到 Traffic、Config 與 Control Plane Boundary。
5. 與 4.13 的交接：依賴拓樸與發現信號回到 Service Topology 與 Dependency Map。
6. 與 8.18 的交接：定位故障的證據分流回到 Incident Intake & Evidence Triage。

下一步路由

要把發現機制放進流量契約，接著讀 5.3 load balancer 合約。要看部署切換如何影響可用集合，接著讀 5.2 Kubernetes 部署策略。要看 discovery 在 control plane 邊界中的定位，接著讀 5.7 Traffic、Config 與 Control Plane Boundary。

你應該看什麼

• How Microsoft Embraces Go

這個案例告訴我們什麼

1. Go 很適合平台與基礎設施工具。
2. 雲端工程很重視部署單純性與長期可維護性。
3. Go 常被放在內部治理、雲端元件與自動化流程中。

可對照的公開原始碼

• Microsoft/cobalt
• azure/osdu-infrastructure

這些公開 repo 可以用來理解 Microsoft 生態裡的雲端基礎設施與自動化工作方式。即使它們不一定只講一件產品，仍很適合對照 Go 的平台語言角色。

本章目標

學完本章後，你將能夠：

1. 用 config struct 集中載入 feature gate
2. 把外部版本偵測轉成 capability
3. 為 gate 關閉時定義降級、回錯或延後處理策略
4. 避免在程式各處直接讀環境變數
5. 同時測試 feature 開與關兩條路徑

【觀察】新功能上線需要可控行為

Feature gate 的核心需求來自生產環境差異。新功能可能只在部分部署環境可用，外部依賴可能版本不同，某些診斷入口只應在內網啟用，某些即時能力需要先灰度。

沒有 gate 時常見問題：

• 新功能只能一次性全開或全關。
• 部署環境不支援時服務直接失敗。
• 測試只能覆蓋預設路徑。
• 問題發生時無法快速降級。
• 程式各處用環境變數判斷，行為難以推理。

Feature gate 的目的是讓行為決策集中、可測、可回滾。

【判讀】feature gate 是行為合約

Feature gate 的核心語意是控制某段行為是否啟用，以及未啟用時系統要做什麼。它不只是 if，而是一個操作合約。

1type Features struct {
2    RealtimePush bool
3    Diagnostics  bool
4    Pprof        bool
5}

開關名稱應描述功能，而不是描述臨時任務。RealtimePush 比 NewCode 更能長期維護；Diagnostics 比 DebugStuff 更清楚。

Gate 應在應用啟動時集中載入，再傳給需要的元件。不要在程式各處反覆直接讀環境變數，否則測試與推理都會變困難。

【執行】集中載入 feature config

Feature config 的核心責任是把環境變數、設定檔或啟動參數轉成明確資料。

1func LoadFeaturesFromEnv() Features {
2    return Features{
3        RealtimePush: os.Getenv("FEATURE_REALTIME_PUSH") == "1",
4        Diagnostics:  os.Getenv("APP_DIAGNOSTICS") == "1",
5        Pprof:        os.Getenv("APP_PPROF") == "1",
6    }
7}

組裝時傳入元件：

 1func main() {
 2    features := LoadFeaturesFromEnv()
 3
 4    mux := http.NewServeMux()
 5    RegisterDiagnostics(mux, features.Diagnostics)
 6
 7    publisher := NewPublisher(PublisherConfig{
 8        RealtimeEnabled: features.RealtimePush,
 9    })
10
11    _ = publisher
12}

這樣功能測試可以直接建構 Features，不必依賴全域環境變數。環境變數解析只需要在 LoadFeaturesFromEnv 的測試中覆蓋。

【判讀】版本偵測要轉成能力

版本偵測的核心原則是不要讓整個程式到處比較版本字串。應把外部版本轉成 capability，內部只判斷能力。

 1type Capabilities struct {
 2    SupportsStreaming bool
 3    SupportsMetadata  bool
 4}
 5
 6func DetectCapabilities(version semver.Version) Capabilities {
 7    return Capabilities{
 8        SupportsStreaming: version.GTE(semver.MustParse("2.0.0")),
 9        SupportsMetadata:  version.GTE(semver.MustParse("2.1.0")),
10    }
11}

內部程式應寫成：

1if caps.SupportsStreaming {
2    return useStreaming(ctx)
3}
4
5return usePolling(ctx)

這比到處寫 if version >= ... 更清楚，也更容易測試。版本字串是外部事實，capability 是內部行為判斷。

【策略】gate 關閉時要有降級策略

Feature gate 的核心問題是關閉時要做什麼。常見策略包括降級、回錯、隱藏入口、排程稍後處理。

例如即時推送關閉時，可以改成保存待處理資料：

1func (p Publisher) Publish(ctx context.Context, event DomainEvent) error {
2    if p.realtimeEnabled {
3        return p.realtime.Publish(ctx, event)
4    }
5
6    return p.repository.SaveForLater(ctx, event)
7}

降級策略要符合資料語意。不能即時送出不代表可以直接丟掉重要事件。

【執行】HTTP endpoint 可用 gate 控制註冊或行為

HTTP feature gate 的核心選擇是「不註冊 endpoint」或「註冊但回明確錯誤」。兩者語意不同。

不註冊 endpoint：

1if features.Diagnostics {
2    RegisterDiagnostics(mux, true)
3}

適合診斷入口、內部工具或不希望使用者看見的功能。

註冊但回錯：

 1func HandleRealtimeExport(features Features) http.HandlerFunc {
 2    return func(w http.ResponseWriter, r *http.Request) {
 3        if !features.RealtimePush {
 4            http.Error(w, "realtime export is disabled", http.StatusNotImplemented)
 5            return
 6        }
 7
 8        startRealtimeExport(w, r)
 9    }
10}

適合公開 API，讓呼叫端知道功能存在但目前不可用。

【策略】gate 不應散落成巢狀 if

Feature gate 的核心維護風險是判斷散落在多層呼叫中，最後沒人知道功能到底何時啟用。

反模式：

1if os.Getenv("FEATURE_REALTIME_PUSH") == "1" {
2    if version >= "2.0.0" {
3        if user.Enabled {
4            // ...
5        }
6    }
7}

較清楚的做法是先組出 decision：

 1type RealtimeDecision struct {
 2    Enabled bool
 3    Reason  string
 4}
 5
 6func DecideRealtime(features Features, caps Capabilities) RealtimeDecision {
 7    if !features.RealtimePush {
 8        return RealtimeDecision{Enabled: false, Reason: "feature_disabled"}
 9    }
10    if !caps.SupportsStreaming {
11        return RealtimeDecision{Enabled: false, Reason: "streaming_not_supported"}
12    }
13    return RealtimeDecision{Enabled: true}
14}

Decision 物件讓 log、測試與錯誤回應都能使用相同 reason。

【執行】log 要記錄 gate decision

Feature gate 的核心操作需求是知道功能為何啟用或關閉。當 gate 影響行為時，應記錄穩定 reason。

1decision := DecideRealtime(features, caps)
2logger.Info("realtime decision",
3    "feature", "realtime_push",
4    "enabled", decision.Enabled,
5    "reason", decision.Reason,
6)

這能回答「功能為什麼沒有走即時推送」這類問題。Reason 應是小集合，不要塞完整錯誤字串。

【測試】開與關兩條路徑都要測

Feature gate 測試的核心規則是同時測啟用與停用路徑。只測預設值很容易讓另一條路徑壞掉。

停用路徑：

 1func TestHandleRealtimeExportFeatureDisabled(t *testing.T) {
 2    req := httptest.NewRequest(http.MethodPost, "/export", nil)
 3    rec := httptest.NewRecorder()
 4
 5    handler := HandleRealtimeExport(Features{RealtimePush: false})
 6    handler.ServeHTTP(rec, req)
 7
 8    if rec.Code != http.StatusNotImplemented {
 9        t.Fatalf("status = %d, want %d", rec.Code, http.StatusNotImplemented)
10    }
11}

啟用路徑：

 1func TestDecideRealtimeEnabled(t *testing.T) {
 2    decision := DecideRealtime(
 3        Features{RealtimePush: true},
 4        Capabilities{SupportsStreaming: true},
 5    )
 6
 7    if !decision.Enabled {
 8        t.Fatalf("realtime should be enabled, reason %q", decision.Reason)
 9    }
10}

環境變數解析應單獨測 LoadFeaturesFromEnv。功能測試應直接傳入 Features，不要依賴全域環境狀態。

本章不處理

本章先處理服務內部的 gate 行為邊界；遠端 feature flag 平台與灰度流程，會在下列章節再往外延伸：

• Backend：部署平台與網路入口

和 Go 教材的關係

這一章承接的是 composition root、handler boundary 與 runtime gate；如果你要先回看語言教材，可以讀：

• Go：composition root 與依賴組裝
• Go：把 handler 邏輯拆成可測單元
• Go：用 interface 隔離外部依賴
• Go：testing 基礎
• Go 進階：Kubernetes、systemd 與 load balancer 合約

小結

Feature gate 是生產操作工具，也是程式設計邊界。好的 gate 會集中載入、轉成 capability、定義降級策略、輸出穩定 reason，並同時測試開與關兩條路徑。它控制的是行為合約，不只是把新程式碼藏在 if 後面。

觀察

Miro 從自維運 Kubernetes 遷移到 managed EKS。遷移前的狀態是平台團隊大部分精力花在叢集本身的運維——control plane 升級、node AMI 維護、etcd 備份、安全修補。這些工作是必要的，但它們跟「讓開發者更快交付功能」沒有直接關聯。

遷移後 managed EKS 接管了 control plane 運維。平台團隊的工作重心從「維持叢集跑起來」轉向「定義 release flow、observability convention、developer experience」。這個轉變是 managed 平台的組織層面價值，技術層面的價值（省維運、自動升級）反而是次要的。

判讀

平台託管化的價值在讓團隊把心力從底層維護轉到交付效率與可靠性策略。這個判讀成立的前提是組織主動重新定義職責邊界——managed 平台不會自動帶來組織轉型，它只是移除了一類維運負擔。如果平台團隊在遷移後沒有重新定義職責，很容易繼續用舊模式工作（只是工作量少了），錯失把省下的精力轉到更高價值工作的機會。

另一個判讀是 managed 平台引入新的 grey zone。control plane 由供應商管理，但 cluster-internal 元件（CNI、ingress controller、service mesh、cluster DNS）的 ownership 需要顯式界定。Miro 的經驗顯示這些 grey zone 若不在 day-1 處理，後續會在事故時暴露——「以為供應商在管」跟「供應商認為客戶在管」的認知差距，會讓故障排查繞圈。

策略

1. 先定義遷移後的平台責任邊界：列出四層責任矩陣——cluster 層（供應商管）、cluster-internal 層（platform team 管）、application 層（service team 管）、跨層議題（協作）。每層有明確 owner，避免 grey zone。責任矩陣的詳細結構見 5.7 Managed 平台跟團隊職責邊界。
2. 以自動化流程取代手動平台操作：遷移前的手動操作（node 升級、cert rotation、backup restore）在 managed 平台上由供應商或 IaC 接管。剩餘的手動操作（namespace provisioning、resource quota 設定、network policy review）也要自動化或流程化，避免依賴個人經驗。
3. 將 incident 與 release policy 接回平台治理：managed 平台的 incident 跟 self-managed 不同——control plane 故障由供應商處理，但供應商的 incident 訊號要進入自家的 incident timeline。release policy（升級節奏、canary 比例、rollback 條件）在 managed 平台上仍是 platform team 的責任。

回退判讀

從 managed 回退到 self-managed 的成本極高（要重建 control plane 運維能力），因此這類遷移的回退策略通常是「在 managed 平台內回退」而非「回到 self-managed」。具體做法是保留舊叢集一段時間作為 fallback，但同時接受「回到 self-managed 不是選項」的設計假設。

下一步路由

回 5.1 container runtime 看遷移後 runtime 層的變化驗證。回 5.7 managed 平台與職責邊界 看職責矩陣的完整結構。回 5.5 平台與入口威脅建模 看遷移期攻擊面變動。

引用源

• Miro on AWS containers and EKS（原始 URL 已失效，內容基於骨架與通用工程知識擴充）

對「service mesh data plane、API Gateway、advanced traffic management、gRPC / HTTP/2 / HTTP/3」這條路徑、Envoy 是首選。

本章目標

讀完本章後、你應該能：

1. 跑起 Envoy + 基本 reverse proxy config
2. 用 xDS API 動態更新 config（不 reload）
3. 配置 listener / route / cluster / filter chain
4. 看懂 Envoy access log + stats + admin endpoint
5. 評估 Envoy 直接用 vs 用 Istio / Envoy Gateway 抽象

最短路徑：5 分鐘把 Envoy 跑起來

1# 1. 啟動 Envoy
2docker run -d --name envoy-demo \
3  -p 9901:9901 -p 10000:10000 \
4  -v "$(pwd)/envoy.yaml:/etc/envoy/envoy.yaml:ro" \
5  envoyproxy/envoy:v1.31-latest

Static config 範例（envoy.yaml）：

 1static_resources:
 2  listeners:
 3  - name: listener_0
 4    address: { socket_address: { address: 0.0.0.0, port_value: 10000 } }
 5    filter_chains:
 6    - filters:
 7      - name: envoy.filters.network.http_connection_manager
 8        typed_config:
 9          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
10          stat_prefix: ingress_http
11          route_config:
12            virtual_hosts:
13            - name: backend
14              domains: ["*"]
15              routes:
16              - match: { prefix: "/" }
17                route: { cluster: service_backend }
18          http_filters:
19          - name: envoy.filters.http.router
20            typed_config:
21              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
22  clusters:
23  - name: service_backend
24    connect_timeout: 5s
25    type: STRICT_DNS
26    load_assignment:
27      cluster_name: service_backend
28      endpoints:
29      - lb_endpoints:
30        - endpoint: { address: { socket_address: { address: app, port_value: 8080 } } }
31admin:
32  address: { socket_address: { address: 0.0.0.0, port_value: 9901 } }

1# 3. 驗證 + admin endpoint
2curl http://localhost:10000                    # proxy 路徑
3curl http://localhost:9901/stats               # metrics
4curl http://localhost:9901/clusters            # upstream health
5curl http://localhost:9901/config_dump         # running config

日常操作與決策形狀

Envoy config 結構

子議題：

• Listener：listen address + filter chain
• Route：path matching + cluster routing
• Cluster：upstream endpoint discovery + load balancing
• Endpoint：實際 backend
• 對應 5.3 LB Contract

Static vs Dynamic config

子議題：

• Static：YAML 寫死、適合 dev / debug
• Dynamic（xDS）：control plane push config
• xDS protocol：LDS / RDS / CDS / EDS / SDS
• 對應 control plane：Istio / Gloo / 自寫

Admin endpoint

子議題：

• /stats / /clusters / /config_dump / /listeners / /server_info
• runtime config（/runtime_modify）
• 對應 observability 跟 debug
• 對應指令：curl admin:9901/clusters

進階主題（按需閱讀）

xDS API 細節

子議題：

• LDS / RDS / CDS / EDS / SDS / RTDS / ECDS
• ADS（Aggregated Discovery Service）統一通道
• Delta xDS（incremental）vs SOTW（State of the World）
• 對應案例 5.C7 Airbnb Istio

Filter chain（HTTP / network filter）

子議題：

• HTTP filters：router / cors / fault / rate_limit / ext_authz / jwt_authn
• Network filters：tcp_proxy / mongo_proxy / redis_proxy
• 自訂 filter（C++ / WebAssembly）
• 對應 security 模組（ext_authz）

Observability 內建

子議題：

• Access log（structured / configurable format）
• Stats（envoy 內建 metrics）
• Distributed tracing（Jaeger / Zipkin / Datadog / OpenTelemetry）
• 對應 04 observability

Envoy Gateway / Emissary / Gloo

子議題：

• Envoy Gateway：Gateway API native（CNCF project）
• Emissary（前 Ambassador）：K8s ingress + API Gateway
• Gloo：Solo.io 商業 Envoy 整合
• 選型判讀：純 K8s ingress → Envoy Gateway；商業支援 → Gloo / Emissary

Service mesh data plane

子議題：

• Istio：control plane + Envoy sidecar
• Linkerd2：自家 Rust proxy（不是 Envoy）— Linkerd2-proxy
• Cilium Service Mesh：eBPF + Envoy
• 對應 5.C7 Airbnb Istio governance

WebAssembly extension

子議題：

• WASM filter：跨語言寫 Envoy extension（Rust / AssemblyScript / Go）
• 跟 Lua（OpenResty 模式）對比
• 適合：custom auth / rate limit / metric collection

Advanced traffic management

子議題：

• Retry / Circuit breaker / Outlier detection
• Timeout（connect / request / idle）
• Traffic split（canary / blue-green / mirror）
• Rate limit（local + global）

排錯快速判讀

Config sync 失敗

操作原則：xDS control plane 連不上 / config 格式錯。判讀：admin /stats 看 update_failure、/config_dump 看當前 config。

Listener config error

操作原則：YAML 格式錯、port 衝突、bind address 錯。判讀：startup log + admin /listeners。

Cluster endpoint 全 unhealthy

操作原則：health check 失敗、SDS 沒提供 cert、network 不通。判讀：admin /clusters 看 endpoint state。

Circuit breaker trip

操作原則：upstream 失敗率 > threshold、Envoy 主動切。判讀：admin /stats 看 cb 相關 metric。

Tracing missing spans

操作原則：tracer config + sampler rate 設錯、context propagation 不對。對應 04 observability OTel。

何時改走其他服務

不在本頁內的主題

• 完整 Envoy YAML schema reference
• xDS protocol binary format
• 各 Istio / Gloo / Emissary 細節（見各自 docs）
• Envoy C++ filter 開發

案例回寫

直接相關案例

跨 vendor 對照

待補 Envoy 案例：Lyft 自家 Envoy production 案例、Stripe / Reddit 用 Envoy 邊緣案例、Envoy Gateway 早期 adopter。

下一步路由

• 上游概念：5.3 LB Contract
• 平行 vendor：nginx、Traefik
• 下游能力：04 observability OTel、07 security

服務環節問題地圖

平台弱點盤點的第一層是把服務環節跟攻擊面對齊。同一個服務交付路徑上、入口、生命週期、設定、交付節奏各自有不同失分模式。

入口暴露面

入口暴露面的主要弱點判讀是「實際可達範圍是否超過設計意圖」。容器化、service mesh、ingress controller 升級、新增 LoadBalancer 都可能無意中把內部服務暴露到公網。入口清單跟責任鏈先對齊、能避免發版本就改變了攻擊面。升級流程跟回退窗口設計見 5.7 平台元件升級的可重播流程。

入口暴露面的盤點要區分三類入口，各自有不同的失分模式：

1. 設計意圖內的入口（Ingress / LoadBalancer Service / API Gateway）：這些入口有明確 owner、有 WAF / TLS 保護。弱點在於設定漂移——port 範圍擴大、路由規則放寬、wildcard host 引入。盤點方式是定期比對實際 Ingress 規則與設計意圖。
2. 隱性入口（NodePort、hostNetwork pod、debug endpoint、metrics endpoint）：這些入口在設計時不被視為外部可達，但在特定網路拓樸下可能從外部存取。NodePort 預設 range 30000-32767 在某些雲端 security group 設定下可能對外開放。metrics endpoint（/metrics、/debug/pprof）常不帶認證、暴露服務內部狀態。
3. 暫態入口（kubectl port-forward、臨時 LoadBalancer、tunnel 測試）：開發或除錯時臨時打開的入口，使用後忘記關閉。這類入口沒有 WAF、沒有 TLS、沒有 audit log，是攻擊面中最難盤點的部分。

Tunnel 形態的入口（cloudflared、Tailscale Funnel）有獨立的弱點盤點框架，見 5.10 Outbound Tunnel 入口 的認證疊法段。

生命週期訊號

生命週期訊號的弱點聚焦於脆弱窗口期被利用：readiness 過早通過、shutdown 階段仍在處理 in-flight request、drain 視窗內接收新請求，都會把短暫的脆弱窗口拉長。

脆弱窗口的判讀要跟 5.6 Platform Lifecycle Contract 的生命週期狀態對齊：

• startup → readiness 窗口：服務正在初始化、依賴尚未驗證、安全中介軟體（WAF sidecar、auth proxy）可能還沒就緒。此時如果 readiness 過早通過讓流量進來，請求可能繞過安全層直接打到後端。
• readiness → drain 窗口：正常服務狀態，弱點集中在 readiness 條件太鬆——只檢查 port 可達但 auth middleware 沒初始化。
• drain → shutdown 窗口：服務正在收斂，此時安全元件（rate limiter、WAF）可能已停止更新規則但仍在處理請求。攻擊者若在 drain 窗口送入惡意請求，安全元件可能無法正常攔截。

設定與密鑰下發

設定與密鑰下發是最容易被忽略的維度。Image 沒變但 config / secret 變了、權限因 RBAC 漂移擴張、feature flag 在 production 偷偷開啟未經 review 的新行為。這些變更不走 release gate 的話，攻擊者有大量低噪音入口可以利用。

設定變更的弱點盤點要分兩個方向：

顯式設定變更（ConfigMap、Secret、feature flag 更新）：變更本身是可追蹤的，弱點在於 review 機制是否涵蓋高風險設定。payment endpoint、auth provider URL、rate limit 閾值、CORS 允許來源——這些設定的變更影響跟程式碼變更等量，應走同等 review 流程。設定變更的 review 與 rollout 策略見 5.7 Config Boundary。

隱式設定漂移（RBAC 逐步放寬、network policy 例外累積、service account 權限擴張）：這類變更是多次小修改累積的結果，單次變更看起來合理但累積後超出安全邊界。盤點方式是定期用 policy-as-code（OPA/Gatekeeper、Kyverno）掃描 cluster 內的 RBAC binding、network policy、pod security 設定，跟 baseline 比對偏移程度。

交付切換節奏

交付切換節奏的弱點判讀是「在不穩定窗口期、系統是否還有防禦能力」。Canary / rollout / rollback 期間 5xx 升高、connection 重建、auth 短暫失敗，會掩蓋同期間的攻擊訊號。沒有先定停損條件就推交付速度、是把切換期變成攻擊期的常見做法。

交付窗口期的防禦能力退化有兩個機制：

訊號淹沒：rollout 本身產生的短暫錯誤（5xx spike、reconnect、auth retry）跟攻擊訊號長得一樣。事故團隊在切流期把所有異常歸因於部署變更，攻擊者剛好利用這個注意力盲區。對策是把切流期 alert 跟安全 alert 分流到不同 channel，安全訊號走獨立通道、由 security on-call 獨立判讀。

防禦元件版本不一致：canary 期間新舊版本同時在線，WAF 規則、rate limit 設定、auth middleware 版本可能不同。攻擊者可以針對舊版本的已知弱點送流量，利用 canary 期間的路由特性讓流量到達舊版本。對策是把安全元件的更新跟應用版本解耦——WAF 規則、rate limit 是平台層設定，應在所有版本一致生效。

案例對照表（情境 → 判讀 → 注意事項 → 路由章節）

「外網可達入口在發版後增加」是平台變更弱點盤點的頭號議題。Ingress class 換、Service type 改、LB 規則重組都可能讓原本內部服務獲得外部 IP。把入口盤點放進 release pre-check、能讓這類變更在合併前被擋下。

「readiness 通過但實際流量錯誤率上升」揭露 readiness probe 設計失誤的弱點面向。Probe 只回 200 OK 不代表服務可承受真實流量、攻擊者剛好可以在這個窗口送高頻 request 看是否壓垮服務。Readiness 反映依賴就緒條件而非單一探針成功、能縮短這個窗口。

「設定異動與異常事件同時出現」是 config rollout 的弱點風險。Config 變更後出現異常事件、可能是設定本身的問題、也可能是攻擊者剛好利用了設定窗口。Config 審查跟責任追蹤同步維護、能讓事後復盤分辨兩者。

「切流期間入侵告警被淹沒」是新加入的議題。切流產生大量短暫 5xx、reconnect、auth retry、可能淹沒真正的攻擊訊號。把切流期 alert 跟一般 alert 分流、攻擊訊號走獨立通道、能避免攻擊在切流窗口下被忽略。

平台遷移期的攻擊面變動

對應 5.C1 / 5.C4 / 5.C5 揭露的遷移分段切換流程、本段從弱點盤點角度補充其攻擊面變動風險（case 庫未直接揭露此角度、屬通用工程經驗）。遷移期的職責邊界重訂見 5.7 Managed 平台跟團隊職責邊界、弱點盤點跟治理視角合用才完整。

平台遷移（self-managed → managed、單 cluster → 多 cluster、舊版本 → 新版本）會短期擴大攻擊面、然後逐步收斂。遷移期顯式管理攻擊面變化、避免雙軌期變成攻擊面雙倍期。

可重複套用的弱點判讀：

1. 盤點雙軌期入口：舊平台跟新平台的入口清單分別列出、確認新平台不繼承舊平台已知漏洞、舊平台的廢棄入口確實關閉。
2. identity / credential 重新對位：service account、API token、TLS cert 在新平台是否走新的 rotation flow、舊平台的 credential 是否在切換完成後撤除。
3. observability 對應更新：新平台的 audit log、access log、security event 是否進入同一個 SIEM / 告警通道、避免遷移期內攻擊訊號掉到觀測缺口。
4. 回退路徑的攻擊面評估：回退到舊平台時、舊平台是否仍處於最新 patch 狀態、回退本身會不會把已修補的漏洞重新引入。

遷移計畫要把資安 review 列為 gate 之一、讓遷移期攻擊面變動進入可見治理流程。沒有這道 gate、遷移期容易被當成純技術項目處理、漏掉攻擊面的隱性擴大。

到實作前的最後一層

弱點盤點在概念層回答的是平台風險判讀與交接節奏。當討論進入 Kubernetes 欄位、LB 規則、系統服務參數或腳本配置時，就代表已進入實作層。

實作層的防護驗證跟概念層分工：實作層看具體 YAML / config / rule 是否符合 hardening baseline、概念層看交付路徑跟責任鏈是否完整。兩者都做才能讓平台變更的攻擊面在 release 前可見。

進實作層後接 07 資料保護模組 的具體 hardening 章節、跟 7.3 入口治理與伺服器防護 對齊入口分級。

本章目標

學完本章後，你將能夠：

1. 理解 shutdown、readiness 與 connection draining 的順序
2. 看懂平台 timeout 對 Go server 的影響
3. 分辨 health 與 readiness 的不同責任
4. 把 memory limit 與 Go runtime 的資源管理接在一起
5. 讓部署平台和程式彼此遵守同一份合約

前置章節

• Go 進階：GC 與 memory limit
• Go 進階：graceful shutdown 與 signal handling
• Go 進階：健康檢查與診斷 endpoint
• Backend：Graceful Shutdown
• Backend：Failover

後續撰寫方向

1. SIGTERM、shutdown timeout、readiness false 與 connection draining 的順序。
2. Kubernetes terminationGracePeriodSeconds 與 Go http.Server.Shutdown 如何配合。
3. Load balancer idle timeout 如何影響 WebSocket heartbeat 參數。
4. Container memory limit、Go memory limit 與 OOM killer 之間的關係。
5. systemd restart policy 與 health endpoint 的責任分工。

【觀察】平台會主動改變服務生命週期

Go 程式不會在真空裡執行。Kubernetes、systemd、load balancer、container runtime 都會影響服務何時接新請求、何時開始收尾、何時被強制終止。這表示程式不只要「能跑」，還要能跟平台協調。

常見的生命週期訊號有：

• SIGTERM
• readiness false
• HTTP shutdown
• connection draining
• memory pressure

【判讀】health 與 readiness 有不同合約

health 通常表示服務自己還活著，readiness 則表示它是否適合接新流量。

• health 可以用來讓平台知道 process 還活著。
• readiness 可以用來讓 load balancer 停止送新請求。

如果兩者混在一起，部署時就容易出現「服務還沒收尾就被塞新流量」或「其實還能接流量卻被誤判下線」的問題。

【策略】shutdown 應該是可預期流程

典型的 shutdown 順序是：

1. 接收到停止訊號。
2. 先把 readiness 關掉。
3. 停止接新流量。
4. 讓現有 request / worker / websocket 收尾。
5. 超時後強制結束。

這個順序能讓平台有時間把流量移走，也讓應用有時間清理資源。

【執行】資源限制要和 runtime 觀念一起看

container memory limit 不只是部署平台的事，也會影響 Go runtime 的行為。當可用記憶體變少時，應用更需要控制：

• goroutine 數量
• buffer 大小
• cache 體積
• in-memory queue 長度

如果這些沒有限制，平台的 OOM killer 可能會比你的 graceful shutdown 先來。

【延伸】平台合約要被測試

部署平台合約需要在測試或預備環境驗證。至少要確認：

• shutdown 時 request 是否停止接入
• worker 是否有機會收尾
• WebSocket 是否有 close path
• health 與 readiness 是否分工清楚

本章不處理

本章不會完整教 Kubernetes 或 systemd 操作。重點是讓 Go 程式設計能清楚暴露平台需要的生命週期訊號。

和 Go 教材的關係

這一章承接的是 Go 的 shutdown 與 runtime 限制；如果你要先回看語言教材，可以讀：

• Go 進階：GC 與 memory limit
• Go 進階：graceful shutdown 與 signal handling
• Go 進階：健康檢查與診斷 endpoint

Vendor / Platform 清單

實作時的常用選擇見 vendors — T1 收錄 Kubernetes / Docker / systemd / nginx / Envoy / AWS ELB / Terraform / Traefik / Consul，每個 vendor 有定位、適用場景、取捨與預計實作話題的骨架。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

暫定分類

建議閱讀順序

章節編號是主題分類，不是閱讀順序。建議先讀 5.6 Platform Lifecycle Contract 理解 startup / readiness / liveness / shutdown / drain 的責任分類，再按 5.1 → 5.2 → 5.3 → 5.4 進入平台實作層。5.5（威脅建模）和 5.7（boundary 分類）適合讀完 5.1-5.4 後做概念整理。5.8（實作示範）是 5.2 + 5.3 的操作化，適合最後讀。

選型入口

部署平台選型的核心判斷是服務如何被啟動、更新、接流量、擴容與停止。當問題集中在 container image、rolling update、health check、load balancer、service registry、service discovery 或 Runtime Config 時，應先評估部署平台能力。

Container 解決服務包裝與 runtime 依賴；Kubernetes 解決多 instance 調度、probe、rolling update 與 resource limit；systemd 適合單機或 VM 上的 service lifecycle；load balancer 解決流量入口、draining、idle timeout 與 health check；service registry 解決實例狀態維護；service discovery 解決服務彼此如何找到 Internal Endpoint；Runtime Config 解決環境差異、Secret Management 與 Feature Flag。

接近真實網路服務的例子包括發版時 request 失敗、pod 尚未 ready 就接流量、長連線 shutdown 清理不完整、服務擴容後 Internal Endpoint 更新延遲。這些場景的共同問題是程式與平台合約，因此本模組會先處理生命週期、流量入口與平台訊號。

與語言教材的分工

語言教材處理程式內的生命週期與訊號。Backend deployment 模組處理 Kubernetes、systemd、load balancer 與 container 平台如何觸發、解讀與限制這些訊號。

與資安概念層的交接

本模組承接 07 模組的概念判讀，並在服務實體層落地。交接基線如下：

• 來自 7.3 入口治理與伺服器防護：承接入口分級、管理平面分離、修補窗口節奏。
• 來自 7.5 傳輸信任與憑證生命週期：承接 TLS/mTLS 與憑證佈署節奏。
• 來自 7.6 秘密管理與機器憑證治理：承接 runtime secret 與機器憑證交付模型。

這個交接讓部署模組聚焦實體配置與平台語意，同時保持與資安判讀一致。

案例驅動讀法

部署平台案例的核心讀法是先確認切換單位（服務、流量、叢集），再定義可回退邊界。

跨語言適配評估

部署平台使用方式會受語言的啟動時間、process model、signal handling、thread/task lifecycle、runtime memory behavior 與 liveness 支援影響。啟動慢的 runtime 要調整 readiness 與 rollout 節奏；長連線或背景 worker 要支援 draining；使用 GC 的 runtime 要觀察 memory limit 與 pause 行為；多 process 模型要確認 signal、log 與 metrics 如何聚合。

章節列表

反例與規模對照入口： 5.C9 反例 / 5.C10 對照。

回退判讀寫法見 0.C4 回退判讀寫法，部署案例要優先保留切流批次、draining、連線生命週期與回退時間。

觀念網路補完方向

部署平台章節下一輪的核心責任是把平台能力寫成服務契約。現有章節已經有 container、Kubernetes、load balancer 與 service discovery，但還需要補上 runtime contract、lifecycle contract、traffic contract、rollout contract 與 control-plane contract 的關係，讓讀者知道部署是一組流量、連線、設定、資源與回退條件的連續切換。

這些方向要用部署平台自己的服務壓力展開。短 request API、長連線服務、背景 worker、control plane config push 與多租戶平台的生命週期不同，寫作時要分別處理它們的 rollout 與 drain 條件。

知識卡補強方向

部署模組的 knowledge card 缺口集中在「平台契約」與「切換完成訊號」。已有 readiness、draining、config rollout 與 rollback strategy 可以作為第一批錨點。

下一批候選卡片包括 startup probe、drain completion、rollout batch、rollback window、config freeze、environment protection 與 deployment contract。這些卡片要讓讀者能分辨「服務已啟動」和「服務可安全接流量」分屬不同責任。

實作探討入口

部署平台的第一條實作路徑是 5.8 Deployment Rollout with Drain and Rollback（實作示範）。這篇以 checkout service rollout 為例，說明 rollout plan、canary evidence、drain signal、rollback condition 與 incident decision route 如何一起成立。

這條路徑的前置引用應該是 5.2 Kubernetes deployment、5.3 load balancer contract、5.C9 反例、6.8 Release Gate 與 8.19 Incident Decision Log。完成後可依 Backend 學習路線 進入下一條服務路徑。

部署路徑的 artifact 對齊重點是「每一批切換都能被觀測、被放行、被回退」。對 4.20 要交 Source/Time range/Query link/Owner/Data quality，並覆蓋 per-version error rate、latency、drain completion 與 reconnect 訊號；對 6.8 要交 Gate decision/Checks/Stop condition/Rollback window/Owner，呈現 canary 批次與停損規則；對 8.19 要交 Timestamp/Decision/Context/Evidence/Owner/Expected effect/Rollback condition，記錄 freeze、回退與重啟切流的決策條件與時間序列。

跨分類引用

• → infra 模組五：核心服務上 IaC：ECS / EKS 的 IaC 描述（subnet 接線、IAM task role、映像版本解耦）是部署平台的地基層

讀完本章後、你應該能判讀自己當前處在三層哪一階、要跨到下一階時需要補哪些議題、對應到 backend/07 哪些卡片。

本章目標

1. 區分個人 dev、團隊共用、production 三層 LLM 部署的安全議題差異。
2. 知道從個人 dev 跨到團隊共用時、需要補哪些控制。
3. 知道從團隊共用跨到 production 時、需要補哪些控制。
4. 認識每層演化對應的 backend/07 卡片清單。
5. 知道何時該停留在當前層、何時該主動升級。

三層演化的判讀軸

1個人 dev（本模組前五章）
2   ↓
3團隊共用（家裡 / 小團隊 / 內部部署）
4   ↓
5production 服務（對外服務 / SaaS / B2B）

三層的核心差異：

關鍵原則：控制機制應該跟需求對齊、不該過度設計也不該不足。個人 dev 不需要 SOC 2 audit、production 不能只靠 git track。

個人 dev → 團隊共用：要補什麼

從個人 dev 跨到團隊共用、典型的觸發場景：

1. 家裡跑模型給家人 / 室友用
2. 小團隊共用一台 LLM server
3. 公司內部部署、有 5 ~ 50 個工程師用

需要補的控制（在前五章的基礎上）：

團隊共用階段的常見 anti-pattern：

1. 把個人 dev 的 dotfile config 直接複製到團隊 server：API key、log 路徑、reset 機制都不對。
2. 依賴單一管理員口頭傳遞政策：沒寫下來、新成員不知道、人離職就失傳。
3. 跳過 auth 直接用「公司內網本來就安全」當理由：內網設備有訪客、有實習生、有 BYOD、有合作廠商；零信任的最低版本仍要做。

團隊共用 → production：要補什麼

從團隊共用跨到 production 服務、典型的觸發場景：

1. 把內部 LLM 服務開放給外部客戶（B2B）
2. 做 SaaS-like LLM API 對外賣
3. 把 LLM 嵌入產品給終端用戶用

需要補的控制（在前面兩層的基礎上）：

production 階段不是「把團隊共用放大」、是「另一個複雜度等級」。多數議題從 backend/07 既有卡片開始讀、LLM-specific 議題在 backend/07 的 LLM 相關章節（llm-*.md）補充。

何時該停留在當前層

不是所有工作流都需要升級。停留在當前層的合理判讀：

升級的兩個常見錯誤：

1. 過早升級：個人 dev 階段就上 enterprise stack（IAM、Vault、SIEM）、複雜度過高、自己用不到、維護成本反而傷工作流。
2. 過晚升級：團隊共用階段該補的控制沒補、出事才補、可能已經有資料外洩 / 法律責任。

判讀依據：控制機制對齊實際 threat model 跟 user 規模、不是「越多越好」。

跨層升級的常見 anti-pattern

從各層往上跨時、常見的意外：

1. 把個人 dev 的 LLM client config 直接放上 production：autocomplete model、default model、API key 都不對；production 場景需要重新設計 model 路由。
2. 把個人習慣的 prompt injection 防護當 production 防護：「我 git track 工作流」對個人 dev 夠、production agent 場景下、git 不在迴路裡、要改用 tool spec + review checkpoint。
3. production 場景仍然依賴使用者「看 prompt 內容」：使用者數量大、不可能每個 prompt 都人工看；production 需要自動化偵測訊號。
4. production 場景沒 tenant 隔離：所有用戶的 KV cache / log / context 混在一起、A 用戶能看到 B 用戶的 cache hit。
5. 沒有 vendor 政策的書面化承諾：team 階段口頭講「我們不訓練客戶資料」、production 階段要寫進條款 / SLA。

給讀者的層級判讀清單

判斷自己當前在哪一層：

1[ ] 只有自己用                                              → 個人 dev
2[ ] 1 ~ 5 個人共用一台 server                                → 個人 dev 或團隊共用初期
3[ ] 5 ~ 50 個人共用、內部部署                                → 團隊共用
4[ ] 對外提供 API 服務 / SaaS                                 → production
5[ ] 服務多個客戶 / 涉及客戶 PII                              → production
6[ ] 有 SLA / 合約承諾                                        → production

對應的「要補的議題」：

 1個人 dev → 團隊共用：
 2  [ ] auth                  ← backend/07 identity-access-boundary
 3  [ ] 入口治理               ← backend/07 entrypoint-and-server-protection
 4  [ ] TLS                    ← backend/07 transport-trust-and-certificate-lifecycle
 5  [ ] secret 集中管理        ← backend/07 secrets-and-machine-credential-governance
 6  [ ] 內部 supply chain      ← backend/07 supply-chain-integrity-and-artifact-trust
 7  [ ] 寫下 acceptable use 政策
 8
 9團隊共用 → production：
10  [ ] 多租戶 isolation       ← backend/07 llm-multi-tenant-isolation
11  [ ] deployment 供應鏈      ← backend/07 llm-deployment-supply-chain
12  [ ] agent prompt injection ← backend/07 llm-prompt-injection-in-agent
13  [ ] log / PII 治理         ← backend/07 llm-log-and-pii-governance
14  [ ] 偵測訊號               ← backend/07 llm-as-service-detection-coverage
15  [ ] workload identity      ← backend/07 workload-identity-and-federated-trust
16  [ ] 偵測平台               ← backend/07 detection-coverage-and-signal-governance
17  [ ] IR 流程                ← backend/07 incident-case-to-control-workflow
18  [ ] 合規                   ← backend/07 data-protection-and-masking-governance

下一步

本章是模組六的最後一章。下一步可以回到 模組六 _index 看其他章節、或進入 Backend 模組七 資安與資料保護 接 production 場景。

Lifecycle Contract

Lifecycle contract 定義平台如何啟動、檢查、接流量、停止與回收服務實例。它包含 runtime、startup、readiness、liveness、shutdown 與 drain。

這些狀態分開後，部署事故才能定位是啟動、接流量、退場還是平台判讀問題。

runtime 與 startup 決定服務能否形成可運行實例。readiness 與 liveness 決定平台何時導入流量與何時重建實例。shutdown 與 drain 決定版本退場時是否能保護在途工作。這些狀態都屬於生命週期合約，卻對應不同的事故處理路徑。

Startup 與 Readiness

startup 的責任是確認服務初始化完成。readiness 的責任是確認服務可承接實際流量。啟動完成不代表依賴已就緒，也不代表背景任務、config、secret 或 connection pool 都可用。

慢啟動服務需要 startup gate，避免 liveness 在初始化期間反覆重啟。依賴敏感服務需要 readiness gate，避免尚未連上資料庫、cache 或 queue 時就接收請求。

啟動時間的組成與壓縮

服務啟動時間的長短決定 rollout 節奏的下限。啟動時間由四段組成，每段有不同壓縮策略：

1. runtime 初始化：語言 VM、GC 初始化、class loading（JVM warmup 可達 10-30 秒）。壓縮手段是 ahead-of-time compilation（GraalVM native image、Go 靜態編譯啟動速度快）或 CDS（Class Data Sharing）。
2. 依賴建立：資料庫連線池、cache 連線、queue consumer 註冊。壓縮手段是 lazy initialization（按需建立）或 connection pool pre-warming（啟動時建好但不阻擋 readiness）。
3. 資料預載：config 同步、feature flag 初始拉取、本地快取預熱。壓縮手段是區分必要載入與非必要載入——必要的阻擋 readiness，非必要的平行載入。
4. 就緒驗證：自我健康檢查、依賴可達性驗證。壓縮手段是平行驗證多個依賴，避免串行等待。

啟動時間超過平台預設 startup timeout 時，先拆成這四段分析瓶頸，再決定調大 timeout 還是壓縮啟動流程。盲目調大 timeout 會掩蓋啟動退化問題，讓單次 rollout 的最短觀察窗拉長。

Readiness 設計的核心取捨

readiness 太鬆（只檢查 HTTP port 是否可達）會讓尚未就緒的實例接到流量。readiness 太緊（檢查所有下游可達性）會讓非自身問題的下游故障觸發連鎖 not-ready，放大故障面。

取捨的判讀框架是「這個依賴不可用時，服務是否仍能提供有意義的回應」：

• 必要依賴：資料庫、auth service——不可用時服務完全無法處理請求。這類依賴的可達性應納入 readiness 條件。
• 可降級依賴：推薦引擎、非關鍵 cache——不可用時服務可回傳降級結果。這類依賴不應納入 readiness，改用 circuit breaker 或 fallback 處理。
• 觀測依賴：metrics collector、log shipper——不可用不影響業務流量。這類依賴進 readiness 是常見誤判，會讓觀測基礎設施故障擊倒整個服務。

對應 5.C3 Orbitera managed K8s migration：揭露「跨平台遷移本質是能力遷移、部署 / 觀測 / 恢復與團隊流程都需要同步重建」。遷移到新平台時，舊平台的 readiness 條件不能直接搬——新平台的依賴可達路徑、DNS 解析速度、secret 注入方式可能改變，readiness 條件要重新驗證。

Liveness 與 Restart

liveness 的責任是偵測無法自我恢復的狀態。短暫下游故障適合交給 readiness、circuit breaker 或 fallback 處理，否則平台會用重啟放大故障。

liveness 太敏感會造成 restart loop；liveness 太寬鬆會讓壞實例長期留在線上。設計時要先定義哪些錯誤可由服務內部恢復，哪些才需要平台重建。

Liveness 適合偵測的失敗模式

liveness 的工程價值在於捕捉服務自己無法修復的狀態。把 liveness 當成通用健康檢查是過度使用，會讓正常的瞬態故障觸發不必要的重建。

適合 liveness 偵測的狀態：

• deadlock：所有 worker thread 被卡住，無法處理新請求也無法回傳錯誤。liveness endpoint 設在獨立 goroutine / thread 上，如果 worker pool 卡住但 liveness goroutine 能回應，問題在業務邏輯而非 deadlock。
• memory leak 導致的 OOM 前兆：記憶體使用率持續上升不回落，GC 已無法回收。此時主動回報 unhealthy 讓平台在 OOM kill 前重建，比被動等 OOM 更可控——OOM kill 不走 graceful shutdown，在途請求直接中斷。
• essential background task 永久停止：必要的定期任務（如 license renewal、session cleanup）超過預期間隔仍未執行。這類失敗靜默發生，只有 liveness 主動偵測能發現。

不適合 liveness 偵測的狀態：下游資料庫短暫不可用、外部 API timeout、cache miss 率升高。這些由 readiness 或 circuit breaker 處理——用 liveness 重建不會修好下游，只會用重啟放大問題。

Restart 的代價量化

每次 liveness 觸發的重啟會產生四類代價：

1. 在途請求中斷：被重啟的實例正在處理的請求直接失敗。
2. 連線重建成本：資料庫連線池、cache 連線、queue consumer 重新建立。
3. 啟動期間的容量缺口：重啟到 readiness 通過之間，整體服務容量降低。
4. thundering herd 風險：多實例同時被 liveness 判定失敗並重啟時，同時重建連線、同時搶資源、下游壓力瞬間放大。

對應 5.C7 Airbnb Istio 升級治理：揭露「基礎平台元件升級若缺乏分批治理、會形成全域風險放大器」。以下基於通用工程知識展開：Istio 等 service mesh 升級期間的 sidecar 重啟可觸發大量服務的 liveness 暫時失敗，若 liveness 太敏感會放大成全域 restart storm。升級期的 liveness 閾值應比穩態更寬鬆，或在升級批次中暫時加大 liveness failure threshold。

Shutdown 與 Drain

shutdown 的責任是讓服務停止接新工作並完成資源釋放。draining 的責任是讓平台在移除實例前，讓 in-flight request、長連線或背景工作有時間收束。

短 request API、長連線服務與 background worker 的 drain 條件不同。短 API 主要看在途請求歸零；長連線看 reconnect 節奏；worker 看已領取工作能否完成或重新排隊。tunnel 入口的 startup / readiness / drain 對齊見 5.10 Outbound Tunnel 入口。

三種 Workload 的 Drain 差異

不同 workload 類型的 drain 完成條件與時間尺度完全不同，用同一套 drain 設定覆蓋所有 workload 會在至少一類服務上出事。

短 request API（HTTP REST、gRPC unary）：drain 窗口通常在 5-30 秒。核心條件是在途請求數歸零。風險點是 load balancer 的 deregistration delay——LB 可能在服務已標記 not-ready 後仍送幾秒流量（取決於 health check interval 與 deregistration delay），所以服務端 drain 窗口要覆蓋這段延遲。endpoint 摘除的傳播窗口與 preStop 等待策略見 5.4 摘除節奏與 Drain 的配合。

長連線服務（WebSocket、gRPC streaming、SSE）：drain 窗口通常在 30 秒到數分鐘。核心條件是現有連線收斂且 reconnect 波形穩定。風險點是客戶端 reconnect 策略——服務端 drain 完成不代表客戶端已連上新實例。若客戶端沒有 backoff 或 reconnect 目標選擇邏輯，會形成 reconnect storm。drain 設計要跟客戶端 reconnect 策略一起規劃。

Background worker（queue consumer、定時任務、batch job）：drain 窗口取決於單一工作的最長執行時間。核心條件是已領取的工作完成處理或安全重新排隊。風險點是不可中斷工作——某些 job 做到一半無法重試（例如外部 API 呼叫已發出但回應尚未確認），drain 時序要覆蓋這類 job 的最長完成時間，否則 job 被中斷後產生不一致狀態。

對應 5.C9 反例：平台切流未先 Draining：揭露「切流失敗常在 connection lifecycle 管理」「drain / idle timeout / health check / client retry 沒有同一節奏」。反例中的事故擴大機制正是不同 workload 類型的 drain 條件被忽略——短 API 的 drain 完成了，長連線的 reconnect 仍在震盪，worker 的 job 被中斷重試造成重複處理。

Shutdown 信號的傳遞路徑

platform 到 application 的 shutdown 信號傳遞有多個可能斷點。信號從平台送到容器 PID 1、PID 1 轉發到應用進程——PID 1 的信號處理語意與常見陷阱見 5.1 PID 1 與信號處理。本段聚焦 lifecycle 層的時序問題：

• preStop hook 與 SIGTERM 時序：Kubernetes 先執行 preStop hook、再送 SIGTERM。preStop hook 可用來等 LB 摘流量（sleep 幾秒讓 endpoint 從可用集合移除），讓 SIGTERM 到達時在途流量已經減少。
• terminationGracePeriodSeconds：平台等待的最長時間。超過後 SIGKILL 強制結束，不走 graceful shutdown。這個值要覆蓋 preStop + drain + 資源釋放的總時間。

shutdown 信號傳遞的驗證方式是在 staging 環境觸發 pod delete，觀察應用 log 中是否出現 shutdown handler 的紀錄。沒看到 shutdown log 代表信號沒傳到、要先修傳遞路徑再談 drain 設計。

不同 Workload 的 Lifecycle 特性對照

生命週期合約的參數設定要依 workload 類型調整。以下是三類常見 workload 的特性差異。

這張表是選型前判準的操作化：先確認服務屬於哪類 workload，再套用對應的 lifecycle 參數基線。混合 workload（例如同時提供 HTTP API 和 WebSocket）要取各層的嚴格值——drain 窗口取最長的、readiness 取最嚴格的。

平台如何表達 Lifecycle 差異

不同部署平台表達生命週期合約的能力不同。選型時要問的是「這個平台能不能分別設定 startup、readiness、liveness 與 drain」。

Kubernetes 在 lifecycle 表達力上最完整，但參數最多也最容易配錯。systemd 靠 sd_notify 協議明確宣告 readiness，在單機部署場景下反而比 K8s 的 probe 直接。Docker 和 ECS 不分離 readiness 與 liveness，需要在應用層自行實作降級邏輯。

選平台不只看功能清單，要看它表達 lifecycle 差異的粒度是否覆蓋服務需求。若服務需要分離 startup 和 readiness 但平台只有一個 health check，這個差距要在應用層補——代價是複雜度從平台設定轉移到程式碼。

遷移期的 Lifecycle 重新驗證

對應 5.C6 Airbnb Kubernetes 叢集擴縮演進：揭露「擴縮策略版本化與可回放」「不同 workload 區分擴縮政策」。以下基於通用工程知識展開：叢集演進過程中，lifecycle 參數的假設會改變——workload 從穩態變成高波動、從單一類型變成混合類型、從小規模變成大規模。lifecycle contract 的參數不是設一次就好，要隨叢集演進重新驗證。

對應 5.C10 對照：規模差異下的平台遷移：揭露「小型組織最容易漏掉回退腳本化」「中型組織依賴錯位、服務切過去但資料面 / 認證面 / 觀測面沒同步」。lifecycle contract 在遷移後的完整性驗證不只看 probe 設定——secret 注入時序、資料庫連線池的 endpoint 是否切到新叢集、observability pipeline 的 readiness 是否對齊，都是 lifecycle 合約的一部分。

遷移後的 lifecycle 驗證清單：

1. startup 時序重測：新平台的 image pull 時間、secret mount 時間、DNS 解析路徑可能不同，原本的 startup timeout 可能不夠。
2. readiness 依賴路徑檢查：readiness 檢查的依賴是否仍可達（新叢集到舊資料庫的 latency 是否增加、跨叢集 service discovery 是否對齊、DNS TTL 與快取行為是否改變）。
3. drain 行為驗證：在新平台觸發 pod delete、觀察 drain 完成時間與在途請求處理是否符合預期。
4. 信號傳遞驗證：在新平台觸發 shutdown、確認 SIGTERM 到達應用進程並觸發 graceful shutdown handler。

選型前判準

部署平台選型前要先回答：

1. 服務啟動需要多久，哪些依賴是 readiness 條件。
2. 服務失敗時應由自己恢復，還是由平台重建。
3. 服務停止時有哪些 in-flight request、connection 或 job。
4. 平台是否能表達 startup、readiness、liveness 與 drain 的差異。

這些問題決定後續要比較 Kubernetes probe、systemd restart policy、load balancer health check 或 service mesh drain 能力。

判讀訊號

常見誤區

把所有 probe 設成同一個 /health endpoint，會讓 startup、readiness 與 liveness 的語意混在一起。三種 probe 回答不同問題：startup 問「初始化完了嗎」、readiness 問「可以接流量嗎」、liveness 問「還活著嗎」。同一個 endpoint 無法同時回答三個問題，因為初始化完成不代表依賴就緒，依賴暫時不可達不代表服務本身壞了。

把 drain 窗口設成固定值不分 workload 類型，會在某一類服務上出事。5 秒對短 API 足夠、對長連線不夠、對 batch job 遠遠不夠。drain 窗口要依服務實際 workload 設定，不是用平台預設值。

把 liveness 失敗當成「服務壞了」而不問代價，會忽略重啟本身的連鎖效應。每次重啟都有在途請求中斷、連線重建、容量缺口的代價——特別是多實例同時被判定 liveness 失敗時，代價會被放大。

案例回寫

lifecycle contract 的完整性可用多個案例交叉驗證。5.C3 Orbitera managed K8s migration 揭露遷移後 readiness 依賴路徑改變的風險。5.C9 反例 揭露不同 workload 的 drain 條件被忽略造成的事故擴大。5.C7 Airbnb Istio 升級治理 揭露基礎平台元件升級缺乏分批治理會形成全域風險放大器。5.C10 對照 揭露不同規模下 lifecycle 驗證的缺口模式。

這些案例共同支撐的判讀是「lifecycle contract 的每個狀態都有不同的失敗模式，混在一起處理會在事故時無法定位」。流量切換或連線生命週期問題路由到 5.3 load balancer 合約。runtime 產物穩定性問題路由到 5.1 container 與 runtime。

跨模組路由

lifecycle contract 是部署模組的概念基底，後續章節都會引用本篇的狀態分類。

1. 與 5.1 的交接：runtime 與 entrypoint 定義 startup 行為回到 container 與 runtime。
2. 與 5.2 的交接：probe 設定與 rollout 節奏回到 Kubernetes 部署策略。
3. 與 5.3 的交接：drain 與流量退場回到 load balancer 合約。
4. 與 5.10 的交接：tunnel 入口的 readiness 與 drain 對齊回到 Outbound Tunnel 入口。
5. 與 4.20 的交接：lifecycle 事件的證據收集回到 Observability Evidence Package。
6. 與 6.8 的交接：lifecycle 狀態作為 release gate 判定條件回到 Release Gate。

下一步路由

要看 Kubernetes 如何承接這組生命週期，接著讀 5.2 Kubernetes 部署策略。要看流量退場如何和 LB 對齊，接著讀 5.3 load balancer 合約。要看不同平台的 lifecycle 表達力比較，接著讀 vendors/。

觀察

Airbnb 的叢集擴縮經歷了多個演進階段。早期是手動調整 node 數量——工程師根據流量預測或事故壓力臨時加 node、事後忘記縮回。中期引入 Cluster Autoscaler，讓 node 數量跟 pending pod 連動。後期隨工作負載類型分化（stateless API、長連線服務、batch job、ML 訓練），單一 autoscaler policy 無法覆蓋所有場景，開始分群治理。

這個演進路徑的共同主題是「每當流量型態或 workload 組成改變，原本的擴縮策略就會在某個量級開始失效」。擴縮策略的有效期跟服務演進速度成反比。

判讀

叢集擴縮若停留在人工流程，面對高波動流量會放大成本與可用性風險。人工擴縮的問題有兩面：反應太慢（流量已衝高但 node 還沒加上來）和撤退太慢（流量已回落但多餘 node 繼續燒錢）。自動化解決反應速度，但引入新的判讀問題——autoscaler 的參數設定本身需要治理。

HPA 觸發閾值設太低會造成 pod 數量頻繁抖動；Cluster Autoscaler 的 scale-down delay 設太短會在流量波動時反覆 add/remove node，增加 pod eviction 頻率。這些參數的調校要依 workload 類型分群——API 服務的擴縮節奏跟 batch job 完全不同。

另一個判讀是擴縮策略跟事故指標要綁定。autoscaler 的動作（scale-up trigger、scale-down execution、node provision latency）如果不在事故 timeline 上可見，事故團隊無法分辨「是 autoscaler 來不及」還是「是應用本身有問題」。

策略

1. 擴縮策略版本化與可回放：HPA / VPA / Cluster Autoscaler / Karpenter 的配置進 git，變更走 release flow。每次調參都有 commit 紀錄，事故後可以追溯「這次 scale-down 過快是因為哪次參數變更」。版本化的另一個價值是可回放——新的擴縮配置在 staging 環境用歷史流量 replay 驗證後，再推到 production。
2. workload 分群擴縮：stateless API 用 CPU / RPS-based HPA、batch job 用 queue depth-based HPA、長連線服務用 connection count-based 自訂 metric。不同 workload 類型放在不同 namespace，各自有獨立的 autoscaler policy。避免一套 HPA 規則套全部 workload。
3. 容量治理與事故指標綁定：HPA 觸發事件、Cluster Autoscaler 的 scale-up / scale-down 事件、node provision latency 都送進事故 timeline（可用 Kubernetes event exporter 或 custom metric）。事故 timeline 上看到「HPA 觸發後 3 分鐘 node 才 ready」就能直接判斷「容量補充太慢」而非「應用有 bug」。

回退判讀

擴縮策略變更的回退比應用版本回退簡單——改 HPA / autoscaler 的 config 就好。風險在於回退後的舊策略可能已經跟當前 workload 型態不匹配（workload 成長了、流量特性變了）。穩定做法是回退後立刻進入觀察窗口，確認舊策略在當前流量下仍然有效。

下一步路由

回 5.2 kubernetes deployment 看 autoscaling 與部署策略協同。回 5.6 platform lifecycle contract 看不同 workload 的 lifecycle 差異如何影響擴縮設計。回 6.9 capacity & cost 看容量規劃的完整框架。

引用源

• Dynamic Kubernetes Cluster Scaling at Airbnb（原始 URL 已失效，內容基於骨架與通用工程知識擴充）

本章目標

讀完本章後、你應該能：

1. 建立 ALB / NLB、配置 listener + target group
2. 設計 health check + connection draining
3. 用 ACM 自動憑證 + SNI
4. 用 ALB Ingress Controller / AWS Load Balancer Controller for K8s
5. 評估 ALB vs NLB vs CloudFront vs API Gateway

最短路徑：5 分鐘把 AWS ELB 跑起來

 1# 1. 建 ALB
 2aws elbv2 create-load-balancer \
 3  --name demo-alb \
 4  --subnets subnet-aaa subnet-bbb \
 5  --security-groups sg-xxx \
 6  --scheme internet-facing \
 7  --type application
 8
 9# 2. 建 target group + register targets
10aws elbv2 create-target-group \
11  --name demo-tg \
12  --protocol HTTP --port 8080 \
13  --vpc-id vpc-xxx \
14  --target-type instance \
15  --health-check-path /health \
16  --health-check-interval-seconds 15
17
18aws elbv2 register-targets \
19  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/demo-tg/... \
20  --targets Id=i-0abc123 Id=i-0def456
21
22# 3. 建 listener + 驗證
23aws elbv2 create-listener \
24  --load-balancer-arn arn:aws:elasticloadbalancing:...:loadbalancer/app/demo-alb/... \
25  --protocol HTTP --port 80 \
26  --default-actions Type=forward,TargetGroupArn=arn:aws:...
27
28ALB_DNS=$(aws elbv2 describe-load-balancers --names demo-alb \
29  --query 'LoadBalancers[0].DNSName' --output text)
30curl "http://${ALB_DNS}"

日常操作與決策形狀

ALB vs NLB vs CLB

子議題：

• ALB：L7、path/host routing、WebSocket、gRPC、Lambda target
• NLB：L4、static IP、preserve client IP、極低延遲、TCP/UDP
• CLB：legacy、不要新用
• 選擇判讀：HTTP/HTTPS → ALB；TCP/UDP / 高吞吐 → NLB

Target group / listener rule

子議題：

• Target type：instance / IP / Lambda
• Listener rule：path-based / host-based / header-based routing
• Priority 排序
• 對應指令：aws elbv2 modify-rule

Health check 與 draining

子議題：

• Health check：HTTP path / interval / threshold
• Connection draining（deregistration delay）：deregister 後等到 in-flight requests 完成
• 對應 5.C9 反例 cutover without drain

進階主題（按需閱讀）

TLS termination + SNI

子議題：

• ACM 自動憑證 + 續期
• SNI：單 ALB 多 domain（最多 25 certificates）
• TLS policy（min TLS version）
• Mutual TLS（ALB 2023+）

ALB Ingress Controller / AWS Load Balancer Controller

子議題：

• 在 EKS 內配置 ALB / NLB（Ingress / Service of type LoadBalancer）
• IngressClass / annotations
• Pod readiness gate（pod 到 ALB target group healthy 才接流量）
• 對應 Kubernetes vendor 頁

Cross-zone load balancing

子議題：

• ALB default enabled、NLB default disabled
• Cross-zone 跨 AZ data transfer cost
• 跟 AZ failover 對應

WAF integration

子議題：

• AWS WAF on ALB
• Rate-based rule / managed rule group
• 對應 07 security WAF

Idle timeout

子議題：

• ALB default 60s、可調 1-4000s
• 跟 keep-alive / WebSocket 長連線對應
• 跟 backend（K8s pod / EC2）的 timeout 對齊

Cost 模型

子議題：

• LB-hour（per ALB / NLB）
• LCU（Load Balancer Capacity Unit）— 多維度計算
• Data processing charge
• 跨 AZ data transfer

排錯快速判讀

Target unhealthy

操作原則：health check path 不對 / security group 沒開 / backend 反應慢。

1aws elbv2 describe-target-health \
2  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/demo-tg/...
3# HealthState: unhealthy → 查 Reason（Target.Timeout / Elb.InternalError / Target.ResponseCodeMismatch）
4# 常見根因：security group 沒開 health check port、health check path 回 404、backend 回應超過 timeout

504 Gateway Timeout

操作原則：backend 超 ALB idle timeout / 60s。判讀：backend log + ALB access log。

Cross-zone imbalance

操作原則：cross-zone disabled、流量集中單 AZ。修法：enable cross-zone（注意 cost）。

Draining 卡住

對應 5.C9 反例。判讀：deregistration delay 太短 / connection 未結束就被斷。

ACM cert renew 失敗

操作原則：DNS validation 失敗 / domain ownership 變動。判讀：ACM console 看 cert state。

何時改走其他服務

不在本頁內的主題

• AWS WAF rule 完整 reference
• Network Firewall 配置
• 各 AWS region 限制差異
• ELB classic（CLB）細節

案例回寫

直接相關案例

跨 vendor 對照

待補 AWS ELB 案例：大規模 AWS Load Balancer Controller 客戶案例、NLB static IP 場景、AWS WAF + ALB 安全整合。

下一步路由

• 上游概念：5.3 LB Contract
• 平行 vendor：nginx、Envoy
• 下游能力：07 security WAF、6 reliability release gate

本模組承接前面的並發、WebSocket、runtime 與測試：graceful shutdown 需要 context 和 goroutine lifecycle，health endpoint 需要區分可用性與診斷，structured log 需要能追 event flow，feature gate 需要能安全控制新能力。

章節列表

本模組使用的範例主題

本模組使用虛構的即時通知服務作為範例。範例包含 HTTP server、WebSocket hub、background worker、runtime diagnostics、structured log 與 feature gate。

範例只用來展示 Go 生產操作設計，不假設讀者正在維護任何特定專案。

本模組的 Go 核心概念

• 用 signal.NotifyContext 或 signal channel 建立 root context。
• 用 http.Server.Shutdown 停止接受新 request。
• 用 context 傳遞停止訊號給 worker、hub、WebSocket pump。
• 用 /health、/ready、/debug/... 分開不同操作訊號。
• 用 log/slog 建立穩定 structured fields。
• 用 config struct 載入 feature gate，而不是到處讀環境變數。

學習重點

學完本模組後，你應該能判斷：

1. 服務收到停止訊號後，哪些元件要先停止接流量
2. health、readiness、diagnostics 各自回答什麼問題
3. structured log 欄位如何支援查詢與聚合
4. 哪些資料不應進入 log
5. feature gate 關閉時應降級、回錯、隱藏還是排程稍後處理

本模組不處理

本模組不討論 Kubernetes、systemd、雲端平台或完整 SRE 流程的所有細節。這些環境會影響操作策略，但本模組先建立 Go 服務本身應具備的操作邊界；後續可接 Kubernetes、systemd 與 load balancer 合約 以及 Observability pipeline、metrics 與 tracing。

學習時間

預計 3-4 小時

Traffic Boundary

Traffic boundary 的責任是決定 request 如何進入服務、如何分流、如何回退。它包含 load balancer、routing rule、health check、sticky session、timeout 與 drain。

流量切換要能回答三個問題：哪一批 request 會到新版本、失敗時如何停止擴批、舊版本是否仍能承接回退流量。這三個答案明確後，canary 才能從比例設定變成可回退策略。

Traffic boundary 的判讀重點是 customer impact 如何被分批限制。小比例 canary、區域切流、tenant 切流與 route rule 都是不同切換單位；切換單位越清楚，rollback window 越容易被驗證。

切換單位的選擇

切換單位決定故障的 blast radius 與回退的精準度。常見切換單位各有不同操作特性：

比例切換最簡單但 blast radius 不可控——5% 的流量中可能包含大客戶的關鍵路徑。租戶切換精準度最高但操作複雜度也最高——需要在 routing 層維護租戶到版本的映射。穩定做法是從比例切換開始，遇到需要精準控制 impact 時再升級到租戶或路由規則切換。

Config Boundary

設定如何下發、如何生效、如何回退——Config boundary 回答這三個問題。config rollout 和應用版本不一定同步，因此要保留相容窗口。

高風險設定包含 payment provider endpoint、feature flag、rate limit、routing rule、timeout 與 fallback policy。這些設定變更可能不需要新 image，卻能改變 production 行為，因此要進 release gate。

Config 變更的風險分級

設定變更的風險不一致——有些設定改了只影響 log level，有些設定改了直接影響付款路徑。分級後才能對不同風險的設定套用對應的 review 與 rollout 強度。

風險分級的判讀依據是「這個設定改錯時、使用者會看到什麼」。改錯 payment endpoint 會讓付款打到錯誤目標；改錯 rate limit 可能讓合法流量被擋；改錯 log level 最多是 log 太吵或太安靜。設定的注入方式與版本追蹤見 5.1 配置注入方式與取捨。

Secret Boundary

Credential、token、certificate 與 machine identity 需要可輪替、可稽核、可回退——Secret boundary 管理這組生命週期。Secret 變更同時影響平台、應用與外部依賴，應使用比普通 config 更嚴格的 evidence 與 rollback window。

Secret rollout 要回答版本相容、雙軌驗證、舊 secret 撤除時間與失敗回退。這裡要接到 7.27 Credential Rotation with Scoped Evidence。

Secret Rollout 的雙軌驗證

Secret 輪替跟應用版本部署有本質差異：rollback secret 不是「換回舊版本」那麼單純——舊 secret 可能已經被撤銷、過期、或在外部系統中標記為失效。Secret rollout 的安全做法是雙軌驗證：

1. 新 secret 先加入、舊 secret 暫不移除：應用先驗證能用新 secret 正常運作。
2. 觀測窗口確認新 secret 穩定：auth 成功率、API 呼叫成功率、certificate handshake 成功率都在 baseline 內。
3. 確認後移除舊 secret：舊 secret 的撤除要有明確時間點，而且要在撤除前確認沒有服務還在用舊 secret。

這個流程的風險點是第 3 步：撤除舊 secret 後發現某個遺漏的服務或 job 還在用、導致該服務認證失敗。盤點覆蓋率的做法是在觀測窗口內搜尋 audit log，確認所有 secret 使用都已切到新版本。

Service Discovery Boundary

Service discovery 的責任是維持可用 endpoint 集合。它回答服務應該連到哪些實例；業務設定與版本正確性則分別交給 config boundary 與 rollout gate。Discovery 的 DNS / registry 運作模式與註冊時序見 5.4 Service Discovery。

Discovery 失準常見於 rollout、擴縮容與區域故障。判讀時要拆成註冊時序、健康判斷、DNS/registry 新鮮度與 fallback 存活時間。

Control Plane Boundary

設定、策略、部署與路由規則的管理落在 management plane。Control plane 變更會影響大量服務，因此需要更嚴格的 evidence、gate 與 decision log。

Control plane 事故常見於規則推送、routing 誤配、secret 下發失敗與 registry 異常。這類事故要先保留 decision timeline，避免事後只看到資料面錯誤率。

Control Plane 變更的 Blast Radius 控制

Control plane 變更的 blast radius 跟 data plane 變更不同——一條 routing rule 推送錯誤可能同時影響所有服務的流量。控制 blast radius 的做法：

1. 分批推送：規則變更先推到 staging / canary namespace、驗證後再推到 production。推送結果的觀測應包含受影響服務的 error rate 與 latency。
2. approval gate：高影響變更（network policy、admission webhook、RBAC binding）需要多人 review。變更的 blast radius 估算（影響多少 namespace / service）應在 review 時可見。
3. decision log：所有 control plane 變更記入 8.23 Control Plane Decision Log，包含時間、操作者、受影響範圍、預期效果與回退條件。事故時對照 decision log 跟 data plane 症狀的時間序列，可以快速判斷因果。

平台元件升級的可重播流程

平台基礎元件升級是 control plane 風險最高的場景。Service mesh、ingress controller、CNI、API server 這類元件影響面廣、單次升級可能形成全域風險放大器。

對應 5.C7 Airbnb Istio 升級治理：揭露 1 個判讀（基礎平台元件升級缺乏分批治理會形成全域風險放大器）+ 3 條策略（分批升級 + 回退窗口、升級驗證標準固定化、升級事件接入 incident command 節奏）。以下基於通用工程知識展開、「升級事件進 timeline」是從 case「接入 incident command」策略進一步推到具體操作。

可重複套用的升級流程：

1. 分批升級單位：先在開發 / staging 叢集驗證、再選低流量 production 叢集 / namespace 作為先導、之後分批擴大。分批單位可以是叢集、namespace、region、tenant，依風險面選擇。
2. 回退窗口跟驗證標準同時設：每批升級前定義「驗證通過」的具體訊號（SLI 維持、特定 metric 不偏移、無新告警），跟「回退窗口」（多久內可以回退）。沒有驗證標準的分批等於連續高風險動作。
3. 升級流程紀錄到 incident-style 文件：升級期間的決策、觀察、停止點都用 incident decision log 格式紀錄。下次升級可重播、不依賴執行者個人經驗。
4. 升級事件進 timeline：升級本身產生的短暫錯誤、reconnect、配置同步延遲，要在事故 timeline 上可見、避免被誤判成事故。

平台元件升級的核心治理價值是把「一次性高風險作業」變成「可重複的低風險作業」。第一次升級用流程，第二次升級用同樣流程，第三次升級流程已經穩定到可以委派、不再需要資深工程師親自執行。

Managed 平台跟團隊職責邊界

平台託管化（self-managed → managed）改變維運責任跟團隊精力的分配。本段聚焦團隊職責邊界；流量跟依賴的分段切換流程見 5.2 分階段平台遷移、紅隊視角的攻擊面變動見 5.5 平台遷移期的攻擊面變動、三者組合才完整。

Platform team 從「維持 Kubernetes 跑起來」轉向「定義 release flow、observability convention、cost governance」。managed 平台採用後第一個治理動作是顯式重新定義職責邊界、讓 platform team 從 cluster ops 轉到 release flow / observability convention / cost governance。重新定義缺位、組織轉型紅利容易被誤判為純技術升級。

對應 5.C5 Miro Managed EKS 遷移：揭露 1 個判讀（平台託管化的價值在讓團隊把心力從底層維護轉到交付效率與可靠性策略）+ 3 條策略（先定義遷移後的平台責任邊界、自動化流程取代手動平台操作、incident 跟 release policy 接回平台治理）。對應 9.C33 Maersk + Bosch Azure AKS：揭露 Maersk 工程訴求引語「focus on things that makes the most business impact」、傳統產業 K8s 動機是治理一致性 + 釋放工程資源到業務功能（後者屬作者判讀）。以下基於通用工程知識展開。

managed 平台採用後的職責邊界重訂可以分四層：

1. Cluster 層：control plane 上游接管（API server、etcd、scheduler、controller-manager）、platform team 從 cluster ops 退到 cluster policy。CIS benchmark、network policy、admission controller 配置仍是 platform 責任。
2. Cluster-internal 層：CNI、ingress controller、service mesh、cluster DNS、storage CSI 通常仍由 platform team own。這層是 managed 服務沒覆蓋的 grey zone、需要明確 ownership。
3. Application 層：deployment、service、HPA、PDB 由 service team own、platform 提供 convention 跟 review process。
4. 跨層議題：cost governance、observability convention、release flow、incident response 是 platform / service / SRE / finance 跨層協作、需要 operating model 明確化。

managed 採用後 day-1 治理項目有兩件事：明確界定 grey zone ownership（避免「以為 managed 服務什麼都管了」的心智模型）、把 platform team 心力從 cluster ops 轉到組織轉型紅利（release flow、observability convention、cost governance）。把重新定義職責當 day-2 議題、會錯失組織轉型紅利。

選型前判準

平台選型前要先回答：

1. 哪些變更屬於 traffic，哪些屬於 config，哪些屬於 secret。
2. 每種變更是否能分批、暫停與回退。
3. Discovery 失準時是否有可控 fallback。
4. Control plane 變更是否有 audit、owner 與 blast radius 限制。
5. 基礎元件升級是否有可重播流程跟回退窗口。
6. Managed 平台採用後團隊職責邊界是否重新定義。

這些答案決定後續要比較 load balancer、service mesh、secret manager、service registry 或 deployment controller 的能力。

實體服務討論承接點

實體平台文章要承接本篇的 traffic、config 與 control plane boundary。ELB、nginx、Envoy、service mesh、Consul、Kubernetes controller、secret manager 或 Terraform 的比較，要先分清它們是在資料面接流量、在控制面改規則，還是在設定面下發狀態。

若主問題是流量切換，後續文章要比較 routing rule、weight、health check、drain 與 rollback。若主問題是設定與 secret，後續文章要比較 rollout、audit、rotation 與相容窗口。若主問題是 control plane 風險，後續文章要比較 blast radius、approval、observability 與 incident decision log。

下一步路由

要把流量邊界接到實際 LB 合約，接著讀 5.3 load balancer 合約。要把 control plane 決策寫入事故流程，接著讀 8.23 Control Plane Decision Log and Write-back。

觀察

Airbnb 在數十個 Kubernetes 叢集、數萬個 pod、數千個 VM 的規模下持續升級 Istio service mesh，峰值流量達數千萬 QPS。團隊累計完成 14 次成功的 Istio 升級。

升級的核心挑戰是規模帶來的協同成本：無法逐一通知每個 workload team 進行升級配合，也無法同時監控所有 workload 的升級狀態。升級策略必須對 workload team 透明——workload 不需要改程式碼或調配置就能完成 proxy 版本切換。

判讀

基礎平台元件升級若缺乏分批治理，會形成全域風險放大器。Istio 升級的影響面覆蓋所有跑 sidecar 的服務——一次壞的升級可以讓整個叢集的服務間通訊中斷。這個風險決定了升級策略必須是 canary 模式（小比例先行），而且 canary 的粒度要夠細（namespace 或 workload 級別），才能在問題擴大前攔截。

另一個判讀是升級流程本身要版本化。第一次升級靠資深工程師手動操作可以成功，但這個知識留在個人經驗裡。第二次升級換了人就可能踩到不同的坑。把升級流程固定成可重播的 spec（升級計畫 → 執行 → 驗證 → 確認/回退），讓升級從「英雄行為」變成「例行操作」。

策略

1. Canary upgrade model（兩版本並存）：採用 Istio 的 canary upgrade 機制，同時跑兩個版本的 Istiod。新版本的 sidecar proxy 跟對應版本的 control plane 配置一起原子部署，避免跨版本相容性問題。透過 revision label 決定每個 namespace 使用哪個版本的 Istiod。
2. 自建工具解耦基礎設施更新與 workload 部署：團隊開發了 Krispr（mutation framework），在 CI 階段注入 Istio revision label，並在 admission 階段對超過兩週未部署的 pod 重新注入最新 label。這讓 workload 在正常部署流程中自動完成 proxy 升級，不需要額外操作。
3. rollouts.yml 定義升級批次與比例：用 spec 檔定義每個環境（staging / production）、每個 namespace pattern 的版本分佈（例如 staging 75% 舊版 / 25% 新版）。比例可以逐步調整——先 5% → 25% → 50% → 100%。每個批次有明確的觀測窗口與停損條件。
4. VM 升級用 mxrc controller：Kubernetes 外的 VM workload 用 mxrc controller 根據 rollouts.yml 更新 tag，遵守健康狀態檢查與可用性門檻。VM 的升級通常在兩週內透過自然輪替完成。
5. 升級事件進 incident timeline：升級期間的短暫錯誤（proxy 重連、配置同步延遲）在事故 timeline 上標記為升級事件，避免被誤判成獨立事故。升級的決策紀錄用 incident decision log 格式，讓下次升級可以回溯上次的判斷依據。

升級節奏的收斂

14 次升級的經驗讓升級流程逐步收斂。多數 workload 在正常 deployment 時自動完成 proxy 升級（因為 Krispr 在 admission 階段注入最新 revision）。沒有 regular deployment 的 workload 在四週內透過自然 pod cycling（node 維護、HPA 調整）完成升級。這個四週窗口是可接受的——超過四週未部署的 workload 通常也是低變動、低風險的。

回退判讀

Istio 升級的回退是把 revision label 切回舊版本、讓 pod 在下次 restart 時重新注入舊版 sidecar。回退的風險在於回退期間新舊 proxy 混跑，traffic policy 可能不完全一致。穩定做法是先在小範圍驗證回退行為（一個 namespace），確認 traffic policy 一致性後再擴大回退範圍。

下一步路由

回 5.2 kubernetes deployment 看 rollout 節奏與 probe 設計。回 5.7 平台元件升級的可重播流程 看通用升級框架。回 8.6 IC handoff 看升級期事故的指揮交接。

引用源

• Seamless Istio Upgrades at Scale

對「跨雲基礎設施管理、團隊協作 IaC、需要 state + plan workflow」這條路徑、Terraform / OpenTofu 是首選。

本章目標

讀完本章後、你應該能：

1. 寫 HCL config（resource / variable / output / module）
2. 設定 remote state（S3 + DynamoDB lock / Terraform Cloud）
3. 設計 module + workspace 結構
4. 跑 plan / apply / destroy 工作流 + GitOps
5. 評估 Terraform vs OpenTofu vs Pulumi vs Crossplane

最短路徑：5 分鐘把 Terraform 跑起來

1# 1. 安裝
2brew install hashicorp/tap/terraform   # 或 brew install opentofu

1# 2. 寫 main.tf
2terraform {
3  required_providers {
4    aws = { source = "hashicorp/aws", version = "~> 5.0" }
5  }
6}
7provider "aws" { region = "us-east-1" }
8resource "aws_s3_bucket" "demo" { bucket = "my-tf-demo-bucket" }

1# 3. init + plan + apply
2terraform init
3terraform plan -out=plan.tfplan
4terraform apply plan.tfplan

日常操作與決策形狀

HCL config 結構

子議題：

• provider / resource / data source / variable / output / locals
• terraform block（required_version / required_providers / backend）
• Module（reusable group of resources）
• 對應指令：terraform fmt、terraform validate

State 管理

子議題：

• Local state（terraform.tfstate）：dev / 學習用
• Remote state（S3 + DynamoDB lock / GCS / Terraform Cloud / Spacelift）
• State migration（terraform state mv / rm / import）
• State sensitive data 不入 git

Plan / apply workflow

子議題：

• terraform plan -out=plan.tfplan（凍結結果）
• terraform apply plan.tfplan
• Auto-approve（CI / CD）vs manual approve（critical）
• 對應 GitOps：Atlantis / Terraform Cloud / Spacelift

進階主題（按需閱讀）

Module 設計

子議題：

• Module input / output
• Module composition（root module → child module）
• Public module registry（Terraform Registry / OpenTofu Registry）
• Version pinning
• 對應 Terraform best practice

Workspaces vs directory layout

子議題：

• Workspaces：同 module 多 instance（dev / staging / prod）
• Directory：每 env 一個 directory
• Workspaces 的局限（state 同 backend、env 共享 config）
• 選擇判讀：強隔離 → directory；快切換 → workspace

Drift detection

子議題：

• Drift = 實際 infra ≠ Terraform state
• 偵測：terraform plan 跑出來有 diff
• 修法：Manual import / state pull / 修改 cloud directly + plan refresh
• 對應 自動化 drift detection（Atlantis / Driftctl）

Terraform vs OpenTofu

子議題：

• 2023 Terraform 改 BSL：Linux Foundation fork OpenTofu
• OpenTofu 跟 Terraform 1.5 API 相容
• 之後分歧：OpenTofu 加 state encryption、provider iteration
• 遷移路徑：替換 binary、import 既有 state

Provider 生態

子議題：

• AWS / Azure / GCP（cloud provider）
• Kubernetes / Helm（K8s provider）
• SaaS：Datadog / Pagerduty / Cloudflare / GitHub
• Community provider vs official provider 品質差距

跟 Crossplane / Pulumi 對比

子議題：

• Crossplane：K8s-native IaC（用 K8s CRD 管 cloud resource）
• Pulumi：用通用語言（TS / Python / Go / C#）寫 IaC
• 選擇判讀：純 cloud infra → Terraform / OpenTofu；K8s-heavy → Crossplane；developer-first → Pulumi

Terraform Cloud / Spacelift / Atlantis

子議題：

• Terraform Cloud（HashiCorp managed）：remote state + run + policy
• Spacelift / env0：商業替代
• Atlantis：OSS Pull Request automation
• 對應 GitOps for IaC

排錯快速判讀

State lock stuck

操作原則：DynamoDB lock 沒釋放（process killed）。判讀 + 修法：terraform force-unlock <lock-id>（小心）。

Plan diff 過大

操作原則：drift 累積 / provider 升級 / config 改太多。判讀：先看 plan output、再決定要不要 apply。

Provider auth fail

操作原則：AWS / GCP credentials 沒設、過期、權限不夠。判讀：AWS_PROFILE / IAM role / GCP ADC 配置。

Module version 衝突

操作原則：root module 跟 child module 用不同 provider version。判讀：terraform providers 看 version constraint。

Apply partial failure

操作原則：apply 中某 resource 失敗、state 一致性問題。判讀：state pull 看當前、可能要 import / state rm 修。

何時改走其他服務

不在本頁內的主題

• 完整 HCL syntax reference
• 各 provider 完整 resource list
• Terraform Cloud / Spacelift 商業 feature
• Drift detection 工具細節

案例回寫

跨 vendor 對照

待補 Terraform 案例：HashiCorp Cloud 大客戶案例、OpenTofu fork 後企業遷移案例、Drift detection 治理案例。

下一步路由

• 上游概念：5 deployment platform
• 平行 vendor：Kubernetes（K8s provider）
• 下游能力：06 reliability（IaC GitOps + release gate）

本模組已開始補成正文。章節先定義問題邊界與前置脈絡，再逐步補上 transaction、outbox、跨節點 WebSocket、observability、部署與可靠性驗證的實作語意；後續仍可依實戰需求繼續擴寫。

與 Backend 教材的分工

本模組保留在 Go 進階篇，因為它要回答的是「Go 服務跨出單一 process 前，程式內部需要準備哪些 port、訊號、錯誤語意與測試合約」。具體資料庫、Redis、RabbitMQ、observability、Kubernetes 或 CI 平台操作，會放在跨語言的 Backend 服務實務指南。

章節列表

本模組和前面章節的關係

本模組適合在你已經理解單一 Go 服務的內部邊界後閱讀，用來補足生產環境常見的外部系統責任。

• 事件與狀態邊界先讀 模組四：架構邊界與事件系統。
• WebSocket lifecycle 先讀 模組二：WebSocket 服務架構。
• 測試可靠性先讀 模組五：測試與可靠性。
• 操作語意先讀 模組六：生產操作。

學習時間

目前已可作為第一輪正文閱讀，完整學習時間可隨後續擴寫再調整。

本篇以 5.2 Kubernetes 部署策略 與 5.3 load balancer 合約 為前置知識——rollout 批次、probe 對齊、drain contract 等概念在該兩篇定義，本篇直接操作化。lifecycle 狀態的完整定義見 5.6 Platform Lifecycle Contract。

服務路徑與切換責任

這條路徑是 client -> load balancer -> checkout-api -> payment provider/order db/order event。部署期間新舊版本會同時承接流量，核心風險在流量生命週期是否可收斂，image 替換本身反而是最可預測的部分。

切換責任分三層：

1. 版本可啟動：container/runtime/config 可用。
2. 版本可接流量：readiness 與依賴狀態對齊。
3. 版本可退場：drain 與在途請求可收束。

Preflight：先驗證可服務基線

Preflight 的責任是把「可啟動」與「可服務」拆開驗證。最小檢查包含：

1. image 與 runtime config 版本對齊。
2. secret 已注入且權限正確。
3. startup/readiness probe 能反映真實依賴狀態。
4. load balancer contract 參數與服務期望一致。
5. service discovery 註冊與摘除路徑可用。

Preflight 失敗時不進 canary。先把失敗收斂在控制面，避免切流後才發現版本不可服務。

Preflight 自動化

手動 preflight 在低頻部署時可行，部署頻率上升後會成為瓶頸或被跳過。穩定做法是把 preflight 檢查嵌入 CI/CD pipeline 的 pre-deploy stage：

1. image 與 config 版本對齊檢查：pipeline 比對即將部署的 image tag 與 ConfigMap / Secret 版本是否在相容矩陣內。版本矩陣可維護在 git（如 deploy/compat-matrix.yaml），CI 自動比對。
2. infra drift detection：部署前用 IaC 工具（Terraform plan、Crossplane drift check）掃描目標環境的實際狀態是否跟宣告狀態一致。drift 存在時暫停部署——在已漂移的環境上部署新版本，會把漂移與版本變更的影響混在一起，事故時無法分辨根因。
3. probe 語意驗證：在 staging 環境對新版本觸發 startup → readiness → liveness 全流程，確認 probe 回應與依賴就緒條件吻合。這步抓的是 probe 設定退化（如 readiness endpoint 被改成永遠回 200）。
4. rollback 可行性驗證：確認舊版本 image 仍在 registry 且可拉取、舊版本 config 仍相容。rollback 能力在 preflight 階段驗證，比事故時才發現「舊版拉不到」代價低得多。

Preflight 自動化的產出是一份 go/no-go 報告，進入 6.8 Release Gate 作為放行依據。pipeline 中的 preflight stage 失敗應阻擋部署而非產生警告——可忽略的 preflight 等於沒有 preflight。

Canary Batch 與 Stop Condition

小流量先驗證新版本行為，再決定是否擴批——Canary 回答的是「這個版本值不值得擴大」。

canary 判讀要維持 per-version 視角。只看整體服務平均值會掩蓋新版本局部退化。

Traffic / Drain：把退場變成可驗證流程

Drain 的責任是讓舊版本在下線前完成在途請求，不讓 rollout 把短暫切換放大成用戶錯誤。

退場順序：

1. 舊實例 readiness 先轉 not-ready 停接新流量。
2. 保留 drain 窗口完成 in-flight request。
3. 確認連線數下降到門檻後再終止進程。
4. 驗證無異常 reconnect 尖峰再進下一批。

Drain 條件的完整 workload 分類回到 5.6 Platform Lifecycle Contract，本段以 checkout service 為例：短 API 的 draining 窗口可短，長輪詢與 webhook callback 要更保守。

Rollback Compatibility

舊版本回來時仍可運作，是 rollback 能成立的前提——回退如果變成第二次故障，就失去了回退的工程價值。

要先驗證四個相容面：

1. config 相容：新設定不會讓舊版啟動失敗。
2. schema 相容：資料結構仍可被舊版讀取。
3. cache key 相容：舊版可讀新快取或有 fallback。
4. event schema 相容：舊版 consumer 不會因新事件欄位崩潰。

若這四項未完成，所謂 rollback 只會停在「版本回切」，無法恢復服務正確性。

Evidence Package

每一批切換要可被判讀、可被追責、可被回放——部署 evidence 支撐這三個條件。

這份 evidence 要對齊 4.20 Observability Evidence Package。

Release Gate

Release gate 的責任是決定下一批切換與是否凍結 rollout，不是報告「目前看起來正常」。

這組欄位要對齊 6.8 Release Gate。

Incident Decision Log

freeze rollout、rollback version、隔離 region、延長 drain 都屬事故決策，需寫入 8.19 Incident Decision Log。涉及流量規則 / control plane 設定推送的決策、見 5.7 跟 8.23 Control Plane Decision Log。

 1incident_decision:
 2  timestamp: 2026-05-11T15:06:00Z
 3  decision: "freeze rollout at 25% and rollback one region"
 4  context: "new version timeout to payment provider increased in ap-northeast"
 5  evidence:
 6    - query: checkout_error_rate_by_version_region
 7    - query: payment_timeout_ratio_by_region
 8  owner: release-incident-commander
 9  expected_effect: "contain customer impact and restore baseline success rate"
10  rollback_condition: "timeout ratio does not recover after rollback batch completes"

Case Write-back 與邊界

這篇回寫對齊 5.C9 反例、5.C1 Tradeshift 與 5.C3 Orbitera：前者看切換失序，後兩者看遷移路徑與回退策略。preflight / canary / drain 各階段的生命週期定義回到 5.6 Platform Lifecycle Contract。

這篇不處理 schema migration 本身、cache stampede 或 queue replay。若核心風險在資料正式狀態、快取回源或事件恢復，路由到 1.7 Schema Migration Rollout 證據、2.9 Cache Migration 與 Stampede Rollback 或 3.8 Queue Consumer Retry 與 Replay Handoff。

對「Docker / K8s ingress、需要 auto-discovery、ACME 自動 TLS、配置簡潔」這條路徑、Traefik 是 cloud-native first 選擇。

本章目標

讀完本章後、你應該能：

1. 部署 Traefik 到 Docker / K8s
2. 配置 dynamic provider（labels / annotations / CRD / file）
3. 配置 ACME 自動 TLS
4. 設計 middleware chain（auth / rate limit / circuit breaker）
5. 評估 Traefik vs nginx vs Envoy 的選用

最短路徑：5 分鐘把 Traefik 跑起來

 1# 1. Docker 跑 Traefik + dashboard
 2docker run -d -p 80:80 -p 8080:8080 \
 3  -v /var/run/docker.sock:/var/run/docker.sock \
 4  traefik:v3 --api.insecure=true --providers.docker
 5
 6# 2. 用 docker label 配置 routing
 7docker run -d --label "traefik.http.routers.demo.rule=Host(\`demo.local\`)" nginx
 8
 9# 3. 訪 dashboard 驗證
10curl -s http://localhost:8080/api/http/routers | jq '.[].rule'

日常操作與決策形狀

Provider auto-discovery

子議題：

• Docker provider：從 container labels 讀 config
• Kubernetes Ingress provider：從 Ingress resource
• Kubernetes CRD provider：Traefik IngressRoute CRD
• Consul / Etcd provider：從 KV store
• File provider：YAML / TOML 靜態 file

IngressRoute（K8s CRD）

子議題：

• Traefik CRD：IngressRoute / Middleware / TLSOption / ServersTransport
• 比 Ingress 表達力強（middleware chain / TLS option / multi-protocol）
• 跟 Gateway API 對比

Middleware chain

子議題：

• 內建 middleware：headers / rate limit / basic auth / forward auth / retry / circuit breaker / compress / IP whitelist
• 自訂 middleware：plugin（Yaegi-based）
• 順序：定義 middleware → 在 router 引用

進階主題（按需閱讀）

ACME 自動 TLS

子議題：

• Let’s Encrypt 整合（自動憑證 + 續期）
• DNS challenge（適合 wildcard）vs HTTP challenge（適合單 domain）
• 多 resolver 配置（staging / production / 不同 CA）
• 對應 ACME storage（local / KV / Traefik Hub）

Provider weight / priority

子議題：

• 多 provider 同時跑、config 來源衝突處理
• Provider 優先順序
• 對應 dynamic config debug

Traefik Hub（managed）

子議題：

• Traefik Hub：商業 managed control plane
• 適合：跨 cluster 統一管理 / API Gateway portal
• 跟 self-host Traefik 對比

跟 nginx / Envoy 對比

子議題：

• Traefik 強：cloud-native auto-discovery、配置簡潔
• nginx 強：穩定 + 配置控制力 + 大量 community recipe
• Envoy 強：xDS dynamic config、advanced traffic management
• 選型判讀：Docker / K8s 小中規模 → Traefik；複雜 traffic → Envoy；標準 HTTP → nginx

Plugin 機制（Yaegi）

子議題：

• Traefik plugins 用 Yaegi（Go interpreter）跑、不需 recompile
• Plugin catalog（社群 + 官方）
• 適合：客戶 auth / metric / transformation 小邏輯
• 對應 Envoy WASM extension 對比

Multi-protocol

子議題：

• HTTP / HTTPS / TCP / UDP
• gRPC（HTTP/2）原生支援
• WebSocket sticky session

排錯快速判讀

Service 沒被發現

操作原則：先看 provider 是否啟用、再看 label / annotation / CRD 配置。

1curl -s http://localhost:8080/api/http/services | jq '.[].name'

Route 衝突

操作原則：兩個 router 同 rule，看 priority 排序。判讀：dashboard 看 router list。

ACME rate limit

操作原則：Let’s Encrypt 有 rate limit、staging environment 先測再切 production。

Middleware chain 順序錯

操作原則：middleware 順序影響行為（auth before rate limit vs after）。判讀：dashboard 看 middleware order。

Dashboard 連不上

操作原則：dashboard 預設 8080、需要 entrypoint 配置。判讀：traefik.yml + entrypoints 設定。

何時改走其他服務