Docker 和 Kubernetes 对比｜零基础可学

在学习云计算、微服务、DevOps 或后端部署时，很多初学者都会遇到两个高频词：Docker 和 Kubernetes。它们经常一起出现，也经常被放在一起比较。有人说“Docker 是容器”，有人说“Kubernetes 是容器编排”，还有人说“学 Kubernetes 之前必须先学 Docker”。这些说法并不算错，但如果没有系统理解，很容易把二者混为一谈。

本文面向零基础读者，用通俗的方式讲清楚：Docker 是什么，Kubernetes 是什么，它们有什么区别，分别解决什么问题，实际工作中如何搭配使用，以及初学者应该如何学习。

一、先用一个生活例子理解 Docker 和 Kubernetes

假设你开了一家奶茶店。

一开始，你只有一家门店，每天只卖几十杯奶茶。你只需要准备好原料、机器和配方，按照固定流程制作即可。

这时，Docker 就像一个标准化的“奶茶制作盒子”：

• 盒子里有茶叶、奶、糖浆、杯子；
• 还有制作说明；
• 不管你把盒子拿到哪家店，只要打开，就能做出一样的奶茶。

这对应软件世界中的情况就是：

• 程序运行需要依赖环境；
• Docker 把程序和依赖打包在一起；
• 不管放到开发电脑、测试服务器还是生产服务器，都能尽量保持一致运行。

后来，你的奶茶店火了，全国开了 100 家分店。你开始遇到新问题：

• 哪些门店客流量大，需要多准备原料？
• 哪些门店机器坏了，需要自动切换？
• 哪些门店需要扩张？
• 如何统一管理所有门店？
• 如何保证某家店出问题时不影响整体营业？

这时，Kubernetes 就像一个“全国门店管理系统”：

• 自动安排每家店的资源；
• 哪家店忙就多分配人手；
• 哪家店故障就自动恢复；
• 统一调度、扩容、监控和发布。

所以，简单理解：

Docker 负责把应用打包成标准化容器；Kubernetes 负责大规模管理这些容器。

二、Docker 是什么？

1. Docker 的基本概念

Docker 是一种容器化技术平台，它可以将应用程序及其依赖环境打包成一个独立的、可移植的运行单元，这个运行单元叫做 容器。

传统情况下，一个应用能否正常运行，取决于服务器上安装了什么软件、什么版本的语言环境、哪些系统库等。比如：

• Java 应用需要 JDK；
• Python 项目需要指定版本的 Python 和依赖包；
• Node.js 项目需要 npm 包；
• 数据库连接需要配置；
• 系统还可能需要特定的环境变量。

如果开发环境和生产环境不一致，就可能出现经典问题：

“在我电脑上明明可以运行，为什么到服务器就报错？”

Docker 的核心价值就是解决这个问题。

它把应用代码、运行环境、依赖库、配置等打包成镜像，然后通过镜像启动容器。这样就可以做到：

• 开发环境一致；
• 测试环境一致；
• 生产环境一致；
• 部署流程更稳定；
• 应用迁移更方便。

2. Docker 中几个重要概念

镜像 Image

镜像可以理解为一个“应用安装包”或“模板”。它里面包含了应用运行所需的文件、依赖和配置。

比如你可以制作一个镜像，里面包括：

• Ubuntu 系统基础环境；
• JDK 17；
• Spring Boot 应用 jar 包；
• 启动命令。

之后无论在哪台机器上，只要安装了 Docker，就可以使用这个镜像启动同样的应用。

容器 Container

容器是镜像运行起来之后的实例。

如果镜像是“类”，容器就像“对象”；如果镜像是“安装包”，容器就是“正在运行的软件”。

同一个镜像可以启动多个容器。例如，一个 Nginx 镜像可以启动 3 个 Nginx 容器，它们彼此相互隔离。

Dockerfile

Dockerfile 是制作镜像的说明书。

例如，一个简单的 Dockerfile 可能长这样：

FROM openjdk:17
COPY app.jar /app.jar
CMD ["java", "-jar", "/app.jar"]

它的意思是：

1. 使用 JDK 17 作为基础环境；
2. 把本地的 app.jar 复制进镜像；
3. 容器启动时执行 java -jar /app.jar。

仓库 Registry

镜像做好之后可以上传到镜像仓库，例如：

• Docker Hub；
• Harbor；
• 阿里云镜像仓库；
• 腾讯云镜像仓库；
• GitLab Container Registry。

其他服务器可以从仓库拉取镜像并运行。

3. Docker 主要解决什么问题？

