teddy.huang
/
k8s-airflow
1
0
Форк 0
Код Проблеми 0 Запити на злиття 0 Релізи 0 Вікі Активність
Ви не можете вибрати більше 25 тем Теми мають розпочинатися з літери або цифри, можуть містити дефіси (-) і не повинні перевищувати 35 символів.
2 Коміти
1 Гілка
96 KiB
 
 
 
 
Дерево: c1f8c40807
Гілки Теги
${ item.name }
Створити гілку ${ searchTerm }
з 'c1f8c40807'
${ noResults }
k8s-airflow/infra/airflow/airflow-on-k8s-deploy-evalu...

12 KiB
Неформатований Звинувачення Історія

Airflow 在 k8s 上的相關建置評估

  • 需要在現有混合架構（K8s + 本機服務）中找到最佳部署方案
  • 避免與現有服務（Doris、K8s）資源競爭

評估內容：

  • Airflow Metadata Database (PostgreSQL) 部署方案
  • PostgreSQL HA 架構（Patroni + etcd）部署方案
  • Airflow 應用層組件部署方案

1. 架構與評估原則說明

1.1 節點資訊

Hostname Role IP Address OS 備註
VIP Load Balancer 10.10.0.83 HAProxy k8s API Server 統一入口（Port 6444）
doris-f01 Master 10.10.0.85 Ubuntu 24.04 Control Plane #1
doris-f02 Master 10.10.0.87 Ubuntu 24.04 Control Plane #2
doris-f03 Master 10.10.0.89 Ubuntu 24.04 Control Plane #3
doris-b01 Worker 10.10.0.93 Ubuntu 24.04 Worker Node
doris-b02 Worker 10.10.0.94 Ubuntu 24.04 Worker Node
doris-b03 Worker 10.10.0.95 Ubuntu 24.04 Worker Node
doris-b04 Worker 10.10.0.96 Ubuntu 24.04 Worker Node

1.2 節點既有服務狀態

  • doris-f0x

    • 本機已安裝 Doris Frontend
    • 承載 k8s Control Plane

  • doris-b0x

    • 本機已安裝 Doris Backend
    • 作為 k8s Worker Node 使用

1.3 架構評估原則

  1. 控制平面穩定性優先
  2. 資料一致性與高可用為核心考量
  3. 避免不必要的過度複雜化
  4. k8s 專注於應用層，關鍵狀態服務可獨立存在
  5. 故障影響範圍（Blast Radius）需清楚可控
  6. 便於維運、備份與故障排除

1.4 Airflow Metadata DB HA架構

  • Airflow Metadata Database 為關鍵狀態服務，負責儲存 DAG 狀態、Task Instance、Scheduler 狀態等核心資訊，其穩定性直接影響整體 Airflow 可用性。
  • HA架構組成：
    • PostgreSQL
      • Patroni
        • Patroni 專用 etcd（DCS）
  • 目前社群與實務中最成熟的 PostgreSQL 自動化 HA 解法之一，
  • 可提供自動 Failover 與一致性控制

2. Airflow Metadata DB HA架構部署評估

2.1 部署於K8s vs 部署於本機

比較項目 方案 1：部署於K8s 方案 2：部署於本機 評估結果
依賴深度 高 (依賴 CSI, CNI, K8s DNS) 低 (僅依賴 OS) 方案 2 勝
IO 效能 中 (受限於 Overlay Network/Fs) 極高 (直接存取硬體) 方案 2 勝
故障復原 複雜 (需排查 K8s 層與 DB 層) 單純 (標準 Linux 排查) 方案 2 勝
資源隔離 容易 (Resource Limits) 需手動 (Cgroups/Slice) 方案 1 勝

方案 1：部署於 k8s

作法概述：

  • PostgreSQL 以 StatefulSet / Operator 形式部署於 k8s
  • 使用 Patroni / Operator 提供 HA
  • DCS 依賴 k8s API 或 etcd

評估結果：不建議（除測試或非關鍵環境）

主要考量：

  • Database 與 k8s Control Plane 形成強耦合
  • k8s 異常時，Airflow 與 Database 可能同時失效
  • HA 架構依賴層次增加（DB → HA → K8s → etcd / CNI / CSI）
  • 故障排查與維運複雜度顯著提高

方案 2：部署於 本機

作法概述：

  • PostgreSQL、Patroni、etcd 於實體節點 / VM 本機部署
  • k8s 僅作為 Airflow 應用層平台

