我把 Homelab 的 Docker 換成 Kubernetes，結果跟想的不一樣

Hey，我是 Boson。

最近看到一篇文章，有玩家把自己 homelab 裡跑了快兩年的 Docker Compose，整套搬進 Kubernetes，本來預期「更穩、更好管理」，結果寫的是「跟想的不一樣」。我看完笑了，因為這幾乎是我半年前的翻版。

先講結論：我後來也把一部分服務搬回去了。不是 K8s 不好，是我把「想學的東西」跟「homelab 真正需要的東西」搞混了。

Docker Compose 像合租公寓，K8s 像搬進有物業的社區

我自己最常用的比喻是這個。

用 Docker Compose 管 homelab，像跟室友合租一間公寓——水電自己接、東西壞了自己修，規則簡單到一個 docker-compose.yml 就能講完。你想加一個服務，寫幾行 YAML，docker compose up -d，五分鐘搞定。沒有委員會，沒有審批，你就是房東兼房客。

K8s 是搬進一個有物業管理委員會的社區。社區有消防規範（Pod Security Policy）、停車公約（NetworkPolicy）、社區大會（每次升級都要對齊 CRD 版本）。理論上更安全、更標準化、出事有人扛——但你光是搞懂「垂直車道要怎麼劃」就要花掉一個週末。

對一個五人以下的合租公寓，物業管理委員會不是保障，是行政負擔。

動機跟代價，我一開始沒分開算

老實說，動機裡有一半不是「homelab 需要」，是「我想學」——K8s 是業界標準，趁 homelab 練手又比 prod 環境試錯安全，「既然要學，不如順便把家裡的東西都搬上去」。

這個邏輯把「學習用途」跟「生產用途」疊在一起算帳。我家裡那十幾個服務——Ghost、Tailscale、Obsidian RAG、幾個自動化腳本——本來的需求是「穩定跑、別讓我半夜爬起來修」，不是「高可用、可水平擴展、滾動更新零停機」。K8s 解的問題，是我的 homelab 從來沒遇過的問題。

代價很快就現出來了：

• 一套 etcd 要自己備份，不然整個 cluster 狀態說沒就沒
• 每個服務從一個 YAML 變成 Deployment、Service、Ingress、ConfigMap 四五個檔案
• 升級 K8s 版本變成一個需要排時間做的「專案」，不是隨手 apt upgrade
• 半夜跳出 CrashLoopBackOff，debug 路徑比 Docker Compose 多了至少兩層抽象

最諷刺的是，我原本想解決的問題——「服務掛了要手動重啟」——Docker Compose 加個 restart: unless-stopped 就解決了 90%。我為了那剩下 10% 的場景，換了一整套需要持續維護的基礎設施。這就是典型的「為了學新技術而過度工程化」，換成自己家裡的東西，我還是踩了。

什麼時候 K8s 才值得上

冷靜下來後，我給自己畫了一條線，這條線跟「會不會用」無關，跟「規模」跟「目的」有關：

我現在的 homelab，Ghost、RAG 系統這種「我每天要用、不能掛」的服務，搬回 Docker Compose。真正拿來練 K8s 的，是另外開的一個獨立 cluster，跑一些無關緊要的測試服務，掛了也不影響我的工作流。學習跟生產分開跑，這條線我之前一直沒劃清楚。

結論：不是 K8s 不好，是我選錯了戰場

K8s 本身沒有問題，業界標準不是浪得虛名。問題是我把「想學的工具」直接套到「不需要這個工具的場景」，然後用維運痛苦去交學費。

如果你也在考慮要不要把 homelab 全面 K8s 化，先問自己一句：你是真的需要編排，還是只是想找個理由用一下 K8s？

如果答案是後者，沒關係，那就老實說「我要練手」，開一個獨立的測試環境，不要拿你每天要用的服務當代價。

你的 homelab，現在踩的是哪一種坑？

本文為 BosonFlow 原創，轉載請標示出處。

需要 [架構顧問 / 自動化工作流導入] 服務？歡迎來信： - Email：[email protected]