搜索 Docker vs Kubernetes 表明您必须选择一个，但该框架会导致很多混乱。这有点像将一个集装箱与容纳数千个集装箱的港口进行比较。它们在不同的级别上运行，并且经常同时使用。

本指南解释了每个应用程序的用途，在两个应用程序中显示了相同的小应用程序，并以一种实用的方法结束。此处的命令和文件是我们在本文中未执行的标准示例，因此请根据您安装的版本检查它们。

简短的回答

Docker 是一个平台，用于将应用程序及其依赖项打包到映像中，然后将该映像作为容器运行。它回答了“如何让这个应用程序在任何地方都以相同的方式运行？”的问题。

Kubernetes，通常写作 K8s，是一个容器编排器。它决定容器在多台机器上运行的位置，在发生故障时重新启动它们，并根据需求进行扩展。它回答了“如何保持数百个容器可靠运行？”的问题。

Docker 与 Kubernetes 对比

Docker 是做什么的

在容器出现之前，“它可以在我的机器上运行”是一个日常问题，因为每个服务器都有不同的版本。 Docker 将您的代码、运行时和库捆绑到一个 映像 中。该映像的运行副本是一个容器，它共享主机的内核，因此与完整的虚拟机相比，它启动速度更快，使用的内存更少。

工作流程分为三个步骤：

1. Build：a Dockerfile 描述如何创建映像。
2. Ship： 将映像推送到注册表，例如 Docker Hub。
3. 运行： 在任何兼容计算机上从该映像启动容器。

要进行实践，请从我们的 Docker 初学者教程 开始，然后阅读我们的 Dockerfile 最佳实践 。

库伯内特斯是做什么的

一台服务器上的 Docker 运行良好，直到该服务器发生故障、流量超出其容量或者您有数十个服务需要协调。 Kubernetes 负责这些操作工作：

• 调度：将容器放置在有足够可用容量的机器上。
• 自我修复：替换故障容器并将工作从故障节点移开。
• 扩展：手动或基于指标添加或删除副本。
• 服务发现：为一组不断变化的容器提供一个稳定的名称。
• 滚动更新：逐步发布新版本，并进行简单的回滚。
• 配置：与图像分开管理设置和机密。

核心思想是期望状态。您声明应该存在三个副本，控制者会不断将其与现实进行比较并纠正任何差异。我们的 Kubernetes 初学者教程 在本地集群上演练了这一过程。

Docker 和 Kubernetes 如何协同工作

从开发人员的笔记本电脑到生产环境的典型路径如下所示：

1. 开发人员编写 Dockerfile 并在本地测试容器。
2. CI/CD 管道 构建映像并运行测试。
3. 管道将版本化映像推送到注册表。
4. Kubernetes 清单已更新以使用该映像版本。
5. Kubernetes 提取镜像并将其部署到集群中。

所以Docker的工作在Kubernetes启动之前就基本完成了。该图像是它们之间的交接点。

一个应用程序，两种方式

这是一个小型网络服务。无论哪个工具运行该映像，其构建方式都相同：

# Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

使用 Docker 运行它

docker build -t shop-api:1.0 .
docker run -d --name shop -p 8080:8000 --restart unless-stopped shop-api:1.0

两个命令，它正在运行。这很简单，适合许多小型项目。但一台机器上只有一份副本，如果机器死机，服务也会随之消失。

使用 Kubernetes 运行它

# shop.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: api
          image: registry.example.com/shop-api:1.0
          ports:
            - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8000

kubectl apply -f shop.yaml
kubectl get pods -l app=shop

还有很多东西要写，并且您需要一个集群来运行它。作为回报，您将获得三份副本、稳定的内部地址和自动替换。这种权衡是整个决策的缩影：更多的复杂性换取更多的弹性。

当容器发生故障时会发生什么？

dockershim 的混乱

您可能已经读过“Kubernetes 抛弃了 Docker”。这在狭义上是正确的，并且不必要地吓坏了很多人。 Kubernetes 通过称为容器运行时接口的标准来运行容器。 Docker Engine 没有直接实现它，因此 Kubernetes 包含了一个名为 dockershim 的适配器。该适配器在 1.24 版本中被删除。

集群现在通常使用 containerd 或 CRI-O 等运行时。 使用 Docker 构建的映像仍然有效，因为它们遵循开放容器计划 (OCI) 映像标准。因此，您可以继续使用 Docker 进行构建，并且您的集群会使用不同的运行时来运行结果。

Docker Compose、Swarm 和 Kubernetes

更有意义的比较是协调容器的工具之间的比较：

Docker Compose 从一个文件启动多个相关容器，它非常适合 Web 应用程序和笔记本电脑上的数据库。 Swarm 内置于 Docker 中，比 Kubernetes 更容易学习，但它的生态系统要小得多。 Kubernetes 拥有最大的社区和工具，这也是它成为大型部署默认设置的重要原因。

你需要哪一个？

在以下情况下，单独使用 Docker 通常就足够了：

• 您正在本地开发或在一台服务器上运行小型应用程序。
• 您的团队很小，没有专门的运营人员。
• 偶尔短暂的停机是可以接受的。

当满足以下条件时，Kubernetes 就开始有意义：

• 您运行不同团队自行部署的许多服务。
• 您需要跨多个计算机或区域的高可用性。
• 流量变化很大，自动扩展可以节省真正的资金。
• 您拥有操作它的技能或预算。

还有一个中间立场。托管容器平台（例如 AWS Fargate、Google Cloud Run 或 PaaS）可以运行 Docker 映像，无需维护集群。对于许多成长型公司来说，这是正确的下一步，而不是直接跳到 Kubernetes。

如果您出于职业原因想学习两者，那么顺序很明确：首先是 Docker，然后是 Kubernetes。如果不先了解镜像、端口和容器日志，就无法轻松调试 Pod。

常见错误

• 过早采用 Kubernetes。 复制大公司的架构可能会让小团队埋头于运营工作。
• 在生产中使用latest标签。您无法可靠地判断什么正在运行或回滚。使用特定版本标签。
• 在容器内存储数据。 容器是一次性的，因此请使用卷或托管数据库。
• 跳过运行状况检查。 如果没有就绪性和活跃性探测，Kubernetes 就无法对您的应用程序做出正确的决策。
• 忘记资源限制。 一个贪婪的容器可能会使节点上的其他所有容器都挨饿。

最后的话

Docker 打包您的软件，然后 Kubernetes 大规模运行它。与其问哪个更好，不如问你今天遇到了什么问题。如果是“我的应用程序很难安装”，请使用 Docker。如果是“我的 40 个服务需要在服务器故障中幸存下来”，请看看 Kubernetes。从解决实际问题的最简单的工具开始，当您看到需要时再升级。

常见问题

继续学习