Docker vs Kubernetes：何时使用哪个？

Docker 和 Kubernetes 是现代软件部署中最重要的两项技术，但它们解决的是根本不同的问题。Docker 将应用打包成可移植的容器，而 Kubernetes 在大规模场景下编排这些容器。本指南详细分析何时使用哪个、它们如何互补，以及如何在 2026 年为你的项目做出正确选择。

什么是 Docker？

Docker 是一个容器化平台，将应用程序及其依赖项打包成轻量、可移植的单元（称为容器）。每个容器包含应用运行所需的一切：代码、运行时、系统库和配置文件。容器共享宿主机的操作系统内核，因此比传统虚拟机更加高效。

Docker 解决了软件开发中的一个根本问题："在我机器上能跑"综合症。通过打包整个运行时环境，Docker 确保应用在开发、测试和生产环境中行为完全一致。这种一致性大幅减少了部署失败并简化了调试过程。

Docker 实战：构建镜像

# Node.js 应用的 Dockerfile
FROM node:20-alpine AS builder

WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

COPY . .
RUN npm run build

# 生产阶段
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

EXPOSE 3000
USER node
CMD ["node", "dist/server.js"]

Docker Compose 多容器应用

Docker Compose 允许你使用单个 YAML 文件定义和运行多容器应用。非常适合需要数据库、缓存和应用服务器协同运行的本地开发环境。

# docker-compose.yml
version: '3.9'
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/myapp
      - REDIS_URL=redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: myapp
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user"]
      interval: 5s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  pgdata:

什么是 Kubernetes？

Kubernetes（通常缩写为 K8s）是一个容器编排平台，最初由 Google 开发。它自动化容器化应用在机器集群中的部署、扩展和管理。Docker 在单台主机上运行容器，而 Kubernetes 跨多台主机协调容器。

Kubernetes 提供自我修复能力：如果容器崩溃，Kubernetes 会自动重启；如果节点故障，Kubernetes 会将容器重新调度到健康节点。它还内置了服务发现、负载均衡、滚动更新和密钥管理功能。

Kubernetes 架构

Kubernetes 集群由控制平面和工作节点组成。控制平面通过 API 服务器、调度器、控制器管理器和 etcd（分布式键值存储）管理集群状态。工作节点运行 kubelet 代理和容器运行时，以 Pod 为单位执行实际工作负载。

# deployment.yaml — Kubernetes 部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: myregistry/web-app:v2.1.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /healthz
              port: 3000
          readinessProbe:
            httpGet:
              path: /ready
              port: 3000
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: app-secrets
                  key: database-url
---
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  selector:
    app: web-app
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

Docker vs Kubernetes：功能对比

理解两者的根本差异有助于你在不同场景中做出正确选择：

何时只用 Docker

在很多常见场景中，单独使用 Docker 是正确的选择。并非每个应用都需要容器编排，过早引入 Kubernetes 会带来不必要的复杂性。

• 本地开发环境 — 需要在团队成员间保持一致、可重复的配置。
• 拥有 1-5 个容器的小型应用，可以在单台服务器上轻松运行。
• CI/CD 流水线 — Docker 为测试和构建提供隔离、干净的环境。
• 正在逐步容器化但尚不需要编排的单体应用。
• 个人项目、原型和 MVP — 运维开销需要最小化。

何时使用 Kubernetes

当你的应用需要跨多台机器可靠扩展、自动处理流量高峰或保持高可用性时，Kubernetes 就变得不可或缺。

• 拥有 10+ 服务的微服务架构，需要独立的扩展、部署和服务发现。
• 需要零停机部署、自动回滚和自我修复的生产工作负载。
• 多团队组织，不同团队需要独立部署到共享基础设施。
• 流量模式不固定的应用，可从水平 Pod 自动扩缩中受益。
• 合规性要求高的环境，需要细粒度的访问控制、网络策略和审计日志。

全量 Kubernetes 的替代方案

运行完整的 Kubernetes 集群在运维上代价高昂。2026 年，一些更轻量的替代方案已经成熟：

Kubernetes 自动扩缩

水平 Pod 自动扩缩器（HPA）根据 CPU 使用率、内存消耗或自定义指标自动调整 Pod 副本数量。这确保你的应用能够按需扩展而不会过度配置。

# hpa.yaml — 水平 Pod 自动扩缩器
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

决策框架：Docker 还是 Kubernetes？

根据你的项目需求，使用以下框架来指导决策：

两者的最佳实践

• 使用多阶段 Docker 构建来保持生产镜像精简。一个典型的 Node.js 镜像通过适当的多阶段配置可以从 1GB 缩减到 150MB。
• 永远不要以 root 身份运行容器。在 Dockerfile 中始终指定非 root USER，并在 Kubernetes 中设置安全上下文。
• 固定特定的镜像标签，不要使用 "latest"。不可变标签（使用镜像摘要）提供最强的可复现性保证。
• 在 Kubernetes 中设置资源请求和限制。没有它们，一个行为异常的 Pod 可能会耗尽整个节点的资源。
• 实现健康检查（Kubernetes 中的存活和就绪探针，Docker 中的 HEALTHCHECK）。它们实现自我修复并防止流量到达不健康的实例。
• 将密钥存储在专用的密钥管理系统中（启用静态加密的 Kubernetes Secrets、HashiCorp Vault 或云原生方案）。永远不要将密钥嵌入容器镜像。
• 使用 Kubernetes 命名空间来隔离环境（开发、测试、生产）和团队。为每个命名空间应用资源配额和网络策略。
• 在 CI 流水线中使用 Trivy、Snyk 或 Grype 等工具扫描容器镜像漏洞。阻止包含严重 CVE 的镜像进入生产环境。

FAQ