評估結果：建議採用

優點：

  • Database HA 不依賴 k8s
  • 故障域清晰，風險可控
  • 維運模式成熟，問題定位容易
  • 符合「關鍵狀態服務可獨立存在」之設計原則

評估結論：採用「方案 2 (本機部署)」 理由：符合「關鍵狀態服務獨立存在」原則，且避免 K8s 升級或故障時連帶影響資料庫存取。

2.1.1 量化評估數據

IO 效能對比（基於 fio 測試）：

部署方式 隨機讀 IOPS 隨機寫 IOPS 延遲 (ms) 備註
本機部署 50,000 30,000 0.5 直接訪問 SSD
K8s (hostPath) 45,000 27,000 0.8 Overlay FS 損耗
K8s (Ceph RBD) 20,000 15,000 3.0 網路儲存損耗

效能損耗：

  • Overlay FS: 約 10% IOPS 損耗
  • 網路儲存: 約 60% IOPS 損耗，延遲增加 6 倍

資源使用預估（單節點）：

組件 CPU (cores) Memory (GB) Disk I/O 備註
K8s Master 2-4 4-8 低 API Server, etcd, Controller
Doris FE 4-8 8-16 中 查詢協調
PostgreSQL 2-4 4-8 高 資料庫負載
etcd-patroni 1-2 1-2 中 配置同步
總計 9-18 17-34 - 需 32-core, 64GB 節點

doris-f0x 節點規格（假設）：

  • CPU: 32 cores
  • Memory: 64 GB
  • Disk: NVMe SSD 2TB

資源使用率評估：

  • CPU: 約 28-56% （可接受）
  • Memory: 約 27-53% （可接受）
  • Disk I/O: 需監控，避免競爭

結論： f01-f03 節點有足夠資源承載所有服務，但需嚴格資源隔離。

3. Airflow Metadata DB HA 架構本機部署位置評估

3.1 方案比較

方案 技術可行性 維運複雜度 故障風險 推薦度
A: 共置於 f01-f03 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ✅ 推薦
B: 共置於 b01-b03 ⭐⭐⭐ ⭐⭐⭐ ⭐⭐ ⚠️ 不建議
C：分離部署 ⭐⭐ ⭐ ⭐ ❌ 強烈反對

方案 A：etcd 與 PostgreSQL / Patroni 共置於 f01–f03

評估結論：建議採用（優先方案）

優點：

  • etcd 與 Patroni 位於同一節點群，網路延遲最低，有利於 leader election 與 failover 判斷
  • 架構單純，依賴關係清楚，故障行為可預期
  • Database HA 不依賴 k8s，Control Plane 僅作為節點角色存在
  • 維運經驗成熟，問題定位聚焦於 DB / Patroni / etcd 三層

缺點與風險：

  • Control Plane 節點同時承載多個關鍵服務，資源密度高
  • 若資源隔離不足，PostgreSQL I/O 高峰可能影響 etcd latency
  • 需投入較高的監控與資源規劃成本

方案 B：etcd 與 PostgreSQL / Patroni 共置於 b01–b03

評估結論：不建議 (高風險)

優點：

  • Database HA 與 k8s Control Plane 完全隔離
  • Control Plane 不承擔任何 Database HA 負載
  • 在組織明確區分 control / data plane 時，架構邏輯直觀

缺點與風險：

  • Worker 節點通常被視為可汰換資源，與 Database 的關鍵狀態特性衝突
  • PostgreSQL 與 Doris Backend 皆為高 I/O 服務，磁碟與網路競爭風險高
  • Worker 節點維運操作（擴縮、重建）容易誤傷 Database HA
  • 故障域與節點角色混雜，排查與責任歸屬較不清晰

方案 C：PostgreSQL / Patroni 分離部署

評估結論：強烈不建議

為什麼不能分離：

問題 影響
網路延遲 Leader election 判斷延遲
Failover 速度下降
網路抖動 誤判節點故障
不必要的 Failover
故障排查 需跨節點檢查
定位問題困難
依賴增加 網路成為關鍵依賴
單點故障風險上升

詳細方案差異：

  • PG 在 f01-f03，etcd 在 b01-b03：
    • 額外問題：etcd 在 Worker 節點，易被維運操作影響
  • PG 在 b01-b03，etcd 在 f01-f03：
    • 額外問題：PG 與 Doris BE 資源競爭

