Docker-Compose、Swarm还是K8s？一张图看懂容器编排修罗场：从单机到亿级流量的终极选择指南_在kubernetes中,监控数据和生命周期可以统一的是逻辑概念和物理概念。-CSDN博客

本文链接：https://blog.csdn.net/lzhcoder/article/details/95161888

本文对比了Docker-Compose、Docker Swarm和Kubernetes的区别，指出Kubernetes是谷歌研发的容器管理平台，已成为大公司默认技术。还介绍了Kubernetes的相关概念，如节点、容器组等，阐述了其架构设计，包括主节点和工作节点，以及运行机制和网络通讯等内容。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Docker-Compose 、Docker Swarm和Kubernetes的对比

Docker-Compose 、Docker Swarm和Kubernetes的对比

Docker-Compose

Docker-Compose 是用来管理你的容器的，有点像一个容器的管家，想象一下当你的Docker中有成百上千的容器需要启动，如果一个一个的启动那得多费时间。有了Docker-Compose你只需要编写一个文件，在这个文件里面声明好要启动的容器，配置一些参数，执行一下这个文件，Docker就会按照你声明的配置去把所有的容器启动起来，但是Docker-Compose只能管理当前主机上的Docker，也就是说不能去启动其他主机上的Docker容器

Docker Swarm

Docker Swarm 是一款用来管理多主机上的Docker容器的工具，可以负责帮你启动容器，监控容器状态，如果容器的状态不正常它会帮你重新帮你启动一个新的容器，来提供服务，同时也提供服务之间的负载均衡，而这些东西Docker-Compose 是做不到的,它比K8s更加轻量

Kubernetes

Kubernetes它本身的角色定位是和Docker Swarm 是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，当然也有自己一些不一样的特点。它是谷歌公司根据自身的多年的运维经验研发的一款容器管理平台。而Docker Swarm则是由Docker 公司研发的

这两年Kubernetes已经成为了很多大公司的默认使用的容器管理技术

Kubernetes的具体介绍

能力类别	主要能力	描述
自动化管理	自动部署和缩放	支持水平自动缩放（HPA），根据负载动态调整Pod数量；自动化容器部署和更新。
网络与服务	服务发现和负载均衡	内置服务发现机制，通过DNS或环境变量暴露服务；自动负载均衡流量到多个容器。
存储与配置	存储编排	动态分配持久卷（PV），支持多种存储后端如云存储或本地磁盘。
配置与秘密管理	秘密和配置管理	通过ConfigMaps和Secrets安全存储和管理配置数据，避免硬编码。
可靠性与恢复	自我修复	自动重启失败容器，监控健康检查并替换不健康Pod。
更新与回滚	自动化 rollout 和 rollback	支持滚动更新（零停机部署）和自动回滚到先前版本。
资源优化	自动 bin packing	根据资源请求和限制智能调度容器到节点，优化资源利用。
可移植性与扩展	可移植性和集成	容器跨环境（云、本地、混合）可移植；支持扩展插件如CNI网络和CSI存储。

节点（Node ）：一个节点是一个运行 Kubernetes 中的主机。
容器组（Pod ） ：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享资源（网络、 Volumes）。K8s中的最小任务调度单元，可以被调度到任意Node上恢复。
容器组生命周期（pos-states ）：包含所有容器状态集合，包括容器组状态类型，容器组生命周期，事件，重启策略，以及 replication controllers。
Replication Controllers：主要负责指定数量的 pod 在同一时间一起运行，保证pod高可用的API对象。
服务（services ） ：对一组提供相同功能的Pods 的抽象，并为它们提供一个统一的入口。
卷（volumes ）：一个卷就是一个目录，容器对其有访问权限用于持久化数据。
标签（labels ）：标签是用来连接一组对象的，比如容器组。标签可以被用来组织和选择子对象。

ConfigMap：用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。
接口权限（accessing_the_api ）：端口，IP 地址和代理的防火墙规则。
web 界面（ux ）：用户可以通过 web 界面操作 Kubernetes。
命令行操作（cli ）： kubecfg 命令

容器组

和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，知道容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。（也许在将来的版本中会添加容器组的移动）

服务

Replication Controller

存储卷

Volumes（存储卷）是Pod中能够被多个容器访问的共享目录。 Kubernetes的Volumes概念与Docker的Volumes比较类似，但并不完全相同。 Kubernetes中的Volumes与Pod生命周期相同，而不与容器的生命周期相关。当容器终止或者重启时，Volumes中的数据也不会丢失。另外， Kubernetes支持多种类型的Volumes，并且一个Pod可以同时使用任意多个Volumes。

架构设计

如果让我们自己从头设计一套容器管理平台，有如下几个方面是很容易想到的：
1.分布式架构，保证扩展性；
2.逻辑集中式的控制平面 + 物理分布式的运行平面；
3.一套资源调度系统，管理哪个容器该分配到哪个节点上；
4.一套对容器

Kubernetes 首先是一套分布式系统，由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点（ Master Node）；一类是属于运行平面的工作节点（ Worker Node）。

显然，复杂的工作肯定都交给控制节点去做了，工作节点负责提供稳定的操作接口和能力抽象即可。

从这张图上，我们没有能发现 Kubernetes 中对于控制平面的分布式实现，但是由于数据后端自身就是一套分布式的数据库 Etcd，因此可以很容易扩展到分布式实现

Etcd
这里 Etcd 即作为数据后端，又作为消息中间件。通过 Etcd 来存储所有的主节点上的状态信息，很容易实现主节点的分布式扩展。组件可以自动的去侦测 Etcd 中的数值变化来获得通知，并且获得更新后的数据来执行相应的。

主节点服务
主节点上需要提供如下的管理服务：
apiserver 是整个系统的对外接口，提供一套 RESTful 的 Kubernetes API，供客户端和架构设计其它组件调用；
scheduler 负责对资源进行调度，分配某个 pod 到某个节点上。是 pluggable 的，意味着很容易选择其它实现方式；
controller-manager 负责管理控制器，包括 endpoint-controller（刷新服务和 pod 的关联信息）和 replication-controller（维护某个 pod 的复制为配置的数值）

工作节点

kubelet 是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等；
kube-proxy 是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod（同一类标签）