03 · 核心基礎設施與私有雲
此主題 roadmap 項目的里程碑
截至 2026-10-22 · 今天
甘特圖
里程碑
| # | 里程碑 | 開始日 | 目標日 | 狀態 | 等待 | 團隊 | Epic | 推導 |
|---|---|---|---|---|---|---|---|---|
| 08 · 企業級 Harvester HCI | ||||||||
| 8.1 | Fabric L3 設計核准 — server ↔ ToR routed，BGP 到 ToR | 2026-07-06 | 2026-08-14 | 完成 | — | SRE | — | — |
| 8.2 | 第一個 rack group 切到 L3 fabric — 一個 rack group 改為 BGP peering | 2027-01-01 | 2027-02-12 | 規劃中 | 8.1 | SRE | — | — |
| 8.3 | 所有伺服器機櫃切到 L3 fabric | — | 2027-05-21 | 規劃中 | 8.2 | SRE | — | 等待 8.2 |
| 8.4 | Harvester 具備承接正式流量的條件 | — | 2027-04-09 | 規劃中 | 8.2 | SRE | — | 等待 8.2 |
| 09 · KVM 遷移至 Harvester | ||||||||
| 9.1 | Harvester 確立為重建的預設落點 | — | 2027-04-23 | 規劃中 | 8.4 | SRE | — | 等待 8.4 |
| 9.2 | 虛擬機工作負載於 Harvester 重建並完成切換 | — | 2027-10-08 | 規劃中 | 2.3, 4.2, 9.1 | SRE | — | 等待 2.3, 4.2, 9.1 |
| 9.3 | 最後一台 libvirt 主機關機 | — | 2028-01-28 | 規劃中 | 9.2 | SRE | — | 等待 9.2 |
| 9.4 | 退役的 KVM 主機重灌併入 Harvester | — | 2028-04-07 | 規劃中 | 5.4, 9.3 | SRE | — | 等待 5.4, 9.3 |
| 10 · DNS 架構重構 | ||||||||
| 10.1 | 新 DNS 驗收完成，並盤點仍指向舊 resolver 的客戶端 | 2026-08-10 | 2026-10-30 | 進行中 | — | SRE | — | — |
| 10.2 | Zone 記錄納入 Terraform 管理 | — | 2027-02-12 | 規劃中 | 4.1 | SRE | — | 等待 4.1 |
| 10.3 | 客戶端切換完成，舊 resolver 除役 | — | 2027-07-16 | 規劃中 | 2.3, 10.1 | SRE | — | 等待 2.3, 10.1 |
| 10.4 | 台中 Site B 除役 | — | 2028-01-14 | 規劃中 | 10.3 | SRE | — | 等待 10.3 |
| 11 · Kubernetes 叢集遷移至 L3 fabric | ||||||||
| 11.1 | L3 模式 K8s 叢集建置完成 — MetalLB BGP 模式 | 2027-01-01 | 2027-02-19 | 規劃中 | 8.2 | SRE | — | 等待 8.2 |
| 11.2 | 服務分波搬遷，雙叢集並行 | — | 2027-03-26 | 規劃中 | — | SRE · 平台工程 | — | — |
| 11.3 | 切換完成，舊叢集淘汰 | — | 2027-07-16 | 規劃中 | 8.3 | SRE · 平台工程 | — | 等待 8.3 |
細節
8.1Fabric L3 設計核准 — server ↔ ToR routed，BGP 到 ToR2026-08-14完成 · 2/2
- L2/L3 邊界與 BGP peering 設計說明負責人 · CharlesL2 網域在哪裡結束、各 ToR 通告哪些 prefix、伺服器如何 peering。
- 與網路團隊審閱負責人 · Charles
8.2第一個 rack group 切到 L3 fabric — 一個 rack group 改為 BGP peering2027-02-12規劃中 · 1/3
- Rack group A 的 ToR BGP 設定負責人 · Charles
- 將 rack group A 的伺服器切到 routed uplink負責人 · TBD一次一個機櫃，各自的維護時段；回滾方案是保留在 ToR 上的 L2 trunk 設定。
- 驗證 ECMP 與 failover負責人 · TBD
8.3所有伺服器機櫃切到 L3 fabric2027-05-21規劃中 · 0/3
- Rack group B 到 D 的切換波次負責人 · TBD
- 除役 L2 trunk負責人 · TBD
8.4Harvester 具備承接正式流量的條件2027-04-09規劃中 · 0/4
- Longhorn 負責本機系統碟、外接 Rook/Ceph 負責持久資料的分工已經畫好;還沒定的是背後的容量與故障域。
- 備份與還原以實際 VM 演練，而非僅完成設定負責人 · TBD從沒跑過的還原只是一個設定,不是能力 — 而項目 09 會把所有無法容器化的工作負載交給這個平台。
- 「可承接正式流量」的判準明訂並簽收負責人 · TBD項目 09 以此里程碑為前提,它的意義就必須是一條明訂的判準 — 而不是日後在壓力下,由當時負責切換的人臨時判斷。
9.1Harvester 確立為重建的預設落點2027-04-23規劃中 · 0/4
- 對照項目 02 的重建順序記錄落點規則:Harvester、Kubernetes，或留在原地負責人 · TBD項目 02 負責重建服務,不決定它們落在哪裡。少了這條規則,它的波次會先重建到 libvirt 上,同一批服務得再搬一次。
- 工作負載分為三類:上 Kubernetes、於 Harvester 上以容器執行，或維持一般 VM負責人 · TBD不是兩類。一個應用可以已經容器化,卻仍然不能上 Kubernetes — sticky session、日誌寫在本機、假設 replica 永遠不會被替換的狀態。那些會以容器形式落在 Harvester 上(25.4),而不是進項目 26。項目 09 承接的只有第三類:根本無法容器化的那些。
- 波次投入前，先在 Harvester 上驗證一個無法容器化的工作負載負責人 · TBD項目 09 承接的正是麻煩的那些 — 有狀態的設備與授權軟體。到了波次進行中才發現其中一個跑不起來,是代價最高的發現順序。
- 將 2.1 的切換與回滾準則延伸涵蓋 hypervisor 變更負責人 · TBD回滾一次重建是一回事,回滾到一個正在退役的 hypervisor 上是另一回事。2.1 議定時,落點還沒決定。
9.2虛擬機工作負載於 Harvester 重建並完成切換2027-10-08規劃中 · 0/4
- 服務經由項目 02 的波次與樣板在 Harvester 上重建負責人 · TBD重建工作屬於 2.3;項目 09 加上的只是落點為 Harvester。不另立清單,也不另排波次。
- Harvester 虛擬機以 Terraform provider 宣告，而非主控台負責人 · TBD4.2 負責接上 provider;這裡要求重建必須經由它,讓遷移過來的虛擬機從第一天就是程式碼,而不是等日後再清一次。
- Ansible inventory 由 Terraform state 產生，而非另一份清單負責人 · TBD與 4.4 建立的交接點相同。遷移正是手工清單最容易走樣的時候,因為每一台主機的位址會同時改變。
- 各工作負載切換後，libvirt 舊實例確實退役，而非留著待命負責人 · TBD2.3 對重建已有此要求;在這裡它同時是 9.3 得以成立的條件 — 只要主機上還有東西留著待命,它就關不掉。
9.3最後一台 libvirt 主機關機2028-01-28規劃中 · 0/3
- 其餘 libvirt 主機依明訂順序清空負責人 · TBD
- 主機先關機，經明訂隔離期後才移除負責人 · TBD把 3.2 對孤兒 VM 訂下的規矩套用到主機上 — 若誤判了什麼還在使用中,仍然救得回來。
- 最後一台主機關機，並記錄日期負責人 · TBD要到沒有第二套 hypervisor 需要維護,這個項目才算完成。留下一兩台殘存主機,正是兩套平台悄悄變成常態的起點。
9.4退役的 KVM 主機重灌併入 Harvester2028-04-07規劃中 · 0/4
- 主機再利用前先與 Netbox 記錄核對負責人 · TBD5.1 讓 Netbox 成為硬體真實來源;一台從退役狀態回來的主機,正是它的記錄最可能已經過時的時候。
- 經 iPXE 管線重灌，全程無人登入負責人 · TBD5.4 在新上架的伺服器上驗證了這條路徑;再利用的主機走的是同一條,只是磁碟上已經有一套 OS。
- 併入 Harvester 叢集並實際承載工作負載負責人 · TBD
- 記錄與硬體維運的交接:誰負責上架與佈線，誰負責佈建負責人 · TBD權責依循管線而非機器 — 硬體維運交付一台已上架的主機,佈建則與其他節點走同一條自動化路徑。
10.1新 DNS 驗收完成，並盤點仍指向舊 resolver 的客戶端2026-10-30進行中 · 2/4
- 記錄逐站核對預期的解析結果負責人 · Charles
- 盤點仍指向舊 resolver 的機器負責人 · TBD架構已經到位,客戶端還沒有。在這份清單出現之前,關於還剩多少,任何人講得出來的都只有「大部分機器」。
- 將該清單區分為重建波次會帶走的、與需要單獨清掃的負責人 · TBD這個區分決定了項目 10 有多少是自己的工作,而不是項目 02 的副產物。
10.2Zone 記錄納入 Terraform 管理2027-02-12規劃中 · 0/4
- 三個 private hosted zone 以 import 納管，而非重建負責人 · TBD把 4.1 對雲端帳號的規矩套用到這裡 — 程式碼要能描述目前正在應答的 zone,才有資格改動它們。
- 對外與內部 zone 皆納入管線，並關閉主控台路徑負責人 · TBDDNS 正是那種手動變更在「有東西找不到」之前完全看不出來的地方。主控台留著,管線就只是兩個選項之一。
- Unbound 的 forward-zone 設定納入 Ansible 標準負責人 · TBD4.4 讓主機可僅由程式碼重現。forwarding 被手動改過的 resolver,是一台沒有人重建得出來的主機 — 而 DNS 故障時要的正是重建它。
- 每次 zone 變更在套用前先產出可審閱的差異負責人 · TBD
10.3客戶端切換完成，舊 resolver 除役2027-07-16規劃中 · 0/4
- 重建出來的機器一開始就指向新 resolver負責人 · TBD大部分的切換是項目 02 與 09 的性質,而不是項目 10 動手做的事;這條要確認它真的成立。
- 殘留機器清掃:更改 DHCP 選項，並列出與修正靜態設定負責人 · TBD改 DHCP 只帶得走會續約的機器。不會續約的就是一份清單 — 到那時它已經短到可以逐一列名。
- 舊 resolver 先停止應答並觀察，之後才移除負責人 · TBD停止應答會讓還在問的人浮出來,而此時把它放回去仍然只是一道指令。先刪掉,這個發現就會變成一次故障。
- 舊 resolver 除役負責人 · TBD
10.4台中 Site B 除役2028-01-14規劃中 · 0/4
- 先決定原本解析到 Zone B 的名字改指向何處負責人 · TBDZone B 與 A、C 用站點本地記錄回答同一批 FQDN。不先回答這個問題就移除它,正是撤場打掉根本不在那個站點的服務的方式。
- 移除 Site B 的 Unbound 對、Route 53 inbound endpoint 與 Zone B負責人 · TBD
- 記錄為台中 IDC 撤場的前置條件，而非其結果負責人 · TBD撤場是 3.5,而它等待本里程碑。方向很重要:Zone B 先走,不是與站點一起走 — 因為那些名字得先指到別的地方。
11.1L3 模式 K8s 叢集建置完成 — MetalLB BGP 模式2027-02-19規劃中 · 1/3
- 在 L3 fabric 上建置 RKE2 叢集負責人 · Charles
- MetalLB BGP 模式與 ToR pair 對接負責人 · TBD
- 資料路徑文件的 A · B · C 三條路徑都要在新叢集上實際觀察到。
11.2服務分波搬遷，雙叢集並行2027-03-26規劃中 · 0/3
- 各 namespace 的搬遷波次計畫負責人 · TBD
- 第一波服務雙叢集並行負責人 · TBD
- 第二、三波服務雙叢集並行負責人 · TBD
11.3切換完成，舊叢集淘汰2027-07-16規劃中 · 0/2
- 最後一波切換負責人 · TBD
- 淘汰舊叢集負責人 · TBD