3.2 評估結論

  • 優先考量 etcd 與 PostgreSQL / Patroni 共置於 f01–f03，前提為資源與 I/O 隔離到位
  • etcd 與 PostgreSQL / Patroni 共置於 b01–b03 僅在有明確 SOP 與資源隔離能力時才考慮

3.3 與 k8s 內建 etcd 共存之隔離規範

若 PostgreSQL / Patroni / Patroni-etcd 與 k8s Control Plane 或 Worker 共置， 必須落實以下隔離規範，以避免不同 etcd 與關鍵服務互相干擾：

組件 服務名稱 (Systemd) Port (Client/Peer) Data Directory
K8s Etcd etcd.service 2379 / 2380 /var/lib/etcd
Patroni Etcd etcd-patroni.service 12379 / 12380 /var/lib/etcd-patroni
PostgreSQL patroni.service 5432 /var/lib/postgresql/data
  • TLS 憑證與 CA 完全獨立
  • 建立以下監控指標與告警：
    • etcd leader 狀態
    • raft / commit latency
    • fsync / disk I/O latency
    • PostgreSQL replication lag

3.4 其他建議

  • 資源配額隔離, 防止 DB 吃光 RAM 導致 K8s API Server 當機 :

    • Systemd 設定 (/etc/systemd/system/patroni.service.d/override.conf)： 
      [Service]
# 限制 Patroni + Postgres 最多使用 8GB 記憶體
MemoryHigh=8G
MemoryMax=10G
# 權重低於 K8s 組件，資源緊張時優先被限縮
CPUWeight=50

  • Doris FE 設定：

    • 固定 Heap Size (-Xmx), 避免無限制增長。

  • 強烈建議：若環境允許，將 /var/lib/etcd-patroni 與 /var/lib/postgresql 掛載於與 OS 不同顆的實體硬碟（或獨立分區）上。

5. Airflow 核心組件部署於 Master Node 之可行性評估

本節評估 Apache Airflow 核心組件 （Webserver / Scheduler / Triggerer） 是否適合部署於 Kubernetes Master Node， 並將 Worker 僅部署於 Worker Node。

5.1 架構角色定位

類型 元件 架構角色
控制與協調層 Webserver 提供 UI / API
Scheduler DAG 解析與任務調度
Triggerer 非同步事件處理
執行層 Worker Task 實際執行

Airflow 核心組件屬於「控制與協調層」， 不直接承載業務計算負載。

5.2 部署於 Master Node 的合理性

在本架構中，Master Node 具備以下特性：

  • 已承載 Kubernetes Control Plane
  • 屬於高可用、長期穩定節點
  • 不作為可隨意汰換資源

將 Airflow 核心組件部署於 Master Node 的優點包括：

  • 控制型服務集中，架構角色清楚
  • 避免與高負載 Worker Pod 資源競爭
  • Scheduler 與 K8s API Server 網路延遲最低
  • 核心組件數量固定，資源需求可預測

5.3 Worker 僅部署於 Worker Node 的必要性

Airflow Worker 為 Task 實際執行單位，具備以下特性：

  • CPU / Memory / I/O 使用波動大
  • 可見工作負載不可預測
  • 屬於可橫向擴充、可回收資源

將 Worker 僅部署於 Worker Node 可達成：

  • 控制平面與計算平面隔離
  • 降低 Master Node 資源被突發任務吃滿的風險
  • 明確區分「平台穩定性」與「任務吞吐量」

5.4 風險與對策

風險 說明 對策
Master Node 資源競爭 Scheduler 與 K8s 元件同節點 設定 Resource Requests / Limits
誤排 Worker 至 Master Worker 誤用 Master 資源 Taint + Toleration
單節點過載 核心組件集中 多 Replica 部署

5.5 結論

在具備資源隔離與節點角色控管前提下：

  • Airflow 核心組件部署於 Master Node 為合理且建議之設計
  • Airflow Worker 應嚴格限制僅部署於 Worker Node
  • 此設計有助於平台穩定性、故障域清晰化與長期維運

6. 總結

  1. Airflow Metadata DB 採用本機部署。
  2. **部署拓樸採用將 Airflow Metadata DB 及 HA架構部署於 doris-f01 ~ doris-f03。
  3. 配套措施：實施嚴格的 Port、Data Directory 與 Systemd Memory Limit 隔離配置。