論壇

你好，已經查到這次事件的根本原因，逐點回覆：

1. 13:52–14:01 是否有節點維護／drain？為何在非設定時間重啟？ 是的。當天 13:38–13:52（UTC）ap-east-2（AWS）叢集進行了一輪節點輪替：多台底層節點被終止（事件紀錄為「節點已不存在於雲端供應商」），同時啟動新節點接手。你的 app 與 PostgreSQL Pod 因為原節點被移除而被重新排程到剛加入的新節點。所以這次重啟與你設定的 06:00 定時重啟無關，是平台節點輪替造成的非預期重排。

2. DB 為何約 68 分鐘才恢復？是否與 aws-cni IP 分配失敗有關？ 是，主因有兩個，且兩者相關：

• 新節點剛加入、aws-cni 尚未把網路（ENI／IP 池）準備好，當下又有大量被重排的 Pod 同時湧入（整個叢集數十個服務在同一時間都出現「failed to assign an IP address」），導致 IP 配發塞車，Pod 卡在無法建立網路。
• 新節點是「冷節點」、沒有任何映像快取，需要重新拉取映像。你的 PostgreSQL（postgres:18）映像在紀錄中顯示拉取約 1 小時 7 分（含等待），app 映像約 24 分鐘（含等待）。這兩段等待就是中斷被拉長到約 68 分鐘的主因。

換句話說，這不是 DB 本身的問題（你提供的 CPU/記憶體也佐證沒有 OOM），而是「重新排程 + 網路配發 + 重新拉取映像」的恢復過程過久。

3. PostgreSQL 是否有平台側或誤設定的定時重啟？ 沒有。這次 DB 重啟是上述節點輪替造成的 Pod 重排（Pod 名稱有更換、映像重新拉取），並非 in-place 的定時重啟。你的服務上沒有平台側的定時重啟設定，無需關閉。

4. 未來這類維護是否有事前通知或狀態頁可訂閱？ 平台事件可在狀態頁 https://status.zeabur.com 查看，目前提供 RSS 訂閱（https://status.zeabur.com/feed ，可加進 RSS 閱讀器或自動通知）。另外我們已將這次節點輪替造成 aws-cni IP 配發塞車、以及冷節點重拉映像導致恢復過久的問題回報給基礎設施團隊，會改善節點輪替時的排空與 IP 預熱流程，降低之後類似情況的中斷時間。

補充建議： 這次中斷的根源在於「共享叢集」的節點會隨平台維護一起輪替，你的 Pod 因此被迫重排到剛開機的新節點。如果你的服務對連線穩定度要求較高，可以考慮改用 專用伺服器（Dedicated Server）：專用伺服器是單租戶的獨立節點，不會被納入共享叢集的整體節點輪替，能大幅降低這類非預期重排與恢復過久的影響；同時節點上已有映像快取，重啟恢復也更快。如果有興趣，我可以再協助你評估適合的規格。