K3s 是什麼？為什麼我選擇用 K3s 部署 WeaMind
文章目錄
📌 這是 WeaMind 系列 的第 6 篇。
本系列以真實世界專案為背景，記錄重要技術實作與經驗分享。
「想學 Kubernetes，要用什麼工具？」這是我在轉向 DevOps 時，必須回答的問題。
你可能拿到的標準答案是：「用 Minikube 或 Kind 在本機開個環境，先跑起來再說」。這當然沒錯，對多數人來說是合理的起點。但對我而言，問題則複雜一些。
這篇文章針對「想自己建 Kubernetes 叢集，但又不想搞得太複雜」的情境，說明 K3s 是什麼、適合誰，以及我為什麼最後選擇它。
Minikube 和 Kind：合理的工具，但不是我要的
學習 Kubernetes 的最佳起手式，無疑就是 Minikube 或 Kind 這兩個工具。
它們都是專為在本機快速建立 Kubernetes 環境而設計的，安裝簡單、資源需求低，很適合初學者。
如果你只是想練習 kubectl 的指令、跑幾個 Deployment 看看效果，這兩個工具已經足夠。可謂進入門檻低、環境乾淨、不用花錢，一台電腦就能搞定。
方便的代價
但為了方便與降低門檻，它們在架構上都存在著一定程度的簡化：網路行為、多節點環境、儲存層，這些都和真實 production 環境有差距。
這並非缺點，只是設計上的取捨——為了在本機好用，犧牲了一些真實性。
我需要更多真實感
但對我來說，這個取捨剛好與我的學習目標衝突。我準備轉職 DevOps，想多了解建置過程本身：節點怎麼加入叢集、網路介面怎麼配置、Ingress 怎麼和 Load Balancer 串起來等等。
用真實的 VM 學習，這些議題會更具體些，不被環境提前幫你簡化掉。
剛好我也已經在用 Hetzner Cloud，開一台最小規格的 VM 只需一個月數歐元。有這樣的條件，用真實環境學習似乎是更自然的選擇。
簡言之，不是因為 Minikube 或 Kind 不好，而是對我的目標而言，這樣的做法能得到更接近現實的學習效果。
三條 K8s 叢集建置路線
決定用真實 VM 之後，問題就從「用哪個工具模擬」變成「用哪種方式建立叢集」。這是另一層選擇，面向的是想認真接觸真實環境的人。此時有三條路可以選：
| 路線 | control plane 誰管 | 維運成本 | 適合情境 |
|---|---|---|---|
| EKS / GKE | 雲端供應商 | 低 | 想專注把服務跑起來、不要自己維護底層 |
| kubeadm | 自己 | 高 | 想完整掌握 Kubernetes 底層，或企業需要高度控制 |
| K3s | 自己 | 中 | 想自己建叢集，但不想從零組裝每個元件 |
這三條路代表三種不同的假設，選哪條取決於你的目標是什麼。以下我們依序來看。
EKS / GKE：適合想「省事」的人
EKS / GKE 這類服務屬於託管式 Kubernetes（managed K8s），也就是由雲端供應商代管 control plane 的 Kubernetes。對想把服務跑起來、不想維護基礎設施的情境來說，這是最省事的選擇。
但「省事」只是表面。
它真正的價值在於高可用與穩定性——control plane 的多副本、自動修復、SLA 保證，都不是自己建叢集能輕易複製的——甚至大部分的公司也無法做到這一點。
這是為什麼大部分 production 環境的首選還是 EKS 或 GKE，而不是自建叢集。
對企業來說尤其合理——工程師的時間比 VM 費用貴，沒有必要把人力花在 Kubernetes 底層維護上。它的存在價值，就是讓團隊專注在應用層。
代價是：你幾乎碰不到底層。Control plane 的建置、節點的加入、網路設定大多由雲端處理好，因此你的學習重心會更偏向操作，而不是從頭建置。
kubeadm：適合想掌控底層的人
kubeadm 是 Kubernetes 官方的叢集建置工具，需要你從頭開始，手動組裝：安裝 kubelet、設定 API server、用 token 讓 worker node 加入。
它讓你最直接碰到 Kubernetes 的原生建置流程。這條路適合 platform team，或需要對底層有完整掌控的企業環境。
其代價是複雜——網路套件、憑證管理、etcd 備份，每個環節都要自己處理。
對我這種單人維運的小型專案來說，這樣的複雜度很難換來相應的回報。
K3s：我的選擇
K3s 介於兩者之間。它不像 EKS 那樣把底層全部藏起來，也不像 kubeadm 那樣把所有複雜度都攤在你面前。
對我來說，這正是我需要的平衡。
我選 K3s 的核心原因很簡單：我不只是想把 Kubernetes 用起來，還想理解它是怎麼被建起來的。它的價值不在於「比較輕」，而在於保留了恰到好處的建置細節，同時又不會把維運成本一下子拉得太高。
這是採用 K3s 的幾個實際考量：
- 整合度高：Traefik、Flannel 等網路套件開箱即用，不需要像 kubeadm 一樣逐一自己安裝。
- 夠真實：節點加入、kubeconfig 管理、網路介面綁定這些事還是要自行處理。
- 不適合大型叢集：高度客製化底層或企業級規模的需求，kubeadm 或託管式 K8s 才是更好的選擇。
K3s 是什麼
K3s 不是另一套系統，它是 Kubernetes 的一個發行版（distribution）。
「distribution」這個詞，用過 Linux 的人應該不陌生。Linux kernel 是基礎，Ubuntu、Fedora、Arch Linux 則是不同的發行版（distribution）——它們都是 Linux，但各自做了不同的打包與整合。
K3s 和 Kubernetes 的關係類似：它不是另一套不同的系統，而是建立在 Kubernetes 標準安裝之上的一個輕量發行版，由 Rancher Labs 開發，現由 SUSE（2020 年收購 Rancher Labs）維護，並通過 CNCF 認證。
這裡說的 Kubernetes 標準安裝，就是 Kubernetes 專案原本提供的元件與安裝方式，不會先幫你把常用元件整合成開箱即用的發行版。
和標準安裝相比，K3s 的核心差異是：單一執行檔、更精簡的依賴、預設內建 Traefik Ingress Controller，資料儲存則改用 SQLite 這類較輕量的方案，而非原生的 etcd。
你不需要自己從無到有，把這些零件組裝起來，就能快速擁有一個能跑的叢集。
| Kubernetes 標準安裝 | K3s | |
|---|---|---|
| 安裝方式 | 多元件分開安裝 | 單一執行檔 |
| 預設 Ingress Controller | 無 | Traefik（內建） |
| 預設網路套件 | 無 | Flannel（內建） |
| 資料儲存 | etcd | SQLite（預設，可切換） |
| 記憶體需求 | 較高 | 較低（適合小型 VM） |
| CNCF 認證 | ✓ | ✓ |
WeaMind 的 K3s 叢集長什麼樣
叢集是 1 個控制平面節點 + 2 個工作節點，跑在 Hetzner 私有網路內。
可以把這個架構簡單理解成：應用層放進 K3s 叢集，資料層則獨立留在叢集外。
WeaMind K3s 叢集架構圖，使用 Obsidian 渲染
K3s 預設以 DaemonSet 方式部署 Traefik，所以每台 worker 都會有一個實例。
外部流量先經過 Hetzner Load Balancer 的 TCP 443 passthrough，再在 Traefik 這一層完成 TLS 終止，憑證則由 cert-manager 向 Let’s Encrypt 取得。
資料層沒有放進叢集，而是保留在叢集外的堡壘機，透過 Hetzner 私有網路連接。
結語：剛剛好的複雜
回到最初的問題：想學 Kubernetes，要用什麼工具？
如果你的情境和我類似——個人專案或作品集、目標是理解建置過程、不想花大錢——那 K3s + 雲端 VM 是目前我覺得最務實的起點。
不在 Minikube 和 Kind 之間糾結，也不需要一開始就上託管式 K8s 或硬啃 kubeadm。選一個夠真實、又不會把你淹沒的環境，先跑起來再說。
如果這篇文章對你有幫助，歡迎到 WeaMind GitHub 首頁 給我一個星星
想試用 WeaMind，可掃描下方 QR Code 或搜尋 LINE ID@370ndhmf加入好友
你的支持是我持續分享的動力
