雅寶社區 · 頂客論壇 (AHPAL.COM)

💻 3C 科技教學

2026 年 Docker 容器化部署實戰：從入門到 K8s 整合指南

發表時間：2026 年 08 月 14 日 | 更新日期：2026 年 08 月 14 日 | 編輯：雅寶社區編輯團隊

在 2026 年的最佳實踐中，請務必注意以下幾點：

3.2 多階段建構與映像檔瘦身

為了產生最小的映像檔，多階段建構（Multi-stage Build）是您不可不知的技巧。以一部 Golang 應用為例，您可以在第一個階段使用 golang:1.24 執行編譯，第二個階段則使用空白基礎映像檔（如 scratch）直接複製編譯後的二進位檔：

# 建構階段

FROM golang:1.24 AS builder

WORKDIR /src

COPY . .

RUN CGO_ENABLED=0 go build -o /app/myapp main.go

執行階段

FROM scratch

COPY --from=builder /app/myapp /myapp

EXPOSE 8080

ENTRYPOINT ["/myapp"]

因為 scratch 映像檔不含任何套件，可大幅降低攻擊面。在 2026 年，您還可以使用 buildkit 的 Squash 功能，或者透過 docker build --squash 將多層壓縮為單層。要注意的是，如果應用需要 CA 憑證或時區資訊，請務必從 builder 階段將這些檔案複製過來。透過這些方法，很多映像檔可以從 500MB 縮小到 10MB 以下，大幅加快部署速度。

3.3 使用 Docker Compose 管理多容器應用

真實世界的應用很少是「單一容器」就能搞定。例如一個網頁服務，可能需要 nginx 作為反向代理，Node.js 作為應用伺服器，PostgreSQL 作為資料庫，Redis 作為快取。Docker Compose 允許您透過一個 YAML 檔案描述整個服務架構，並用 docker compose up 一鍵啟動。

以下是 2026 年一個標準的三階層應用 docker-compose.yml 範例：

services:

web:

image: nginx:1.27-alpine

volumes:

• ./nginx.conf:/etc/nginx/nginx.conf:ro

ports:

• "80:80"

depends_on:

• app

networks:

• frontend

app:

build: .

environment:

• DB_HOST=db
• REDIS_HOST=redis

expose:

• "3000"

networks:

• frontend
• backend

db:

image: postgres:16-alpine

environment:

POSTGRES_USER: user

POSTGRES_PASSWORD: secret

volumes:

• db-data:/var/lib/postgresql/data

networks:

• backend

redis:

image: redis:7-alpine

volumes:

• redis-data:/data

networks:

• backend

volumes:

db-data:

redis-data:

networks:

frontend:

backend:

此 YAML 檔定義了四個服務，並將網路切分為前後端，增強安全性。透過 depends_on，Compose 會確保 db 與 redis 先啟動，再啟動 app。搭配 2026 年 Docker Compose 的新功能——完整的容器健康檢查依賴，可以等待「服務健康」而非僅「啟動」，讓服務啟動順序更加可靠。此外，Compose 亦支援 docker compose up --scale app=3 快速橫向擴展，讓您在本機也能模擬生產環境的負載平衡。

四、容器化部署的進階技巧

當您能夠熟練地建構映像檔與管理多容器服務之後，接下來的挑戰便是如何讓容器化系統在長時間運作下保持穩定、安全且可觀測。這些進階技巧將引導您深入 Docker 的底層機制，建立一個「可維護」的容器環境。

4.1 資料持久化與磁碟管理

容器天生是「無狀態（stateless）」的，但在實際應用中，資料庫檔案、使用者上傳檔案、應用程式日誌都需要被持久化儲存。Docker 提供了兩種主要方式：Bind Mount 與 Volume。

