💻 3C 科技教學
2026 年 Docker 容器化部署實戰：從入門到 K8s 整合指南
m
code {
b
hr {
border-to);
res.end('Hello from Docker + 頂客論壇！');
});
server.listen(3000, () => console.log('Server running on port 3000'));
接著建立 package.json 以及 Dockerfile：
最佳實踐還包含：使用官方映像、指定精確版本標籤而非 latest、盡量合併 RUN 指令、善用 .dockerignore 排除不必要的檔案（例如 node_modules）、避免以 root 身分執行容器，並設定非特權使用者。這些細節都能降低映像檔大小與資安風險。
現在我們的應用需要搭配資料庫，才能算是完整服務。若手動用 docker run 啟動兩個容器並串接網路設定，既繁瑣又容易出錯。Docker Compose 正是為此而生，它透過 YAML 檔描述所有服務，一條指令就能啟動整個應用棧。
db:
我們使用 MongoDB 容器儲存資料，並宣告一個命名卷（named volume）讓資料得以持久保存。執行 docker compose up -d 即可在背景啟動，docker compose ps 查看狀態，docker compose logs -f 追蹤日誌，docker compose down 關閉整個架構。相較於手動連接，Compose 內建自訂網路，讓服務間可以透過服務名稱互連，例如程式碼中只要設定 DB_HOST=db 就能連到資料庫容器。
在 2026 年，Docker Compose 已整合進 Docker CLI 成為第一等公民（docker compose），許多新創甚至直接使用 Compose 作為輕量佈署方案，尤其單一節點的環境比 K8s 更輕便。
資料持久化是容器實戰中的經典痛點。容器被刪除時，內部資料也會跟著消失，因此必須使用 Volume 或 Bind Mount。Volume 由 Docker 管理，存放於宿主的特定目錄，是官方建議的方式。Bind Mount 則將宿主上的目錄掛載進容器，方便開發時修改即時生效。
以剛才的 Compose 為例，資料庫使用 Volume 保存資料，即使 docker compose down -v 只會移除匿名卷，但命名的 db_data 還是保留，下次重啟資料仍在。若要手動建立與掛載卷：
網路方面，Docker 預設提供三種網路：bridge（橋接，單主機內互聯）、host（直接使用宿主網路）、none（無網路）。最常用的是 bridge，透過 docker network create mynet 可建立自訂橋接網路，讓容器以名稱互相溝通，並支援 DNS 解析。另一種是 overlay 網路，用於多主機之間的容器通訊，常見於 Swarm 模式，但現在大家幾乎都改用 K8s 的 CNI 了。
當你已經能熟練地建立容器與管理多服務，下一步就是讓映像檔更精簡、應用更安全、運作更高效。這一章探討的進階技巧，是從「能用」到「好用」的分水嶺，特別在企業環境中，這些細節往往決定成本與服務品質。
映像檔越肥大，下載時間越長，儲存成本也越高，且暴露的攻擊面越大。除了前面提到的多階段建置，還有以下幾種瘦身技法：
alpine 或 distroless。Alpine 僅約 5MB，但預設使用 musl libc，相容性偶有問題；Distroless 連 shell 都沒有，安全性極高，適合靜態編譯的 Go/Rust 應用。RUN apt-get update && apt-get install -y ... && rm -rf /var/lib/apt/lists/*，避免分層中留下不必要的快取。.dockerignore：在輸送建置環境時，排除 git 資料夾、本機測試檔、編輯器設定等。安全掃描方面，Docker Hub 內建安全掃描，另外也推薦使用 Trivy、Clair、Anchore 等開源工具。我們可以在 CI 流程中加入掃描，例如：
trivy image --severity HIGH,CRITICAL --ignore-unfixed my-app:v1找出映像檔漏洞，並確保不將帶有高風險漏洞的映像檔部署到生產環境。此外，在 2026 年，業界已普遍使用「簽章」機制（如 Docker Content Trust / Cosign）來確保映像檔的完整性與來源可信度，避免供應鏈攻擊。
容器化環境的日誌管理與傳統 VM 不同，容器預設將日誌輸出到 stdout/stderr，Docker Daemon 會收集並處理。使用 docker logs 可以查看容器日誌，但在多容器或分散式環境下，我們需要集中式日誌平台，如 ELK/EFK（Elasticsearch, Fluentd/Fluent Bit, Kibana）或 Loki+Grafana。
在 Compose 環境中，我們可以設定 logging driver，例如使用 fluentd 或 awslogs：
若用 json-file，務必限制每個日誌檔案的大小與數量，避免主機磁碟被塞爆。更進階的做法是讓應用程式直接將結構化日誌（JSON 格式）輸出，方便後續查詢與自動化告警。
監控方面，cAdvisor、Prometheus、Grafana 是標準組合。cAdvisor 由 Google 維護，可以蒐集容器 CPU、記憶體、網路、磁碟 I/O 等指標；Prometheus 負責儲存與查詢；Grafana 提供視覺化儀表板。透過 docker run 啟動 cAdvisor 並掛載 Docker socket：
docker run -d --name=cadvisor -p 8080:8080 --privileged \
v /:/rootfs:ro -v /var/run:/var/run:ro -v /sys:/sys:ro -v /var/lib/docker/:/var/lib/docker:ro \
gcr.io/cadvisor/cadvisor
當然，2026 年多數團隊會直接使用雲原生的 OpenTelemetry 來追蹤與監控，讓應用層與基礎設施層的指標能統一管理。
3.3 資源限制與效能調校
我們常遇到某個容器吃掉所有 CPU 資源，影響其他服務。Docker 提供豐富的資源控制選項：
CPU：可用 --cpus 限制使用幾顆 CPU，或 --cpu-shares 設定相對權重。
記憶體：使用 --memory（硬限制）與 --memory-swap（包含 swap 的總限制）。超過限制會觸發 OOM。
磁碟 I/O：透過 --device-read-bps、--device-write-iops 等參數。
暫存檔案大小：使用 --tmpfs 或是設定 --shm-size 調整 /dev/shm 大小。
在 Compose 中，對應的語法為：
services:
web:
deploy:
resources:
limits:
cpus: "0.50"
memory: 256M
reservations:
cpus: "0.25"
memory: 128M
值得注意的是，Compose 的 deploy.resources 在 swarm 模式或 Docker Compose v2 的某些環境才有效。在一般 docker run 還是直接使用 --memory 等參數最直接。
效能調校還包含：使用 OverlayFS 的效能加速、避免頻繁的容器啟動與停止、使用容器間的自訂網路而非預設 bridge 來獲得更好的效能與隔離。另外，64KiB 的寫入快取與調整核心參數（如 net.core.somaxconn）也能改善網路延遲，但通常這些已經包含在調校好的作業系統基準中。
四、與 Kubernetes (K8s) 整合實戰
當你的服務規模成長到需要多台主機、自動調度、故障轉移時，Kubernetes 就成為不可或缺的作業系統。Docker 是「容器建置與單機管理」的利器，而 K8s 則是「叢集調度與自動修復」的王者。2026 年的今日，K8s 已成為雲原生交付的事實標準，學習如何把 Docker 映像帶入 K8s 世界，將是我們最後的實戰主題。
4.1 K8s 核心概念與架構簡介
Kubernetes 有一個主節點（Control Plane）與多個工作節點（Worker Nodes）。Control Plane 負責管理叢集狀態、排程工作、調度 API；工作節點則負責運行 Pod。Pod 是 K8s 的最小部署單位，它封裝一個或多個容器，以及共享的儲存與網路資源。Docker 映像檔可以被 K8s 直接使用，只要映像檔存放在可存取的倉儲，K8s 就會拉取並啟動容器。
關鍵元件簡介：
Etcd：儲存整個叢集的狀態與設定。
API Server：所有操作進出的門口，負責身份驗證與授權。
Scheduler：決定新建立的 Pod 該放到哪個節點。
Controller Manager：確保叢集實際狀態符合期望狀態，例如副本數。
Kubelet：每個節點上的代理，負責管理 Pod 與容器。
Kube Proxy：處理服務網路規則，實現 LoadBalancer 與 Service 功能。
我們所使用的 Docker 映像檔，其實是透過 CRI（Container Runtime Interface）由 containerd 直接執行，K8s 不直接依賴 Docker CLI，但可以相容任何符合 CRI 的 runtime。因此，你的 Docker 映像檔依然可以在 K8s 上完美運行。
4.2 將 Docker 映像部署到 K8s 叢集
首先，基於上一章建立的 my-app:v1 映像檔，我們先推送到一個倉儲。假設我們使用 Docker Hub：
docker tag my-app:v1 yourdockerhub/ya-bao-app:v1
docker push yourdockerhub/ya-bao-app:v1
接下來，我們編寫一個 K8s 部署 YAML（deployment.yaml）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: ya-bao-app
labels:
app: ya-bao
spec:
replicas: 3
selector:
matchLabels:
app: ya-bao
template:
metadata:
labels:
app: ya-bao
spec:
containers:
- name: app
image: yourdockerhub/ya-bao-app:v1
ports:
- containerPort: 3000
resources:
limits:
cpu: "0.5"
memory: "256Mi"
livenessProbe:
httpGet:
path: /
port: 3000
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /
port: 3000
initialDelaySeconds: 3
periodSeconds: 5
這個 Deployment 確保我們有 3 個 Pod 在運行。livenessProbe 偵測應用是否存活，若回應失敗就會重啟；readinessProbe 偵測是否已可接收流量，避免將請求導向尚未就緒的 Pod。
接著建立一個 Service，提供穩定的存取入口（ClusterIP），並從外部存取需搭配 Ingress：
apiVersion: v1
kind: Service
metadata:
name: ya-bao-service
spec:
selector:
app: ya-bao
ports:
- protocol: TCP
port: 80
targetPort: 3000
套用配置：
kubectl apply -f deployment.yaml -f service.yaml
kubectl get pods
kubectl get svc
要從外部存取，可以使用 NodePort、LoadBalancer 或 Ingress。以 Ingress 為例，部署一個簡單的 Ingress Controller（例如 NGINX Ingress），再建立 Ingress 規則將 demo.ya-bao.io 導向我們的 Service。
4.3 使用 Helm 管理應用與自動伸縮
當應用愈來愈複合，YAML 檔堆疊如山，Helm 便是 K8s 的套件管理工具，類似 apt 或 yum。Helm Chart 將所有 K8s 資源包裝成一個可版本化的範本，安裝與升級都變成一條指令。為了示範，我們建立一個簡易 Chart 目錄：
helm create ya-bao-chart
修改 values.yaml 設定應用名稱、映像檔位置、資源配額、副本數等。並在 templates/deployment.yaml 中使用 Values 參數。安裝 Chart：
helm install ya-bao ./ya-bao-chart --set image.repository=yourdockerhub/ya-bao-app --set image.tag=v1
Helm 的好處在於部署、升級、回復都能套用一次定義。加上意願式管理，團隊在不同環境（開發、測試、生產）中只需要覆寫對應的 values 檔即可。
自動伸縮是 K8s 的重要優勢之一。我們可以使用 HorizontalPodAutoscaler（HPA）根據 CPU 或記憶體使用率自動調整 Pod 數量。例如，保留平均 CPU 使用率在 60%，副本數在 2 到 10 之間：
kubectl autoscale deployment ya-bao-app --cpu-percent=60 --min=2 --max=10
這樣一來，當流量激增，Pod 自動增加；當流量降低，Pod 自動縮減。在 2026 年，還有 KEDA 可以根據事件驅動（如 RabbitMQ 佇列長度）進行更細緻的伸縮，確保資源利用最佳化。
⚠️ 重要提醒：K8s 中的 Pod 是短暫且可失敗的，因此不要將資料留在 Pod 內，請使用 PersistentVolumeClaim（PVC）或外部資料庫服務。
五、2026 年容器化趨勢與未來展望
熟悉了 Docker 與 K8s 的整合之後，我們不妨跳脫工具層次，展望未來生態系統的走向。在 2026 年，容器化技術已經非常成熟，但依然持續演進，特別在安全、效率與供應鏈方面，已成為雲原生時代最重要的課題。
5.1 Docker 與雲原生生態系的演進
Docker 不再只是開發者本機的工具，它與雲端整合更加緊密。我們可以看到以下幾個明顯趨勢：
無伺服器容器：除了傳統的 K8s 叢集，更多服務商開始提供完全託管的容器服務，例如 AWS Fargate、Azure Container Apps，讓開發者專注於程式碼而不用管底層節點。
WebAssembly (Wasm) 的興起：Wasm 具備快速啟動、輕量與安全等特性，漸成為容器與虛擬機之外的另一個輕量執行載體。許多未來平台能同時運行容器與 Wasm，實現更細微的工作負載隔離。
邊緣運算容器：將 Docker 映像檔部署到邊緣設備（如機器手臂、攝影機、路由器）已成常態。輕量化映像檔與節能調度演算法是關鍵，K3s（輕量 K8s）也加速了這個領域。
AI 整合：在 2026 年，ML 模型交付也採用容器化的方式，搭配 Kubernetes 的 GPU 排程能力，讓大型語言模型（LLM）的推理服務可以自動伸縮。Dockerfile 中常常執行模型下載與前處理，映像檔更大，因此優化技術更形重要。
可以說，Docker 不只是一個產品，更成為「容器映像檔」的代名詞，其 OCI（Open Container Initiative）相容確保了映像檔可以在不同容器 runtime 中運行，具有無可比擬的互通性。
5.2 安全與治理的新挑戰
既然容器與 K8s 已經成為核心基礎設施，安全就不再只是加裝防毒軟體那麼簡單。2026 年的治理與安全挑戰主要有：
供應鏈安全：從映像檔的基礎層、相依套件、來源倉儲，到最終部署，每個環節都可能被植入惡意內容。必須使用軟體物料清單（SBOM）、映像簽章與許可證掃描，確保來源透明。
零信任架構：以往只靠網路防火牆已不夠，必須在 Pod 與 Pod 之間建立微隔離（Micro-segmentation）。服務網格（如 Istio、Linkerd）提供了 mTLS、細粒度存取控制與可觀測性。
Policy as Code：透過 OPA/Gatekeeper 或 Kyverno 等工具，將安全策略寫成程式碼，強制應用在每一個部署上，例如禁止 privileged 容器、強制限制資源配額、禁止掛載宿主路徑等。
多雲管理：企業常同時使用雲端與地端的 K8s 叢集，需要統一的管理平台與擴充機制。2026 年的 Docker 與 雲原生工具已經能提供很好的多叢集策略管理。
這些挑戰並非無法克服，只要我們在設計初期就導入DevSecOps流程，將安全工具整合進CI/CD pipeline，就能讓容器化的優勢與安全並存。
結語：動手實踐，才能掌握容器化精髓
從 Docker 的基本概念、實戰建置、進階調校，到最後與 Kubernetes 的無縫整合，我們這趟旅程涵蓋了現代容器化部署的完整脈絡。我們看到 Docker 提供一致性的開發環境與精簡的交付機制，而 K8s 則賦予了自動調度、彈性伸縮與自我修復的能力。兩者相輔相成，已成為 2026 年最主流的部署組合。
然而，紙上談兵終究有限，唯有在自己的專案中實際操作，才能真正理解映像檔分層的奧妙、服務發現的機制、以及故障排除的技巧。建議你從今日開始，將手邊的某個小型服務容器化，並嘗試在測試環境中部署到 K8s 叢集。遇到問題時，透過 docker logs、kubectl describe pod、kubectl logs 等指令細心排查，每一次的錯誤都是成長的養分。
希望這篇〈2026 年 Docker 容器化部署實戰：從入門到 K8s 整合指南〉能為「頂客論壇」的讀者們帶來實質幫助。未來的雲原生世界將更加豐富，期待我們一同學習、交流與進步。若你對文章中的任何環節有疑問，歡迎在下方留言，我們一起討論！別忘了把這篇文章分享給需要的朋友，讓更多人加入容器化的行列。
本文由「雅寶社區 · 頂客論壇」編輯群撰寫，同步發佈於 3C 科技教學分類。
```
💬 留言討論
歡迎在下方留言，分享您的想法、心得或疑問。所有留言都會透過 GitHub 帳號 進行驗證。