Docker 與 Kubernetes，各是什麼？
兩個名字常被綁在一起講，好像要二選一——但它們其實不在同一層做事
「該用 Docker 還是 Kubernetes？」這個問題有點怪
你大概聽過這句話：要跑現代的雲端應用，得會 Docker，還要會 Kubernetes。於是很自然會冒出一個問題——那我到底該用哪一個？這正是這篇 ByteByteGo 圖解丟出的開場問句。
但先別急著選邊。這篇短文其實想讓你發現一件事：這兩個工具解決的不是同一個問題，也不站在同一個高度。搞懂它們各自在幹嘛，「該用哪個」這題往往就自己解開了。
把一支應用程式想成一批貨。容器就像海運貨櫃——不管裡面裝什麼，尺寸規格一致，可以疊、可以搬、可以上船。Docker 是把貨裝進貨櫃、再在單一港口把它卸下來跑的那套工具；Kubernetes 則是排程整支貨櫃船隊的港務局：哪個貨櫃該放哪台機器、某台當機了誰來頂上、貨量暴增時要不要多開幾台。一個管單一貨櫃，一個管整個船隊。
直接讀原文：兩句定義
與其聽轉述，不如逐字核對 ByteByteGo 對這兩個工具下的定義。留意兩個關鍵字：Docker 說的是 containerization（容器化），Kubernetes 說的是 container orchestration（容器編排）。
Docker 是一個開源平台，讓你能把應用程式打包、散布，並在隔離的容器裡執行。
它專注在容器化——提供輕量的環境，把應用程式和它的依賴一起包起來。
Kubernetes（常被簡稱為 K8s）是一個開源的容器編排平台。
它提供一套框架，用來自動化容器化應用的部署、擴縮與管理，而且是跨越一整群節點來做。
Docker 的關鍵字是「打包 + 跑起來」（單一容器）；Kubernetes 的關鍵字是「跨一群機器自動管理」（一大堆容器）。前者處理「一個」，後者處理「一群」——這條線，貫穿整篇文章。
兩張卡片，兩種角色
把定義攤成兩張並排的卡片，你會更清楚它們各自負責什麼、又刻意不管什麼。
一個開源平台，負責把應用程式打包、散布、並在隔離的容器裡執行。它專注在依賴的封裝，給你一個輕量、一致的執行環境——但它管的，就是「這一個容器怎麼跑起來」。
一個開源的容器編排平台。它提供一套框架，自動化容器化應用的部署、擴縮與管理，而且是跨越一整群節點來做。它不在乎某一個容器內部怎麼跑，它在乎的是「這一大群容器整體是不是照你要的狀態在運作」。
Kubernetes 太長了，工程師習慣寫成 K8s——取開頭的 K、結尾的 s，中間 8 個字母就用數字 8 代替。之後看到 K8s，你就知道講的是同一個東西。
小試身手
先確認你抓到了兩個定義的重點，再往下看它們到底差在哪一層。
知道了各自的定義，接下來把兩者放在同一張圖上比。你會看到 Docker 待在「單一主機」的高度，而 Kubernetes 站在「跨叢集」的高度自動幫你排兵佈陣。往下捲。
它們差在哪一層？
Docker 待在單一主機的容器層級；Kubernetes 站上跨叢集的編排層級——差別不是好壞，是高度
關鍵在「層級」：單一主機 vs. 整個叢集
原文用一句話點破兩者最根本的差異——它們在不同的層級做事。先讀原文，再拆開來看。
Docker 運作在「單一作業系統主機上的個別容器層級」。
你必須手動管理每一台主機；一旦要替多個相關容器設定網路、安全政策和儲存，事情會變得很複雜。
Kubernetes 運作在「叢集層級」。它跨越多台主機管理多個容器化應用，為負載平衡、擴縮、確保應用的期望狀態這些工作提供自動化。
原文點出關鍵痛點：用 Docker 時，每一台主機你都得手動管。機器少的時候還好；一旦是幾十、幾百個容器散在許多台機器上，光是把網路、安全政策、儲存串好就足以讓人崩潰。這正是「該換 Kubernetes」的訊號。
Kubernetes 幫你自動化的三件事
原文明確列出 Kubernetes 在叢集層級自動幫你打理的工作。這三個詞，是理解 K8s 為什麼存在的核心：
把湧進來的流量平均分散到多個容器上，不讓某一台被打爆、其他台卻閒著。
流量變大就自動多開幾個容器撐住，流量變小就縮回去省資源——不用你半夜爬起來手動加機器。
你只要宣告「我要跑 5 個容器」，K8s 會持續盯著，掛了一個就自動補一個，永遠維持在你要的樣子。
傳統做法是你「一步步下命令」讓系統變成某個樣子；Kubernetes 反過來，你只「宣告最終想要的樣子」，剩下的差異由它自己補齊。某台機器當掉、某個容器崩潰，它會自動重開、重新調度——這種「你說要什麼、它負責維持」的模式，正是原文所說的 ensuring the desired state。
點點看：一個 Kubernetes 叢集長什麼樣
下面是一個簡化的 K8s 叢集。上面是負責決策的控制層，下面是實際跑容器的一群節點（node）。點任何一塊，看它在整個編排裡扮演什麼角色。
如果把 Docker 放進這張圖，它大概只負責「在某一個節點上，把某一個容器跑起來」——也就是圖裡的一個小格子。整張圖怎麼協調、誰放哪、掛了誰補，那是 Kubernetes 站在叢集高度做的事。這就是「層級不同」最直觀的樣子。
動手分分看：這件事該找誰?
下面是幾個實際情境或職責。依照原文對兩者的定位，把每一張拖到負責它的工具——「Docker（單一主機、容器層級）」還是「Kubernetes（跨叢集、編排層級）」。拖完按「對答案」。
看到「打包、封裝、在一台機器上跑起來」——那是 Docker 的容器層級；看到「跨多台、自動、負載平衡、擴縮、維持狀態」——那是 Kubernetes 的編排層級。這也對應原文那句總結：Docker 專注容器化與在個別主機上跑容器，Kubernetes 專精於大規模跨叢集地管理與編排容器。
所以，該用哪一個？
原文用一句 In short 收攏了整篇。讀完這句，開場那個「二選一」的問題就會鬆開。
簡而言之：Docker 專注在容器化、以及在個別主機上把容器跑起來；而 Kubernetes 專精於大規模地跨一群主機管理與編排容器。
依原文的定位，這兩者處在不同層級、解決不同層級的問題：先用 Docker 把應用打包成容器，規模變大、要跨多台機器自動管理時，再讓 Kubernetes 來編排這些容器。原文結尾的提問也呼應這件事——它問的是「什麼樣的挑戰，促使你從 Docker 轉向 Kubernetes」，暗示的正是一條隨規模成長的路徑，而非對立的取捨。
小試身手
抓住「層級不同」這條主線，這章就通了。來兩題收尾：
下次有人問你「Docker 還是 Kubernetes」，你可以反問：你的問題是「怎麼把一支應用打包跑起來」，還是「怎麼跨一大群機器自動管理一堆容器」？前者用 Docker，後者才輪到 Kubernetes——它們是不同層級的隊友，不是對手。