Docker 主要解决的是 应用打包、交付和运行环境一致性 的问题。

它的优势包括：

环境一致

开发、测试、生产环境都使用同一个镜像，减少环境差异带来的问题。

部署简单

传统部署可能需要安装语言环境、复制文件、配置依赖。Docker 部署只需要：

docker run 镜像名

当然，实际生产中还会有更多参数，但核心思路非常简单。

启动速度快

容器比虚拟机轻量，不需要完整启动一个操作系统，因此启动速度通常很快。

资源占用低

容器共享宿主机内核，相比虚拟机更加轻量，可以在同一台机器上运行更多应用实例。

易于迁移

只要目标机器支持 Docker，就可以运行同一个镜像。

三、Kubernetes 是什么？

1. Kubernetes 的基本概念

Kubernetes，简称 K8s，是一个容器编排平台。它的主要作用是管理大量容器应用，包括部署、调度、扩容、负载均衡、故障恢复、滚动更新等。

如果只是在一台服务器上运行几个容器，用 Docker 就足够了。但在真实生产环境中，情况往往更加复杂：

• 一个系统可能有几十个微服务；
• 每个服务可能需要多个副本；
• 服务要部署在多台服务器上；
• 某台服务器可能宕机；
• 某个容器可能异常退出；
• 某个服务访问量突然上升，需要自动扩容；
• 新版本发布时不能影响用户访问；
• 配置、密钥、网络、存储都需要统一管理。

这些问题单靠 Docker 命令手动管理会非常麻烦。Kubernetes 就是为了解决这类复杂场景而出现的。

2. Kubernetes 中几个重要概念

Cluster 集群

Kubernetes 管理的是一个集群。集群由多台服务器组成，这些服务器被称为节点。

通常包括：

• 控制平面节点，也叫 Master 节点；
• 工作节点，也叫 Worker 节点。

控制平面负责管理和调度，工作节点负责真正运行应用容器。

Pod

Pod 是 Kubernetes 中最小的调度单位。

很多初学者会问：为什么 Kubernetes 不直接管理容器，而要管理 Pod？

可以这样理解：Pod 是一个或多个容器的组合，这些容器共享网络和存储。大多数情况下，一个 Pod 中只有一个业务容器。但有时也会有辅助容器，比如日志采集、代理等。

Deployment

Deployment 用来管理应用的部署和更新。

它可以声明：

• 应用需要运行几个副本；
• 使用哪个镜像；
• 如何更新；
• 如何回滚；
• 如何保持期望状态。

例如你希望某个服务一直保持 3 个副本运行，Kubernetes 会持续检查。如果某个 Pod 挂了，它会自动创建新的 Pod。

Service

Pod 的 IP 可能会变化。为了让其他服务稳定访问它，Kubernetes 提供了 Service。

Service 可以为一组 Pod 提供一个稳定的访问入口，并实现负载均衡。

ConfigMap 和 Secret

应用通常需要配置文件、环境变量、数据库密码、Token 等信息。

Kubernetes 提供：

• ConfigMap：保存普通配置；
• Secret：保存敏感信息。

这样可以把配置和镜像分离，方便不同环境使用不同配置。

Ingress

Ingress 通常用于管理外部访问集群内部服务的规则。

比如：

• api.example.com 访问后端 API 服务；
• www.example.com 访问前端服务；
• /admin 路径转发到后台管理服务。

3. Kubernetes 主要解决什么问题？

Kubernetes 主要解决的是 容器的大规模管理和自动化运维 问题。

它的核心能力包括：

自动调度

Kubernetes 可以根据资源情况，把 Pod 自动调度到合适的节点上运行。

自动恢复

如果容器崩溃，Kubernetes 可以自动重启；如果节点宕机，它可以把应用重新调度到其他节点。

自动扩缩容

当访问量变大时，可以增加副本；访问量降低时，可以减少副本，从而节省资源。

滚动更新

发布新版本时，Kubernetes 可以逐步替换旧版本，避免一次性全部下线导致服务不可用。

服务发现和负载均衡

服务之间不需要记住具体 Pod IP，可以通过 Service 名称进行访问。

配置和密钥管理

通过 ConfigMap 和 Secret 管理配置，使应用更加灵活。

声明式管理

Kubernetes 常用 YAML 文件描述“我希望系统最终是什么状态”，然后由 Kubernetes 自动去实现这个状态。

例如你声明希望某个服务有 3 个副本，Kubernetes 就会尽力保持始终有 3 个副本运行。

四、Docker 和 Kubernetes 的核心区别

很多人会问：Docker 和 Kubernetes 到底是不是同一种东西？答案是：不是。