Bind Mount 是直接將主機的本機目錄掛載到容器內，例如 docker run -v /host/data:/container/data。它的好處是直觀、容易使用，特別適合本機開發環境。但因為它依賴於特定主機的目錄結構，較難以跨平台遷移。Volume 則是由 Docker 引擎管理，儲存在 /var/lib/docker/volumes/ 下的資料目錄。透過 docker volume create 與 docker volume inspect，您可以輕鬆備份、轉移並使用 volume 外掛（如 Rook-Ceph）儲存到雲端儲存空間。在 2026 年，提供高效能雲端檔案儲存的 CSI 驅動程式，已經可以將 Docker Volume 直接對應到 S3 或 Azure Files，讓容器資料轉化為無限擴充的雲端磁碟。

為了避免磁碟空間被大量無用的容器與映像檔佔滿，您必須定期執行 docker system prune -a --volumes 清除所有未使用的資源，並設定 log rotation 以限制日誌檔案大小。透過 docker run --log-opt max-size=10m --log-opt max-file=3 即可避免容器日誌無限肥大。

4.2 容器監控與日誌收集

現代維運強調「可觀測性（Observability）」。您不能只依賴 docker stats 指令觀看即時資源用量，更需要在發生問題時快速回溯。2026 年的主流做法是使用 Prometheus 收集容器指標（如 CPU、記憶體、磁碟 I/O），並透過 Grafana 建立視覺化儀表板。cAdvisor 是常用的指標來源，它可以容器的形式掛載在 Docker 網路中，自動將節點上的容器資料暴露給 Prometheus。

日誌方面，洛基（Loki) 是 Grafana 家族中的輕量級日誌聚合系統，它透過標籤（label）索引日誌，並與 Prometheus 共用相似的查詢語法。使用 Docker 的 docker plugin install grafana/loki-docker-driver 即可將所有容器的 stdout/stderr 自動導向 Loki。當您在 K8s 中運行時，更可以搭配 fluentd 或 filebeat，依據 namespace、Pod 名稱與容器名稱自動歸類日誌。妥善的日誌收集策略是系統故障診斷的第一道防線，請務必預先規劃。

4.3 安全性與鏡像掃描

容器安全絕對是 2026 年的重中之重，因為供應鏈攻擊只要成功，駭客便能同時掌握成千上萬個服務。因此，映像檔掃描從「建議」升級為「強制」。Docker 內建 docker scan 指令，會比對 Trivy、Anchore Engine 等漏洞資料庫，列出映像檔中已知的 CVE，並提供建議修補版本。您也可以使用 docker bench 安全檢測工具，針對 Docker 部署環境進行基準評估，檢查是否遵循 CIS Benchmark 標準。

此外，請務必限制容器內進程的權限。例如，在 Dockerfile 中使用 USER node、加入 --cap-drop ALL 與 --cap-add NET_BIND_SERVICE，以最低權限原則運作。2026 年 Docker 亦支援「無 root 的容器引擎 (rootless mode)」與「User Namespace 隔離」，建議所有執行 node 的 Host 皆採用此配置。最後，請定期更新基底映像檔，並使用 Digest（SHA256）取代 tag 來鎖定映像檔版本，杜絕 “latest” 標籤帶來的不可預期行為。

五、從 Docker 邁向 Kubernetes (K8s)

當您的應用程式數量增加、用戶規模成長，單靠 Docker Compose 管理數十個容器會變得相當痛苦，遑論要進行自動擴展或節點故障轉移。此時，您需要一個強大的「容器編排（Orchestration）」系統來統一管理集群，而 Kubernetes 正是業界標準。

5.1 為什麼需要 K8s？容器編排的價值

Kubernetes 將多台主機化作一個巨型資源池，您可以定義所需狀態（例如「我需要三份 nginx 副本」），K8s 就會自動調度、部署並維護該狀態。當發生主機故障、容器崩潰、網路異常時，K8s 會自動重啟或遷移容器，實現自我修復（Self-healing）。此外，K8s 具備下列核心價值：

儲存卷編排：可動態掛載雲端硬碟、NFS 等儲存空間至 Pod。

