K3s 是什麼？輕量級 Kubernetes 完整介紹：架構、安裝、適用場景一次看懂

K3s 是 SUSE（前身 Rancher Labs）推出的輕量級 Kubernetes 發行版，二進位檔不到 100MB，最低 512MB RAM 的機器就能跑起來。它通過 CNCF 完整認證，意思是你寫的 YAML 可以直接搬到正式的 Kubernetes 叢集——只是它把 cloud-provider、legacy、alpha 等用不到的東西全部拔掉，最後變成一顆 single binary。為邊緣運算、IoT 裝置、CI/CD pipeline、開發環境量身設計。

這篇會帶你完整搞懂 K3s 的來歷、架構設計、預設內建了什麼、實戰怎麼裝，以及最重要的——什麼情境該用、什麼情境不要硬塞。如果你對容器化還沒概念，建議先看 Docker 是什麼？為什麼工程師愛用容器化 補一下基礎，再回來讀這篇會更順。

K3s 是什麼？從 Kubernetes 講起

先補位 30 秒：Kubernetes 在做什麼事？

Kubernetes（簡稱 K8s，K 加 8 個字母加 s）是 Google 在 2014 年開源的容器編排系統，前身是 Google 內部代號 Borg 的調度系統，目前由 Cloud Native Computing Foundation 維護。它要解決的問題很具體：當你有 100 個 container 散在 10 台機器上跑，誰來決定每個 container 該排在哪一台、哪一台死了該怎麼自動把它搬到別處、流量該怎麼平均分配、版本要怎麼滾動更新——這些事情手動做會把人逼瘋，K8s 就是那個自動處理的編排者。

K8s 的世界有幾個關鍵詞要記：Pod 是最小調度單位（一個或多個 container 綁在一起跑）、Deployment 描述「我希望這個服務跑幾份、用什麼 image」、Service 處理叢集內外的網路存取、Node 是底層那台機器。你寫一份 YAML 把這些講清楚，K8s 就會想辦法讓現實狀態符合你的描述。這個「宣告式管理」是它的精髓，跟傳統「我下指令、機器執行」的命令式思維完全不同。

從 2015 年釋出 1.0 開始，K8s 十年來幾乎輾壓了所有競爭對手——Docker Swarm、Mesos、Nomad——原因不複雜：自動恢復、自動擴縮、宣告式 API、生態系極大。但這些好處的代價是「重」：一個基本可用的叢集要好幾 GB 記憶體、幾十個 process、複雜的網路與儲存設定。對工廠裡那台 4GB RAM 的邊緣盒子、或開發者筆電上想跑個測試環境的場景來說，標準 K8s 根本裝不進去。這就是 K3s 的切入點。

想更完整地理解 Kubernetes 在做什麼、為什麼會出現、適合哪些團隊？延伸閱讀：Kubernetes 是什麼？容器編排核心概念與適用場景完整介紹，那篇文章從架構、核心物件到適用場景全部講清楚。

K3s 的名字怎麼來？

名字其實是個工程師梗。K8s = K + 8 個字母 + s，那把它砍一半呢？K + 4 個字母 + s = K4s 嗎？不是。Rancher Labs 在 2019 年釋出時的內部說法是「Kubernetes 的記憶體佔用大概要砍一半」，所以暱稱就變成 K3s。沒有官方全名、不是縮寫，就是「半個 K8s」的意思。

這個命名背後的設計哲學很直接：把標準 Kubernetes 拿來，砍掉資料中心級才用得到的功能、把外掛換成輕量替代品、把所有東西打包成一個可執行檔。最後產出的東西，依然是「真正的」Kubernetes——只是穿上了適合邊緣場景的合身衣服。

Cloud Native Computing Foundation 在 2026 年 1 月公布的 2025 年度雲端原生調查報告 顯示，82% 的容器使用者已經把 Kubernetes 跑在 production 環境，628 位受訪 IT 專業人員確認 K8s 已經變成跑 AI workload 的事實上作業系統。但這個統計沒告訴你的是：剩下 18% 不是不想用，很多是被資源門檻擋在外面——這就是 K3s 想解決的事。

