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