它们虽然都和容器有关，但关注点完全不同。

一句话总结：

Docker 解决“如何把应用装进容器并运行”的问题；Kubernetes 解决“如何在集群中管理大量容器”的问题。

五、Docker 和 Kubernetes 是竞争关系吗？

很多初学者会误以为 Docker 和 Kubernetes 是二选一关系。其实它们更多是 配合关系，而不是竞争关系。

一个常见流程是：

1. 开发者写好应用代码；
2. 使用 Dockerfile 构建 Docker 镜像；
3. 将镜像推送到镜像仓库；
4. Kubernetes 从镜像仓库拉取镜像；
5. Kubernetes 在集群中创建 Pod；
6. Pod 中运行容器；
7. Kubernetes 负责服务发现、负载均衡、扩缩容和故障恢复。

也就是说：

• Docker 常用于制作镜像和本地运行容器；
• Kubernetes 常用于生产环境管理容器。

需要注意的是，Kubernetes 早期可以直接使用 Docker 作为容器运行时。但后来 Kubernetes 移除了对 Docker Shim 的直接支持，转向使用符合 CRI 标准的容器运行时，例如：

• containerd；
• CRI-O。

不过这并不意味着 Docker 没用了。Docker 仍然广泛用于本地开发、镜像构建和调试。很多镜像也是用 Dockerfile 构建出来的，并且镜像格式仍然是通用的 OCI 标准。

六、为什么有了 Docker 还需要 Kubernetes？

如果你只是个人项目，或者在一台服务器上部署一个博客、一个后台系统，Docker 已经足够好用。比如你可以用 Docker Compose 启动：

• Nginx；
• MySQL；
• Redis；
• 后端应用；
• 前端应用。

但企业级生产环境通常不只是“一台服务器 + 几个容器”。它可能有：

• 多台服务器；
• 多个业务服务；
• 高并发访问；
• 灰度发布需求；
• 故障自动恢复需求；
• 服务治理需求；
• 自动扩容需求；
• 多环境部署需求；
• 资源隔离和权限管理需求。

这时，如果仍然手动执行 Docker 命令，就会出现很多问题。

例如，你有 10 台服务器、50 个服务、每个服务 3 个副本，总共就是 150 个容器。你需要考虑：

• 每个容器运行在哪台机器上？
• 某台机器资源不足怎么办？
• 某个容器挂了谁来重启？
• 新版本如何逐步发布？
• 如何回滚？
• 如何让服务之间互相找到？
• 如何做负载均衡？
• 如何统一管理配置？
• 如何查看运行状态？

Kubernetes 的意义就在于，把这些复杂操作自动化、标准化、平台化。

七、Docker Compose 和 Kubernetes 有什么区别？

初学者还经常听到 Docker Compose。它和 Kubernetes 也容易混淆。

Docker Compose 是 Docker 提供的一个多容器管理工具。它通过 docker-compose.yml 文件定义多个容器如何一起启动。

例如，一个 Web 项目可能包括：

• 后端服务；
• MySQL；
• Redis；
• Nginx。

用 Docker Compose 可以一条命令启动全部服务：

docker compose up -d

Docker Compose 非常适合：

• 本地开发环境；
• 小型项目；
• 单机部署；
• 快速测试。

但 Docker Compose 不擅长大规模集群管理。它通常不会像 Kubernetes 那样提供完整的自动调度、自动恢复、复杂网络策略、声明式部署和生态扩展能力。

对比来看：

可以这样记：

Docker 是“单个容器工具”，Docker Compose 是“单机多容器工具”，Kubernetes 是“集群级容器管理平台”。

八、实际项目中 Docker 和 Kubernetes 怎么配合？

下面用一个简单的后端服务部署流程来说明。

假设你有一个 Spring Boot 项目。

第一步：编写 Dockerfile

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/demo.jar app.jar
EXPOSE 8080
CMD ["java", "-jar", "app.jar"]

这个文件定义了如何把 Java 应用打包成镜像。

第二步：构建镜像

docker build -t demo-api:1.0 .

第三步：推送到镜像仓库

docker tag demo-api:1.0 registry.example.com/demo-api:1.0
docker push registry.example.com/demo-api:1.0

第四步：编写 Kubernetes Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: demo-api
          image: registry.example.com/demo-api:1.0
          ports:
            - containerPort: 8080

这段配置表示：希望 Kubernetes 运行 3 个 demo-api 副本。

第五步：编写 Service

apiVersion: v1
kind: Service
metadata:
  name: demo-api-service
spec:
  selector:
    app: demo-api
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