K3s 在 2020 年正式被 CNCF 接收為 Sandbox project，2022 年升級為 Incubating project。背後的維護者是 SUSE（2020 年併購 Rancher Labs），生態系還包含整個 Rancher 家族（Rancher Manager、Longhorn、RKE2 等），所以你選 K3s 不是選一個短命專案——它有商業公司在養。

K3s 的架構設計：怎麼把 Kubernetes 縮成一顆 binary

標準 Kubernetes 部署起來是一群 process：kube-apiserver、kube-scheduler、kube-controller-manager、etcd、kubelet、kube-proxy⋯⋯每個都要單獨啟動、單獨設定。光是想搞懂「誰跟誰講話」就足以勸退新手。K3s 的做法是把這一切打包成同一顆 Go binary，啟動時用 process 管理機制把它們跑起來。

這個設計的好處不只是「檔案小」，更關鍵的是運維上的簡化。沒有跨 process 的 IPC 設定、沒有版本錯配的可能（因為都是同個 binary）、升級就是換一顆檔案重啟。對在 100 個工廠端點都要部署叢集的場景，這個差異直接決定「能不能落地」，遠超過幾個百分點的優化。

用 SQLite 取代 etcd 是 K3s 最大膽的決定

Kubernetes 的所有狀態資料都存在 etcd 裡——這是一個高可用的分散式 key-value store。問題是 etcd 本身就是個重的元件：要 quorum、要選舉、磁碟 I/O 要快、記憶體吃得不少。對單節點或邊緣環境來說，這完全是殺雞用牛刀。

K3s 預設改用 SQLite。對，就是那個寫嵌入式系統會用的 SQLite。對單節點叢集來說，SQLite 的效能完全夠用，而且少了一大塊複雜度。多節點 HA 場景下，K3s 會切換到 embedded etcd（仍然包在那顆 binary 裡），或者你也可以指定外接 MySQL / PostgreSQL。

被砍掉的東西：你不會想念的 legacy 包袱

K3s 拿掉了大量「資料中心 K8s 才需要、邊緣場景用不到」的元件。看下面這張對照表就清楚：

這張表的重點在於「K3s 把選擇做掉了」，而非單純「K3s 比較少功能」。標準 K8s 給你 100 種選項——你要選 CNI、選 ingress、選 LB、選 storage——然後你會花三天試錯找到能跑的組合。K3s 直接幫你選好，跑起來就有 ingress、有 LB、有 DNS。要換也可以，但 80% 的場景不用換。

K3s 與 K8s 的快速對比表

如果你只想知道「跟 K8s 比起來怎麼選」，先看這張對照表抓個感覺。完整的架構深挖、效能 benchmark、決策樹會在系列下一篇 K3s vs K8s 完整比較：怎麼選？ 處理。

一句話總結：K3s 把同一套 Kubernetes API 用更聰明的方式打包，讓資源受限或不想養 DevOps 團隊的場景也跑得起來——功能並沒有真的減少。

K3s 適合什麼場景？四個主流應用情境

有一個產業數據很值得參考——Loginline 整理的 2026 Kubernetes 趨勢報告 預估到 2026 年，75% 的企業資料會在邊緣端處理，67% 的企業計畫在邊緣 / Kubernetes / K3s 領域投資。這個數字背後反映的是同一個趨勢：把運算搬到使用者旁邊。而能跑在低資源裝置上、又是 Kubernetes 標準的選項，沒有比 K3s 更主流的了。

場景一：邊緣運算（工廠、零售、電信）

一條產線上有 30 台 PLC、5 台視覺檢測相機、2 台邊緣 AI 推論伺服器。它們不能等資料傳回雲端再處理，網路斷掉也不能停線。傳統做法是每台機器自己跑各自的 service，沒有編排、沒有自動恢復、沒有統一管理。K3s 的角色是把整條產線變成一個小型叢集，掛掉的容器自動重啟、設定變更可以從中央 GitOps 推下來。

