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：適合想「省事」的人
Control plane 由雲端管理，你只需要管 worker node 和應用程式。對想把服務跑起來、不想維護基礎設施的情境來說，這是最省事的選擇。
但「省事」只是表面。managed K8s 真正的價值在於高可用與穩定性——control plane 的多副本、自動修復、SLA 保證，都不是自己建叢集能輕易複製的——甚至大部分的公司也無法做到這一點。
這是為什麼大部分 production 環境的首選還是 EKS 或 GKE，而不是自建叢集。
對企業來說尤其合理——工程師的時間比 VM 費用貴，沒有必要把人力花在 Kubernetes 底層維護上。managed K8s 的存在價值，就是讓團隊專注在應用層。
代價是：你幾乎碰不到底層。Control plane 的建置、節點的加入、網路設定都由雲端處理好，你學到的就只有操作，不是建置。
kubeadm：適合想掌控底層的人
kubeadm 是 Kubernetes 官方的叢集建置工具，從頭手工組裝：裝 kubelet、設定 API server、用 token 讓 worker node 加入。學習深度最高，最貼近 Kubernetes 原始面貌。
這條路適合 platform team，或需要對底層有完整掌控的企業環境。
代價是複雜——網路套件、憑證管理、etcd 備份，每個環節都要自己處理。
對我這種單人維運的小型專案來說，這樣的複雜度很難換來相應的回報。
K3s：我的選擇
K3s 介於兩者之間。它不會像 EKS 那樣把底層全部藏起來，也不像 kubeadm 那樣把所有複雜度都攤在你面前。對我來說，這正是我想要的平衡。
我選 K3s 的核心原因很簡單：我不只是想把 Kubernetes 用起來，還想理解它是怎麼被建起來的。它的價值不在於「比較輕」，而在於保留了恰到好處的建置細節，同時又不會把維運成本一下子拉得太高。
幾個實際考量：
- 整合度高：Traefik、Flannel 網路套件開箱即用，不需要像 kubeadm 一樣逐一自己裝
- 夠真實：節點加入、kubeconfig 管理、網路介面綁定這些事還是要自己處理
- 不適合大型叢集：高度客製化底層或企業級規模的需求，kubeadm 或 managed 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 專案原本提供的元件與安裝方式，不會先幫你把常用元件整合成開箱即用的發行版。
和 Kubernetes 標準安裝相比，K3s 的核心差異是：單一執行檔、更精簡的依賴、預設內建 Traefik Ingress Controller，並以 SQLite 取代 etcd 作為資料儲存（有需要也可以換回 etcd）。
你不需要自己從零把這些零件拼起來，就能快速擁有一個能跑的叢集。
| Kubernetes 標準安裝 | K3s | |
|---|---|---|
| 安裝方式 | 多元件分開安裝 | 單一執行檔 |
| 預設 Ingress Controller | 無 | Traefik（內建） |
| 預設網路套件 | 無 | Flannel（內建） |
| 資料儲存 | etcd | SQLite 取代 etcd（可換回） |
| 記憶體需求 | 較高 | 較低（適合小型 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 之間糾結，也不需要一開始就上 managed K8s 或硬啃 kubeadm。選一個夠真實、又不會把你淹沒的環境，先跑起來再說。
如果這篇文章對你有幫助，歡迎到 WeaMind GitHub 首頁 給我一個星星
想試用 WeaMind，可掃描下方 QR Code 或搜尋 LINE ID@370ndhmf加入好友
你的支持是我持續分享的動力