如果您的系統需要高可用性與精細的流量管理，K8s 絕對是不可取代的解決方案。

5.2 K8s 核心概念：Pod、Service、Deployment

在 K8s 中，最小的調度單位不是容器，而是 Pod。Pod 通常包含一個或多個容器，這些容器共享同一個網路命名空間與儲存卷，可視為一個「邏輯主機」。在實務中，我們通常僅在 Pod 中放入一個主容器，再搭配一個輔助容器（sidecar）用於日誌轉發或代理等任務。

Deployment 是最常用的控制器，它負責管理無狀態應用程式的 Pod 生命週期，支援更新、回滾與擴展。透過 YAML 定義 replicas 數量，K8s 會確保符合預期狀態。Service 則提供了一種穩定的存取方式，即使 Pod 不斷重啟，Service 的虛擬 IP（ClusterIP）也不會改變。讀者最常使用的 Service 型別包括 ClusterIP（叢集內存取）、NodePort（對外存取）與 LoadBalancer（負載平衡器後端）。此外，Ingress 控制器可以基於 HTTP 路徑或域名進行路由，讓對外存取更為優雅。

5.3 將 Docker 應用無縫遷移到 K8s

好消息是，您並不需要重寫應用程式即可從 Docker Compose 遷移至 K8s。2026 年的 kompose 工具已發展得非常成熟，可以自動將 docker-compose.yml 轉換為 K8s 的 Deployment、Service 與 Volume 定義。以下是一個轉換指令範例：

# 安裝 kompose

curl -L https://github.com/kubernetes-incubator/kompose/releases/download/v1.34.0/kompose-linux-amd64 -o /usr/local/bin/kompose

chmod +x /usr/local/bin/kompose

轉換

kompose convert

轉換後會產生若干個 YAML 檔，您可以依據需求進行微調。例如，將 Service 的 type 改為 LoadBalancer，或加入 HorizontalPodAutoscaler（HPA）的定義。由於 Docker 的網路與儲存設定大致與 K8s 的 label selector 對應，只要將既有映像檔推送到可被 K8s 存取的容器倉庫，即可快速完成遷移。但要特別注意，環境變數的傳遞方式需從 compose 的 environment 改成 ConfigMap，機密資料則需存入 Secret。

六、2026 年 K8s 與 Docker 整合實戰

在本章節，我們將實際創建一個本地 Kubernetes 叢集，並將先前建立的 Docker 應用部署上去。我們將採用 kind（Kubernetes in Docker）作為標準工具，因為它可直接使用 Docker 容器來模擬叢集節點，無需額外虛擬機，非常適合開發與測試。

6.1 使用 kind 建立本地 K8s 叢集

kind 可在您的個人電腦上建立一個多節點 Kubernetes 叢集，所有控制平面與工作節點皆為 Docker 容器。首先，請確保 Docker 已正確執行，然後安裝 kind：

# 使用 Go 安裝

go install sigs.k8s.io/kind@latest

或在 Linux / macOS 上直接下載

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-amd64

chmod +x ./kind

sudo mv ./kind /usr/local/bin/kind

建立一個包含 1 個 control-plane 與 2 個 worker 節點的多節點叢集，請建立 kind-config.yaml：

kind: Cluster

apiVersion: kind.x-k8s.io/v1alpha4

nodes:

• role: control-plane
• role: worker
• role: worker

接著執行：

kind create cluster --config kind-config.yaml --name demo-cluster

完成後，執行 kubectl cluster-info 確認連線狀態。您將發現 Docker CLI 中也會多了名為 demo-cluster-control-plane 的容器，這正是 kind 的核心理念：用 Docker 容器模擬 Node。

6.2 透過 kubectl 部署應用

現在，我們要部署上一節所建置的 Node.js 應用。由於 K8s 需要從倉庫取得映像檔，我們可以選擇將映像檔載入 kind 節點，或是使用 Docker Hub 的公開映像。在測試環境中，最簡單的方法是將映像檔載入 kind：