零售業也類似。一家便利商店有 POS、監控、會員系統、廣告播放——這些東西如果都是獨立 Docker container 各跑各的，店長根本管不了。把它們收進 K3s，加上 Rancher 中央管理，總部能看見每家店的容器狀態、批次升級、故障告警。

場景二：IoT 裝置與 Raspberry Pi 叢集

這是 K3s 最有名的場景。一個典型例子：某個農業監控系統用 Raspberry Pi 4（2GB RAM）跑 K3s，管理一整片田裡的土壤感測器和氣象站。網路不穩、電力不穩，但只要 Pi 不死，叢集自己會處理服務的重啟和路由。

Homelab 玩家也吃這套。Hacker News 上的自架基礎設施討論串 裡有很多人分享用 3-5 顆 Pi 組叢集，跑 Pi-hole、Home Assistant、Plex、自家的程式。一台壞掉就讓另一台接手，這種小規模 HA 用 docker-compose 寫不出來，用 K3s 一個 manifest 搞定。

場景三：CI/CD pipeline 的暫時性測試環境

每次 PR 進來，CI 啟動一個 K3s 叢集、把整套服務跑起來、跑完整合測試、銷毀叢集——整個過程不到兩分鐘。標準 K8s 啟動時間夠你泡杯咖啡，K3s 30 秒就能讓你開始跑測試。

這在 GitHub Actions、GitLab Runner、Jenkins 上都很常見的模式。如果你還在用 Docker Compose 寫整合測試，可以參考 CI/CD 是什麼？自動化部署完整指南 了解 CI/CD pipeline 的全貌，再考慮要不要把測試環境升級成 K3s。

場景四：本地開發環境，學 Kubernetes 用

第一次學 K8s 的工程師最怕的就是「裝環境裝到爆炸」。Minikube 啟動慢、Kind 跟生產環境差太多、Docker Desktop 內建的 K8s 又重又吃資源。K3s 給你一個「跟生產一樣是 single-process Kubernetes、但啟動快、資源吃得少」的甜蜜點。

筆電開發、寫個 deployment.yaml 直接 apply、打 service、配 ingress——K3s 內建的 Traefik 會幫你把 .local 的網域都接好。這個體驗對學習者來說很關鍵：你不會卡在「怎麼讓我的 service 對外」這種環境問題，可以直接學 K8s 本身。

K3s 安裝實戰：從零到第一個 Pod

理論講夠了，動手裝一次最有感。K3s 的安裝指令真的就是一行——這在 Kubernetes 世界裡是奇蹟。

Server 節點安裝（控制平面）

找一台 Linux 機器（任何發行版，Ubuntu / Debian / CentOS / openSUSE 都行），執行：

curl -sfL https://get.k3s.io | sh -

這條指令會下載 K3s binary、安裝成 systemd service、自動啟動。執行完之後，你的 K8s 控制平面已經跑起來了。驗證一下：

sudo k3s kubectl get nodes
sudo k3s kubectl get pods -A

應該會看到一個 Ready 狀態的 node，加上 kube-system namespace 裡面 coredns、traefik、metrics-server、local-path-provisioner 等一堆 Pod 已經在跑——這些是 K3s 預設幫你裝好的。

Agent 節點加入（多節點時才需要）

如果你要加更多節點變成多節點叢集，先在 server 拿到 token：

sudo cat /var/lib/rancher/k3s/server/node-token

然後在 agent 機器上執行（替換 SERVER_IP 和 TOKEN）：

curl -sfL https://get.k3s.io | K3S_URL=https://SERVER_IP:6443 K3S_TOKEN=TOKEN sh -

回 server 端 kubectl get nodes 應該就能看到 agent 加進來了。

跑你的第一個 deployment

確認叢集 OK 之後，跑一個經典的 nginx 試試：

sudo k3s kubectl create deployment nginx --image=nginx
sudo k3s kubectl expose deployment nginx --port=80 --type=LoadBalancer
sudo k3s kubectl get svc nginx

注意 service type 我們選了 LoadBalancer。在標準 K8s 裡，這需要雲端 LB 配合才會拿到 external IP；但 K3s 內建的 ServiceLB（Klipper）會直接拿節點的 host port 出來給你，所以你會立刻看到 external IP——這就是 K3s 開箱即用的一個小驚喜。

