零停機從 Ingress NGINX 遷移到 Envoy Gateway：加權 DNS 切換策略實戰
CNCF Blog · 2026-05-25
隨著 Kubernetes Gateway API 趨近穩定，越來越多的工程團隊考慮從 Ingress NGINX 遷移到 Envoy Gateway 或其他 Gateway API 實作。CNCF 部落格發表了一篇實戰案例，記錄如何透過加權 DNS 流量切換達成零停機遷移，並分析過程中遇到的 DNS TTL 衝突與多命名空間 hostname 配置問題。
遷移三階段
第一階段：控制器選型。評估標準包含 CNCF 對齊、生產功能支援（mTLS、request buffering）、以及是否遵循「專用資源模型」而非 annotation 蔓延。Envoy Gateway 被選中，原因是作為 CNCF 專案的長期維護保障，以及對 mTLS 與 request buffering 的原生支援。
第二階段：內部測試。使用 Kind（Kubernetes IN Docker）與內部工具 Goldilocks，讓 Ingress 與 HTTPRoute 資源同時存在於叢集，驗證相同 hostname 在兩個控制器下的行為一致性。這是零停機策略的核心前提：Gateway API 和 Ingress API 可以共存。
第三階段：加權 DNS 切換。使用 ExternalDNS 搭配 AWS Route 53 的加權記錄（weighted records），讓新舊控制器同時服務同一個 hostname，透過調整權重漸進轉移流量：
# 初始：舊 Ingress 100%, 新 HTTPRoute 0%
# 驗證後：50% / 50%
# 確認後：舊 Ingress 0%, 新 HTTPRoute 100%遇到的挑戰
- DNS TTL 衝突：在舊 Ingress 記錄的 TTL 到期前移除它，會導致部分用戶在快取過期期間遇到 DNS 錯誤
- 多命名空間 hostname 設定：Gateway API 1.5 之前，hostname 必須同時在 Gateway 和 HTTPRoute 層級定義，破壞了跨命名空間的關注點分離
- 回滾複雜度：加權 DNS 方案讓回滾變得簡單——只需調整權重，無需刪除重建 DNS 記錄
影響範圍
Gateway API 相較於 Ingress API 的主要優勢是職責分離（RoleOriented Design）：叢集管理員控制 Gateway，應用開發者控制 HTTPRoute，不需要管理員權限即可配置路由規則。Envoy Gateway 也支援更豐富的流量管理（請求重試、限流、熔斷），這些在 Ingress API 中通常需要依賴 vendor-specific annotation 實作。
原始來源：CNCF Blog
Kubernetes 政策執行時機太晚：為何 Admission Controller 無法解決開發者體驗問題
CNCF Blog · 2026-05-25
CNCF 部落格探討 Kubernetes 政策執行的一個根本問題：現有的政策即代碼（Policy-as-Code）工具——OPA/Gatekeeper、Kyverno、Conftest——雖然功能強大，但都在開發週期的過晚階段執行，導致開發者在完成 PR 審查後才收到違規通知，不得不切換上下文修正。
「太晚」的定義
目前的兩個主要執行點是：
- CI/CD pipeline 掃描：manifest 在 CI 中被工具（如 Conftest）驗證，失敗時 pipeline 報錯
- Admission Controller：資源嘗試進入叢集時，Kyverno 或 OPA Gatekeeper 在 API server 層阻擋
問題不在工具本身，而在執行時機：「當違規被發現時，開發者已完成程式碼撰寫、PR 通常已被審查，上下文已經切換走了。」這個摩擦造成的是：CI 因政策違規失敗 → 開發者切換回去看錯誤 → 再一次提交修正 → 再次等待 CI → 循環重複。
解決方向：移到 PR Review 階段
文章提出將政策執行點前移到 Pull Request Review 階段，讓政策違規作為 PR comment 或 review check 出現，在開發者仍有 PR 上下文的時候解決問題。具體技術路徑包含：在 GitHub Actions 中對 PR diff 執行政策掃描、使用 Danger.js 或類似工具在 PR 上自動留下政策說明，以及 IDE 插件在本地開發時即時反饋。
影響範圍
對 Platform Engineering 團隊而言，Admission Controller 仍然必要，作為最後防線阻止真正危險的配置進入叢集，但不應是唯一的政策執行點。讓開發者更早獲得政策反饋，既減少了他們的修正成本，也降低了 Admission Controller 在關鍵部署時期阻擋合法部署的頻率。
原始來源：CNCF Blog
瀏覽器作為容器建置環境：OCI 規格的純 JS 實作探索
ochagavia.nl · 2026-05-26
Adolfo Ochagavía 發布一個 DevOps 工程角度的 proof-of-concept：不依賴 Docker daemon、Buildah 或任何容器 runtime，純粹在瀏覽器沙盒中完成 OCI 映像檔的下載、修改與打包。專案以 TypeScript 與 Svelte 撰寫，提供互動式介面讓使用者選擇 base image 與初始化腳本，最終匯出可用 docker load 載入的 tar 檔案。
OCI 規格的純資料本質
這個 demo 的工程價值在於揭示 OCI image format 的核心性質：映像檔只是一組 tar 壓縮層加上 JSON 描述文件（manifest.json、config.json），沒有任何神秘的二進位 magic。TypeScript 的 pako（gzip）與原生 crypto.subtle.digest（SHA-256）已足以完整操作 OCI 規格要求的所有格式。這意味著任何能運行 JavaScript 的環境，原則上都可以產生合規的 OCI 映像檔。
對 CI 工具設計的啟示
雖然瀏覽器版本因沙盒限制（無 syscall、無 root、無複雜網路）只能做基礎的檔案系統修改，但同樣的 TypeScript/Node.js 程式碼移植到 CI 環境中，可以作為輕量化的 映像檔後期處理工具：例如在不啟動 Docker daemon 的情況下，在 CI job 中對已建置的映像 tar 進行 manifest 修改、layer 壓縮優化、或多平台 manifest list 的組合。作者特別強調：「這不是要取代 Docker，而是展示你可以自己寫。」
原始來源：ochagavia.nl、GitHub