docker build -t myapp:v1 .

kind load docker-image myapp:v1 --name demo-cluster

接下來，建立 deployment.yaml：

apiVersion: apps/v1

kind: Deployment

metadata:

name: myapp-deployment

spec:

replicas: 3

selector:

matchLabels:

app: myapp

template:

metadata:

labels:

app: myapp

spec:

containers:

• name: myapp-container

image: myapp:v1

ports:

• containerPort: 3000

env:

• name: NODE_ENV

value: "production"

resources:

requests:

memory: "64Mi"

cpu: "100m"

limits:

memory: "128Mi"

cpu: "200m"

執行 kubectl apply -f deployment.yaml，K8s 將建立三個 Pod。您可以使用 kubectl get pods 查看狀態。隨後，透過 Service 將應用暴露至叢集外部：

kubectl expose deployment myapp-deployment --type=NodePort --name=myapp-service --port=80 --target-port=3000

執行 kubectl get service 找到 NodePort 的埠號，即可透過 http://localhost:<nodeport> 存取您的應用程式。

6.3 設定自動擴展與滾動更新

2026 年的 Kubernetes 已將 Kubernetes Event-driven Autoscaling（KEDA） 整合為標準功能，企業可以根據每秒請求數、佇列深度等即時指標自動調整 Pod 數量。在本機叢集中，我們先以 CPU 為基礎的 HPA（HorizontalPodAutoscaler）進行演練：

kubectl autoscale deployment myapp-deployment --cpu-percent=50 --min=1 --max=8

執行後，K8s 會持續監控 Pod 的 CPU 平均使用率。當使用率超過 50%，即自動增加 Pod 數量；若是低於目標，則會縮減至最小值。您可以使用 kubectl get hpa 觀察狀態。若要模擬負載，可使用 kubectl run -it --rm load-generator --image=busybox /bin/sh，並重複執行 wget -q -O- myapp-service，感受自動擴展的樂趣。

關於滾動更新，首先更新應用程式原始碼後重新建置映像並 tag 為 myapp:v2，使用 kind load docker-image myapp:v2 載入，然後執行：

kubectl set image deployment/myapp-deployment myapp-container=myapp:v2

K8s 會立即建立新的 Pod，並逐步替換舊 Pod，期間服務不會中斷。若發現問題，可執行 kubectl rollout undo deployment/myapp-deployment 立即回到上一個版本。透過這套機制，您可以放心進行頻繁的版本更新，實現真正意義上的 DevOps 持續交付。

七、總結與未來展望

恭喜您！經過這趟充實的旅程，您已掌握了 2026 年 Docker 容器化部署的完整核心知識：從了解容器原理、建置映像檔、透過 Docker Compose 管理多服務，到使用 Kubernetes 進行叢集編排、部署、自動擴展與滾動更新。這套「從 Docker 到 K8s」的技術棧，仍然是數位轉型與雲原生活動的基石。

展望未來，容器化技術將與 AI 深度整合。基礎設施層面的 K8s 已經開始將 GPU 視為一種可排程的資源，使大型語言模型的微調與推論任務能以更具彈性的方式運行。Docker 也推出了 AI 工具鏈，允許開發者將模型與其依賴項封裝成一鍵部署的容器映像，大幅降低 ML 與 DevOps 之間的壁壘。另外，WebAssembly（WASM）即將成為容器之外的另一種輕量級部署單元，而 Kubernetes 社群也已著手探討如何將 WASM 模塊與 Pod 共生，形成混合作業系統執行環境。

無論技術如何演進，您現在建立的「容器化思維」——建構不變的映像檔、使應用無狀態、將基礎設施視為程式碼——將永遠受用。建議您立即開始動手實作，將這篇文章中的範例應用到自己的專案中。只要持續練習，您也將能成為 2026 年最搶手的容器化部署專家。加油！

🏠 返回首頁