iT邦幫忙

2026 iThome 鐵人賽

DAY 29
0
AI Engineering

Agent 開發, 從本地到雲端: AI 工程師的 K8s 筆記系列 第 29 篇

Day 29|維運日常:升級、備份還原、preemption 演練、成本告警,AI 工程師的最小 SRE 清單

  • 分享至 

  • xImage
  •  

cover

POV:部署成功那天你截圖發到群組,過一陣子某個早上機器自己重開,你才發現「部署成功」跟「它會一直活著」是兩件事。

昨天的表把四個服務擺好了位置。今天講擺好之後的事:所謂 Day 2。這篇不是要把你變成 SRE,是一張給 AI 工程師的最小清單,只挑四件事,每件附一個最省力做法,跟一個我自己踩過的雷。

1. 升級:讓平台動手,但要知道它什麼時候動

K8s 版本、節點 OS、base image,三層都要升。GKE 跟 AKS 這類代管服務會自動升 control plane,節點也可以設成自動升級:GKE 有 node auto-upgrade 加 maintenance windows,AKS 有 --auto-upgrade-channel 加 planned maintenance。

最省力做法:開自動升級,但一定要設維護時段;關鍵服務給兩個以上的 replica,並用 PodDisruptionBudget 限制同時被驅逐的數量。只有一個 replica 的話,節點升級把那顆 Pod 趕走的那段時間,服務很可能就是斷的。

我的雷:這條我還沒在 K8s 上踩到,但在 VM 上看過類似的:2026-09-07 dev-box 重開了一次,前後 kernel 從 6.17 變成 7.0(兩者的因果我沒有確認)。如果底層是別人在管的,它換底層的時機不一定配合你;維護時段的價值,就是讓「被換掉」盡量變成可以預期、可以排程的事。

2. 備份還原:先問「哪些東西掉了會痛」

容器用完即丟,要備份的從來不是容器,是狀態:資料庫、向量庫(devstack 的 qdrant 就是)、使用者上傳的檔案,還有 agent 系統特別在意的對話與 session 紀錄。

最省力做法:狀態全部放叢集外(代管資料庫、物件儲存),讓叢集本身維持「隨時可以整個重建」。這樣叢集這一層的還原才會只剩重新 apply YAML(Day 27 示範過那有多短)。但叢集外的資料庫、物件儲存本身還是要備份、還原流程也要真的演練過才算數;把狀態搬出叢集,是把備份責任搬到別處,不是讓它消失。

我的雷:我的 agent session 是持續落盤的 JSONL 檔。9/7 那次重開之後,我實際確認過的只有這一項:session 的 JSONL 都還在。這足以說明「關鍵狀態持續落盤」是對的;其他資料我沒有逐一核對,不多說。反過來說,把關鍵狀態只放在記憶體或容器內暫存檔的 agent,重開機就等於歸零。

3. Preemption 演練:故意讓它死一次

這是我最推、也最容易被跳過的一條。用 Spot 節點省錢的話(AI workload 很常見:GKE Spot Pods、AKS Spot node pool),你就得接受機器隨時會被回收。沒故意演練過的話,很可能就是在真的被回收那天才第一次驗證還原機制,我自己就是。

我的雷:dev-box 是 Spot VM,Cloud Scheduler 每 5 分鐘把被回收的 VM 拉起來,容器靠 restart policy 自己回來。2026-09-07 早上它重開了一次(原因我沒有確認,Day 18 講過),我設好的自動還原是開機時重建 tmux 配置、把 agent session 接回來。結果有一部分沒回來:無人值守開機沒有終端機,tmux 預設視窗只有 80x24,split-window 切到第五個 pane 就 no space for new pane。更糟的是 15 分鐘一次的快照在重開後照跑,保留 5 份,幾輪就把「重開前的健康快照」輪替掉了。

教訓:無人值守還原要先設視窗尺寸;快照輪替要保護最後一次健康狀態。 後來 9/15 它又重開了一次,13 隻 OpenAB 容器在開機後 22 秒全部自己回來,這是 restart policy 的功勞;但容器這層過關不代表 tmux 那層也過關,兩層要分開驗。

最省力做法:挑個沒人用的時段,手動砍掉一個節點或 VM,看服務會不會自己回來、回來之後完不完整。K8s 上通常比 VM 輕鬆:只要還有別的節點、資源夠、排程條件(node selector、taint)允許,Deployment 會把 Pod 排到別的節點;單節點叢集或資源塞滿時,砍節點就是直接中斷。「狀態有沒有完整帶回來」則還是要你自己看。

4. 成本告警:在帳單來之前知道

Day 28 面向 3 說過:節點型的東西忘了關就一直計費,Autopilot 的 Pod 留著也在付。最省力做法是在雲端上設預算告警(GCP budgets、Azure cost alerts),門檻設在「看到會心痛但不會破產」的金額,通知送到你每天會看的地方。

我的雷:9/6 那次記憶體壓力,追到一個閒置 45 小時的 dev 容器吃了 1.25 GiB(Day 04)。那不是帳單問題,但本質一樣:開了沒人關是常態,不是意外。 成本告警是對抗這種常態的一層被動防線;預算上限、配額、閒置自動關閉是更前面的護欄,這篇先講最省力的這層。

最小清單,可以直接抄:

  • [ ] 開自動升級、設維護時段,關鍵服務 replica 兩個以上並設 PodDisruptionBudget
  • [ ] 狀態全放叢集外,叢集本身隨時可重建
  • [ ] 定期手動砍一次節點或 VM,驗證自動且完整地回來
  • [ ] 設預算告警,通知送到每天會看的地方

明天收尾:三十天之後,我對「AI 工程師該懂多少 K8s」的一頁式答案。

今日一句話

Day 2 的最小清單四項:升級交給平台但設好時段、狀態放叢集外、故意殺一次驗證還原、預算告警卡在心痛線;「故意殺一次」不做,你很難知道還原機制是真的還是裝飾。

延伸閱讀


上一篇
Day 28|GCP 與 Azure 對照總表:GKE / Cloud Run / AKS / ACA,同一個 agent workload 的 5 個面向
下一篇
Day 30|收尾:30 天後我對「AI 工程師該懂多少 K8s」的一頁式答案,系列索引與下一步
系列文
Agent 開發, 從本地到雲端: AI 工程師的 K8s 筆記 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言