Docker 入門容器化如何改變軟件交付以及它和 Kubernetes 到底有什么區(qū)別一句話版本Docker 負(fù)責(zé)把一個應(yīng)用打包并跑起來Kubernetes 負(fù)責(zé)把成百上千個這樣的應(yīng)用管好。兩者不是競爭關(guān)系而是上下游的互補關(guān)系。一、Docker 是什么Docker 是一個開源的容器化平臺它把應(yīng)用及其所有依賴代碼、運行時、系統(tǒng)庫、配置文件打包成一個標(biāo)準(zhǔn)化的單元——容器鏡像Image。這個鏡像在任何安裝了 Docker 的機(jī)器上都能以完全相同的方式運行。容器 vs 虛擬機(jī)很多人第一次接觸容器時會拿它和虛擬機(jī)對比虛擬機(jī)VM容器Container虛擬化層級虛擬化硬件每個 VM 帶一個完整 Guest OS虛擬化操作系統(tǒng)共享宿主機(jī)內(nèi)核啟動速度分鐘級秒級甚至毫秒級體積GB 級MB 級隔離性強(qiáng)獨立內(nèi)核進(jìn)程級隔離namespace cgroup資源開銷高低容器本質(zhì)上是 Linux 內(nèi)核提供的兩種機(jī)制的組合Namespace命名空間讓進(jìn)程看不見別人——隔離 PID、網(wǎng)絡(luò)、文件系統(tǒng)視圖等Cgroups控制組限制進(jìn)程能用多少——CPU、內(nèi)存、I/O 配額。Docker 的核心概念概念說明Image鏡像只讀模板包含運行應(yīng)用所需的一切Container容器鏡像的運行實例相當(dāng)于跑起來的進(jìn)程Dockerfile構(gòu)建鏡像的腳本描述鏡像怎么一層層搭出來Registry倉庫鏡像的分發(fā)存儲中心如 Docker Hub、HarborVolume卷容器外的持久化存儲容器刪了數(shù)據(jù)還在Network網(wǎng)絡(luò)容器間互通的虛擬網(wǎng)絡(luò)一個最小例子# Dockerfile FROM golang:1.25 AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 go build -o server ./cmd FROM alpine:3.20 COPY --frombuilder /app/server /usr/local/bin/server EXPOSE 8080 CMD [server]構(gòu)建并運行dockerbuild-tmyapp:1.0.dockerrun-d-p8080:8080--namemyapp myapp:1.0三條命令一個應(yīng)用就在任何機(jī)器上一致地跑起來了。這就是 Docker 解決的核心問題在我機(jī)器上是好的這句話從此消失。Docker Compose單機(jī)多容器的粘合劑當(dāng)一個應(yīng)用由多個服務(wù)組成Web 數(shù)據(jù)庫 緩存時可以用docker-compose.yml在單臺機(jī)器上編排它們services:web:build:.ports:[8080:8080]depends_on:[db,redis]db:image:postgres:16volumes:[pgdata:/var/lib/postgresql/data]redis:image:redis:7volumes:pgdata:dockercompose up-d注意這里的邊界Compose 管理的是一臺機(jī)器上的多個容器。一旦跨越多臺機(jī)器就輪到 Kubernetes 出場了。二、Kubernetes 是什么Kubernetes簡稱 K8s因為 K 和 s 之間有 8 個字母是 Google 開源的容器編排平臺。它管理的是一個機(jī)器集群回答的是生產(chǎn)環(huán)境里真正棘手的問題應(yīng)用要跑在哪臺機(jī)器上調(diào)度容器掛了怎么辦自愈自動重啟、重新調(diào)度流量漲了怎么擴(kuò)容水平伸縮HPA 根據(jù) CPU/內(nèi)存/自定義指標(biāo)自動加減副本用戶訪問哪個容器服務(wù)發(fā)現(xiàn)與負(fù)載均衡Service / Ingress怎么安全地發(fā)新版本滾動更新 / 回滾Deployment 漸進(jìn)式替換舊 PodK8s 的核心抽象概念說明Pod最小調(diào)度單元包含一個或多個共享網(wǎng)絡(luò)的容器Deployment聲明我要 N 個某應(yīng)用的副本K8s 負(fù)責(zé)維持Service穩(wěn)定的訪問入口為一組 Pod 做負(fù)載均衡Namespace集群內(nèi)的邏輯隔離空間Node集群中的一臺工作機(jī)器上面那個docker run的應(yīng)用在 K8s 里長這樣apiVersion:apps/v1kind:Deploymentmetadata:name:myappspec:replicas:3# 始終保持 3 個副本selector:matchLabels:{app:myapp}template:metadata:labels:{app:myapp}spec:containers:-name:myappimage:myapp:1.0ports:[{containerPort:8080}]你聲明期望狀態(tài)3 個副本K8s 的控制器循環(huán)不斷地把實際狀態(tài)往期望狀態(tài)上糾正——掛一個就補一個機(jī)器宕機(jī)就把容器遷到別的機(jī)器。這是 K8s 與 Docker 在設(shè)計哲學(xué)上的根本差異。三、重點Docker 與 Kubernetes 的區(qū)別這是本文的核心。先上對比表再逐條展開。3.1 對比總表維度DockerKubernetes定位容器化平臺 / 容器運行時工具容器編排平臺解決的問題怎么打包、分發(fā)、運行一個應(yīng)用怎么在集群里管理成百上千個容器管理范圍單臺主機(jī)多節(jié)點集群最小單元Container容器Pod可含多個容器描述方式docker run命令 / Compose 文件聲明式 YAMLDeployment/Service 等擴(kuò)縮容docker compose scale單機(jī)、手動HPA 自動水平伸縮、跨節(jié)點調(diào)度故障處理容器掛了默認(rèn)就掛了--restart僅本機(jī)重啟自愈自動重啟、跨節(jié)點重新調(diào)度服務(wù)發(fā)現(xiàn)容器名 DNS僅限單機(jī)網(wǎng)絡(luò)Service DNS集群級穩(wěn)定入口發(fā)布策略手動 stop 舊容器、run 新容器滾動更新、金絲雀、一鍵回滾抽象層級面向單個容器的生命周期面向應(yīng)用期望狀態(tài)的持續(xù)調(diào)諧學(xué)習(xí)曲線平緩幾小時上手陡峭概念體系龐大3.2 逐條解讀① 定位不同工具 vs 平臺Docker 是一把趁手的扳手——打包鏡像、啟動容器、查看日志作用于單個容器的生命周期。Kubernetes 是整個車間的調(diào)度系統(tǒng)——它不關(guān)心某一個容器本身關(guān)心的是這批容器作為一個整體是否始終處于我聲明的狀態(tài)。② 命令式 vs 聲明式用 Docker 時你是命令式的“docker run給我跑一個”。容器死了除非加了 restart 策略否則沒人管。用 K8s 時你是聲明式的“我要 3 個副本、每個 512Mi 內(nèi)存、對外暴露 8080”。之后由 K8s 的控制器持續(xù)調(diào)諧reconcile loop任何偏離期望狀態(tài)的情況都會被自動糾正。這是運維模式上的質(zhì)變從我執(zhí)行操作變成我描述目標(biāo)。③ 自愈能力的差距Docker 的--restartalways只能在同一臺機(jī)器上重啟容器。如果這臺機(jī)器本身宕機(jī)了呢Docker 沒有答案。K8s 的健康檢查liveness/readiness probe 調(diào)度器會處理整條故障鏈容器崩潰→重啟進(jìn)程假死→探針失敗→殺掉重建節(jié)點失聯(lián)→把上面的 Pod 遷移到健康節(jié)點。故障被當(dāng)作常態(tài)來處理這是分布式系統(tǒng)的核心思想。④ 伸縮的維度不同Docker Compose 的scale受限于單機(jī)資源一臺機(jī)器的 CPU 和內(nèi)存就是天花板。K8s 的伸縮有兩個維度Pod 層面HPA 自動增減副本和節(jié)點層面Cluster Autoscaler 自動增減機(jī)器流量洪峰來時整個集群橫向鋪開。⑤ 最常見的誤區(qū)“K8s 取代了 Docker”沒有。這個誤解源于 2020 年 Kubernetes 宣布棄用 dockershim、并在 1.24 版本中移除了對 Docker Engine 的直接支持。真相是K8s 通過CRI容器運行時接口調(diào)用底層運行時現(xiàn)在默認(rèn)用containerd或CRI-O——它們比完整的 Docker Engine 更輕量但你用 Docker 構(gòu)建的鏡像完全不受影響。Docker 鏡像遵循 OCI開放容器鏡像標(biāo)準(zhǔn)containerd 照樣能跑Docker 內(nèi)部本來用的也是 containerd——K8s 只是跳過 Docker 這層中間商直接和它對話。所以正確的圖景是Docker構(gòu)建/分發(fā)鏡像 ──產(chǎn)出── OCI 標(biāo)準(zhǔn)鏡像 ──運行于── Kubernetes 集群 底層運行時 containerd/CRI-ODocker 和 K8s 是流水線的兩端而不是二選一的競品。3.3 怎么選場景推薦本地開發(fā)、CI 構(gòu)建鏡像Docker單機(jī)部署的小項目 / 個人服務(wù)Docker Compose多節(jié)點、需要高可用的生產(chǎn)服務(wù)Kubernetes需要自動伸縮、滾動發(fā)布、多團(tuán)隊協(xié)作Kubernetes剛起步、團(tuán)隊沒有專職運維Docker Compose 起步規(guī)模上來后再遷 K8s一個務(wù)實的路線用 Docker 構(gòu)建鏡像用 Compose 跑本地和小規(guī)模部署當(dāng)手動管容器開始消耗你太多精力時再上 Kubernetes。不要為了用 K8s 而用 K8s——它解決的是規(guī)?；瘑栴}引入的復(fù)雜度同樣可觀很多團(tuán)隊用 Compose 或單機(jī) Swarm 就足夠把業(yè)務(wù)跑得很好。四、總結(jié)Docker讓應(yīng)用一次構(gòu)建處處運行是容器化時代的基石它的戰(zhàn)場是單個容器的打包與運行。Kubernetes在容器之上提供調(diào)度、自愈、伸縮、服務(wù)發(fā)現(xiàn)和發(fā)布管理它的戰(zhàn)場是整個集群的期望狀態(tài)。兩者是互補關(guān)系Docker或任何 OCI 工具鏈生產(chǎn)鏡像Kubernetes 消費并管理這些鏡像。技術(shù)選型的關(guān)鍵不是哪個更先進(jìn)而是我的規(guī)模和問題復(fù)雜度到了哪一層。容器化已經(jīng)是現(xiàn)代軟件交付的默認(rèn)姿勢。理解了 Docker 與 K8s 各自解決的問題邊界你就不會被云原生焦慮裹挾能在正確的層次用正確的工具。