这段配置为 demo-api 提供一个稳定的集群内部访问入口。

第六步：应用配置

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

之后 Kubernetes 会自动拉取镜像、创建 Pod、维护副本数量。如果某个 Pod 出现异常，它会自动重新创建。

九、从架构角度理解二者差异

Docker 更关注“运行单元”

Docker 的核心是容器。它关心的是：

• 如何构建镜像；
• 如何运行容器；
• 如何配置容器网络；
• 如何挂载数据卷；
• 如何查看日志；
• 如何进入容器调试。

它偏向开发者和单机部署场景。

Kubernetes 更关注“系统状态”

Kubernetes 的核心不是某一个容器，而是整个集群的状态。它关心的是：

• 当前集群有多少节点；
• 哪些应用应该运行；
• 每个应用需要几个副本；
• 服务之间如何通信；
• 资源如何分配；
• 故障如何恢复；
• 应用如何升级；
• 配置如何管理；
• 权限如何控制。

它偏向平台工程、运维、SRE 和生产部署场景。

十、Docker 的优点和局限

Docker 的优点

1. 简单易用

Docker 命令相对直观，入门门槛不高。初学者可以很快学会拉取镜像、运行容器、查看日志和构建镜像。

2. 环境隔离

不同应用可以运行在不同容器中，避免依赖冲突。例如一个项目用 Python 3.8，另一个项目用 Python 3.11，都可以通过不同容器运行。

3. 交付标准化

镜像成为应用交付物，部署时不再只交付源代码，而是交付可运行环境。

4. 生态成熟

Docker Hub 上有大量现成镜像，例如 MySQL、Redis、Nginx、MongoDB、PostgreSQL 等。

Docker 的局限

1. 单机管理能力有限

Docker 可以管理当前机器上的容器，但如果有几十台服务器，就难以统一调度。

2. 高可用能力不足

容器异常可以配置重启策略，但跨节点故障恢复不是 Docker 单独擅长的事情。

3. 大规模部署复杂

滚动更新、灰度发布、自动扩缩容、服务发现等能力需要额外工具配合。

十一、Kubernetes 的优点和局限

Kubernetes 的优点

1. 强大的自动化能力

Kubernetes 可以自动调度、自动恢复、自动扩缩容，让生产系统更加稳定。

2. 适合微服务架构

微服务数量多、调用关系复杂，Kubernetes 提供了统一的部署和服务管理方式。

3. 声明式配置

通过 YAML 描述期望状态，更适合自动化和 GitOps 流程。

4. 云原生生态丰富

Kubernetes 已经成为云原生领域的事实标准，周边生态非常庞大，例如：

• Helm；
• Prometheus；
• Grafana；
• Istio；
• Argo CD；
• Knative；
• Longhorn；
• cert-manager。

5. 跨云能力强

很多云厂商都提供托管 Kubernetes 服务，例如：

• Google GKE；
• AWS EKS；
• Azure AKS；
• 阿里云 ACK；
• 腾讯云 TKE；
• 华为云 CCE。

这让企业更容易在不同云平台之间迁移应用。

Kubernetes 的局限

1. 学习成本高

Kubernetes 概念较多，涉及 Pod、Deployment、Service、Ingress、ConfigMap、Secret、PV、PVC、RBAC、Namespace 等。

2. 运维复杂

自建 Kubernetes 集群需要关注控制平面、高可用、网络插件、存储插件、证书、监控、日志等问题。

3. 对小项目可能过重

如果只是一个小型网站或个人项目，上 Kubernetes 可能反而增加复杂度。

十二、零基础应该先学 Docker 还是 Kubernetes？

建议顺序是：

先学 Docker，再学 Docker Compose，最后学 Kubernetes。

原因很简单：Kubernetes 虽然不是 Docker 的“升级版”，但它管理的对象本质上仍然是容器化应用。如果你不理解镜像、容器、端口映射、数据卷、环境变量，就很难理解 Kubernetes 中的 Pod、Deployment、Service 等概念。

推荐学习路线

第一阶段：Linux 基础

至少掌握：

• 常用命令：cd、ls、cat、grep、ps、top；
• 文件权限；
• 进程概念；
• 网络端口；
• systemd 基础；
• SSH 登录服务器。

第二阶段：Docker 基础

重点学习：

• 镜像和容器区别；
• docker run；
• docker ps；
• docker logs；
• docker exec；
• 端口映射；
• 数据卷；
• Dockerfile；
• 镜像构建和推送。

第三阶段：Docker Compose

学习如何用一个 YAML 文件启动多个服务，比如 Web + MySQL + Redis。