K3s 預設內建了什麼？開箱即用的元件

K3s 的另一個亮點是「裝完就有」的元件。標準 K8s 裝完之後你還要自己挑 ingress controller、挑 storage provisioner、挑 LB——K3s 都幫你選好了。

有些人會抱怨「這些元件都是 K3s 自己選的、沒得改」——其實不是，每個都可以在安裝時用 --disable 旗標關掉，然後自己裝想要的。但說真的，預設組合對 80% 的場景都夠用。除非你有很明確的需求（例如要用 cert-manager + nginx-ingress 的組合），不然動它的 ROI 不高。

什麼情況不該用 K3s？真實限制

K3s 很香，但不是萬靈丹。下面這些場景，你應該選標準 K8s 或其他方案。

超過 50-100 節點的大型叢集

K3s 官方有給過參考數字：3 個 server 節點（每個 4 vCPU / 8GB RAM）的 HA 配置可以撐到約 1200 個 agent。聽起來很多，但這已經是極限。k3s GitHub discussions 上對節點上限的討論 中，社群實務經驗是 50-100 節點以內最舒服，再上去 etcd 跟 SQLite 都會開始吃力。如果你要跑 500+ 節點的大型叢集，老實選標準 K8s + 外接 etcd cluster 比較實在。

需要深度雲端整合（cloud-controller-manager 內建功能）

K3s 把 in-tree cloud provider 全部砍掉了。如果你要用 AWS ELB / GCP Load Balancer / Azure Disk 這些雲端原生資源，需要自己另外裝 out-of-tree cloud-controller-manager。在大型 EKS / GKE 場景，K3s 的優勢就消失了——你已經不缺資源、也已經有雲廠管控制平面，何苦再用輕量版？

依賴 alpha API 或非主流 CRD 的特殊場景

K3s 為了保持穩定性，會比標準 K8s 慢一點才支援新功能，alpha API 也經常被預設關閉。如果你的應用依賴某個剛出爐的 alpha 功能，要先確認 K3s 版本有沒有支援。

純 Windows 容器負載

K3s 設計給 Linux node 跑 Linux container，沒打算支援 Windows worker。如果你需要在 K8s 上跑 .NET Framework 老應用，要找其他方案。

學完之後：你的下一步

讀到這裡，你應該對 K3s 有了清楚的輪廓——它是什麼、為什麼存在、怎麼跑起來、什麼時候用、什麼時候不用。如果只是「想知道 K3s 是什麼」，到這裡就可以收工了。

但如果你正在做技術選型——「我們公司到底該選 K3s 還是 K8s？」——那這篇還不夠。架構深度比較、效能 benchmark、生產環境真實取捨、決策框架，這些會在系列下一篇 K3s vs K8s 完整比較：架構、效能、適用場景一次說清楚 完整討論。

如果你還沒走過容器化這一關，先把 Docker 是什麼？為什麼工程師愛用容器化 補上，再來看 K8s 系列會輕鬆很多。如果你想直接把應用跑起來、不想自己維護叢集，可以參考 Zeabur 部署平台評價——某種程度上，PaaS 平台幫你把 K8s 都包掉了。

K3s 常見問題

把 K3s 用在你的場景上

K3s 真正的價值，在於「讓更多場景用得起 Kubernetes」——「比 K8s 輕」只是達成這個價值的手段。如果你的工廠想做邊緣推論、零售門市要中央管理、開發團隊想要更貼近生產的測試環境，K3s 都是值得認真評估的選項。

如果你正在規劃內部系統、邊緣部署架構，或想找人幫忙評估「我們到底該不該上 Kubernetes」，可以聊聊我們的 AI 與系統開發顧問服務。從技術選型到實際落地，我們協助過不少中小企業跨過這一關，知道哪些坑該繞、哪些工具該選。

讀完這篇，你已經知道 K3s 是什麼、長什麼樣、適合什麼。下一步建議直接讀系列第二篇 K3s vs K8s 完整比較，把選型問題一次釐清。