在處理大規模即時數據流時，如何有效管理集群的生命週期與資源調度是工程團隊面臨的核心挑戰。 ride-sharing 平台 Lyft 過去多年來依賴一套自研的 Kubernetes Operator 來管理其 Apache Flink 任務。Apache Flink 是一個強大的分佈式處理引擎，用於對連續數據流進行低延遲的計算。而 Operator 則是一種 Kubernetes 的擴展模式，旨在將特定軟體的運維知識定義為代碼，自動化處理安裝、升級與縮放等複雜操作。然而，隨著業務規模擴張，自研系統的維護成本與功能缺陷逐漸顯現，促使 Lyft 決定將數百個生產環境的 Flink 任務遷移至官方的 Apache Flink Kubernetes Operator。
自研系統的技術債與痛點
Lyft 在 2020 年開發自研 Operator 時，開源社群尚未提供成熟的 Flink Kubernetes 控制平面。當時的升級機制採取雙集群部署，流程包括啟動新集群、觸發 Savepoint（一種將所有算子狀態持久化到儲存設備的快照機制）、取消舊任務並從快照恢復。這種方式存在顯著缺陷：Savepoint 觸發缺乏重試邏輯與冪等性，若大型狀態任務發生超時，可能導致部署失敗，甚至在缺乏近期 Checkpoint（檢查點）的情況下導致任務在無狀態的情況下重啟。
此外，資源管理也面臨困難。Lyft 使用 Apache Beam Python 框架，這需要非 JVM（Java 虛擬機）的記憶體預留。當時團隊僅能透過一個簡單的比例參數來估算開銷，設定過低會導致 TaskManager（Flink 的工作節點）因 OOM（記憶體溢出）而被系統殺死，設定過高則造成嚴重的資源浪費。
遷移路徑與核心技術實現
為了平滑遷移，Lyft 並未要求開發者重寫定義檔，而是開發了一層部署 API，將舊有的 FlinkApplication 規範轉換為官方的 FlinkDeployment 資源。這層轉換邏輯處理了 Jar 包路徑映射、節點選擇器轉換以及環境變數的注入，並將預設升級模式設為 last-state。last-state 是一種高效的升級模式，即使 JobManager（Flink 的主控節點）處於不健康狀態，也能從高可用元數據或最新檢查點恢復，將狀態恢復視為一等公民。
在部署策略上，Lyft 引入了 FlinkBlueGreenDeployment 這一自定義資源定義（CRD）。早期的官方 Operator 在升級時會採取先停止後啟動的模式，導致典型任務有 3 到 6 分鐘的停機時間，大型任務甚至長達 20 分鐘。透過藍綠部署，新舊版本可以並行運行，直到切換完成，徹底消除了升級導致的業務中斷。
自動縮放與資源優化
遷移至官方 Operator 後，Lyft 將 Flink 版本升級至 1.19，旨在實現真正的在線自動縮放（In-place Autoscaling）。在 Flink 1.17 之前的版本，更改並行度需要重啟任務，這對於關鍵業務是不可接受的。從 1.18 版本開始，Operator 支持在不重啟的情況下調整資源。
為了讓自動縮放更精準，Lyft 利用了 flink-connector-aws 5.0.0 提供的 KinesisStreamsSource。該元件能像 Kafka 來源一樣發送記錄積壓指標（Backlog Metrics），為自動縮放器提供必要的信號。同時，Lyft 嘗試使用資源自動調優（Autotuning）來回收 JVM 開銷。但在實踐中發現，自動調優會因調整容器記憶體而觸發 Pod 重啟，這與在線縮放存在衝突。
針對此衝突，Lyft 採取了分級管理策略：對於定價與路由等高關鍵度任務，優先使用在線縮放而禁用自動調優；對於低關鍵度任務，則接受重啟以換取更精確的資源調優。此外，針對 Beam Python 導致的 OOM 問題，Lyft 參考了 Spotify 的做法，將 Python 執行環境移至獨立的 Sidecar 容器中，為其設定獨立的資源限制，避免影響 Flink 主進程。
實務意義與限制
這次遷移為 Lyft 帶來了顯著的經濟效益。透過自動縮放器對資源進行精確的右規模化（Right-sizing），Lyft 成功消除了每年數百萬美元的過度配置成本。在底層基礎設施方面，Lyft 結合了自定義的分配調度器與 Karpenter（一個 Kubernetes 節點自動配置工具），使 Pod 能密集部署並根據需求動態提供 EC2 算力。
然而，不同企業的選擇反映了規模與控制權的權衡。例如 Netflix 運行超過三萬個 Flink 任務，其規模遠超 Lyft，因此選擇運行自研與開源的 Flink Autoscaler 而非完全依賴 Kubernetes Operator。而 Amazon Managed Service for Apache Flink 則提供了完全託管的方案，雖然免除了維護成本，但缺乏 Pod 層級的 Sidecar 定制能力。
總結而言，Lyft 的經驗證明，從自研工具轉向社群標準化 Operator，不僅能降低維護壓力，更能快速獲取如藍綠部署、在線縮放等前沿功能，使工程團隊能將精力從基礎設施維運轉移到更高價值的業務邏輯開發上。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。