第四阶段：Kubernetes 基础

重点学习：

• Pod；
• Deployment；
• Service；
• Namespace；
• ConfigMap；
• Secret；
• Ingress；
• kubectl；
• YAML 声明式配置。

第五阶段：Kubernetes 进阶

可以继续学习：

• Helm；
• PV/PVC 存储；
• HPA 自动扩缩容；
• RBAC 权限；
• Prometheus 监控；
• Grafana 可视化；
• 日志采集；
• CI/CD；
• GitOps。

十三、常见误区

误区一：Kubernetes 替代了 Docker

不准确。

Kubernetes 替代的不是 Docker 的全部能力，而是生产环境中“手动管理容器”的方式。Docker 在镜像构建、本地开发、容器调试方面仍然很常见。

误区二：用了 Docker 就一定要用 Kubernetes

不一定。

如果项目规模小、部署简单，用 Docker 或 Docker Compose 就很好。Kubernetes 适合复杂系统和生产集群，不是所有项目都需要。

误区三：Kubernetes 很难，所以没必要学 Docker

恰恰相反。Docker 是理解容器世界的基础。学好 Docker，再学 Kubernetes 会轻松很多。

误区四：容器就是虚拟机

容器和虚拟机都能隔离环境，但原理不同。

虚拟机通常包含完整操作系统，隔离更彻底，但更重。容器共享宿主机内核，更轻量，启动更快。

误区五：Kubernetes 只适合大公司

Kubernetes 确实常用于中大型企业，但现在很多云厂商提供托管 K8s，小团队也可以使用。不过是否使用仍要看业务复杂度和团队能力。

十四、如何选择：用 Docker 还是 Kubernetes？

可以按以下标准判断。

适合只用 Docker 的情况

• 个人项目；
• 学习测试；
• 单机部署；
• 服务数量少；
• 不需要复杂扩缩容；
• 不需要多节点高可用；
• 团队没有 Kubernetes 运维能力。

例如：

• 个人博客；
• 小型后台管理系统；
• 内部工具；
• 测试环境；
• 简单 API 服务。

适合 Docker Compose 的情况

• 一个项目包含多个组件；
• 需要快速搭建本地环境；
• 单机运行多个服务；
• 希望通过一个配置文件管理服务。

例如：

• Web + MySQL + Redis；
• 前后端联调环境；
• 本地微服务模拟环境。

适合 Kubernetes 的情况

• 服务数量多；
• 多台服务器部署；
• 需要高可用；
• 需要自动扩缩容；
• 需要滚动发布；
• 需要灰度发布；
• 需要统一配置管理；
• 需要标准化 DevOps 平台；
• 团队具备一定云原生能力。

例如：

• 电商平台；
• 金融系统；
• 大型 SaaS 平台；
• 高并发 API 网关；
• 中大型微服务系统。

十五、用一句话记住它们

如果你是零基础，可以先记住下面几句话：

Docker 是打包和运行容器的工具。
Kubernetes 是管理大量容器的集群平台。
Docker 解决环境一致性问题。
Kubernetes 解决大规模容器运维问题。
小项目用 Docker 或 Docker Compose，大项目和生产集群常用 Kubernetes。

十六、总结

Docker 和 Kubernetes 都是云原生技术体系中的重要组成部分，但它们的定位完全不同。

Docker 让应用可以被打包成标准化镜像，并以容器方式运行。它解决了环境一致、快速部署、依赖隔离和应用迁移的问题。对开发者来说，Docker 是非常实用的工具，也是学习容器技术的起点。

Kubernetes 则站在更高层面，负责在集群中管理大量容器。它可以自动调度、自动恢复、滚动更新、服务发现、负载均衡、扩缩容和配置管理。对企业生产环境来说，Kubernetes 是构建云原生平台的重要基础。

二者不是简单的替代关系，而是上下游配合关系。常见模式是：用 Docker 构建镜像，用 Kubernetes 部署和管理镜像运行后的容器应用。

对于初学者，最好的学习路径不是一上来就啃 Kubernetes，而是先掌握 Docker 的基本概念和命令，再学习 Docker Compose，最后进入 Kubernetes。这样你会发现，Kubernetes 中很多看似复杂的概念，其实都是建立在容器基础之上的。

最后再用一个比喻收尾：

Docker 像是标准化集装箱，负责把货物装好；Kubernetes 像是港口和物流调度系统，负责把成千上万个集装箱高效、安全、自动地运输和管理。

理解了这一点，你就真正抓住了 Docker 和 Kubernetes 的核心区别。