# 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 判斷延遲<br>Failover 速度下降 |
| **網路抖動** | 誤判節點故障<br>不必要的 Failover |
| **故障排查** | 需跨節點檢查<br>定位問題困難 |
| **依賴增加** | 網路成為關鍵依賴<br>單點故障風險上升 |


**詳細方案差異：**
- 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 不同顆的實體硬碟（或獨立分區）上。

---


[//]: # (## 4. Airflow 組件建置（k8s）)

[//]: # (### 4.1 建置範圍)

[//]: # ()
[//]: # (Airflow 僅部署應用層元件於 k8s：)

[//]: # ()
[//]: # (- Webserver)

[//]: # (- Scheduler)

[//]: # (- Triggerer)

[//]: # (- Worker（依 Executor 類型）)

[//]: # (- DAG 同步機制（Git-sync / Object Storage）)

[//]: # ()
[//]: # (Metadata Database 透過穩定網路連線存取外部 PostgreSQL。)

[//]: # ()
[//]: # (---)

[//]: # ()
[//]: # (### 4.2 Executor 選型原則（概述）)

[//]: # ()
[//]: # (- **k8sExecutor**)

[//]: # (  - 每個 Task 對應一個 Pod)

[//]: # (  - 彈性佳，資源隔離明確)

[//]: # (- **CeleryExecutor**)

[//]: # (  - 需額外 Message Broker（Redis / RabbitMQ）)

[//]: # (  - Worker 常駐，資源較可預期)

[//]: # (---)

## 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 隔離配置。

---