k8s和docker区别_k8s与docker区别

docker、docker-compose、docker swarm和k8s的区别

Docker 这个东西所扮演的角色，容易理解，它是一个容器引擎，也就是说实际上我们的容器终是由Docker创建，运行在Docker中，其他相关的容器技术都是以Docker为基础，它是我们使用其他容器技术的核心。

k8s和docker区别_k8s与docker区别

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

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

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

既然这两个东西是一样的，那就面临选择的问题，应该学习哪一个技术呢?实际上这两年Kubernetes已经成为了很多大公司的默认使用的容器管理技术，而Docker Swarm已经在这场与Kubernetes竞争中已经逐渐失势，如今容器管理领域已经开始已经逐渐被Kubernetes一统天下了。所以建议大家学习的时候，应该多考虑一下这门技术在行业里面是不是有很多人在使用。

需要注意的是，虽然Docker Swarm在与Kubernetes的竞争中败下阵来，但是这个跟Docker这个容器引擎没有太大关系，它还是整个容器领域技术的基石，Kubernetes离开他什么也不是。

总结

Docker是容器技术的核心、基础，Docker Compose是一个 基于Docker的单主机容器编排工具.而k8s是一个跨主机的集群部署工具 ，功能并不像Docker Swarm和Kubernetes是基于Dcoker的跨主机的容器管理平台那么丰富

k8s为啥不建议用docker了

k8s不建议用docker的原因如下：

1、docker比k8s发布的早；

2、Docker 本身不兼容 CRI 接口，并没有实现 CRI 的打算，同时也不支持容器的一些新需求，社区想要摆脱Dockershim的高维护成本，。

3、k8s不能直接与docker通信，只能与 CRI 运行时通信，要与 Docker 通信，就必须使用桥接服务(dockershim)，k8s要与docker通信是通过节点Kubelet的Dockershim（k8s社区维护的）将请求转发给管理容器的 Docker 服务。

4、Dockershim 一直都是 Kubernetes 为了兼容 Docker 获得市场采取的临时方案（决定）。

5、k8s在过去因为 Docker 的热门而选择它，现在又因为高昂的维护成本而放弃它，我们能够从这个过程中体会到容器领域的发展和进步。

6、对于已经统治市场的k8s来说，Docker 的支持显得非常鸡肋，移除代码也就顺理成章。

7、在集群中运行的容器运行时往往不需要docker这么复杂的功能，k8s需要的只是 CRI 中定义的那些接口。

kubernetes 为何弃用docker？

在Kubernetes中弃用Docker?这听起来像是2020年非常热门的一条信息。虽然Docker是容器的同义词，但很多人没有意识到作为一个产品，Docker是由多个组件组成的，是一个容器的技术栈。

其中一个组件是容器运行时，是kubernetes与容器交互需要的。容器运行时可以拆分成high-level运行时和low-level运行时两部分。两者作用不同，但工作在一块。high-level运行时主要负责比如从仓库拉取镜像、管理镜像、和处理镜像到low-level运行时的工作。low-level运行时将根据镜像具体负责创建、删除和运行容器。high-level和low-level运行时都遵循特定的规范：容器运行时接口（CRI）和开放容器标准协议（OCI）。

容器运行时接口(CRI)是在Kubernetes 1.5中作为alpha版本引入的。CRI的目标是使Kubernetes生态系统更具可扩展性，为开发人员提供Kubernetes将如何与运行时交互的蓝图。开发人员如何实际设计和实现运行时完全取决于他们，只要满足接口。作为集群维护者，CRI的标准化允许我们决定在我们的环境中使用哪个容器运行时。 这也使得Kubernetes变得更加灵活，因为它现在不需要我们掌握每种特定的运行时。当前可用的两个流行容器运行时是containerD和CRI-O。

开放容器标准协议 (OCI)于2015年由Container领域的发起，他们认为构建容器镜像的方式应该标准化。根据OCI规范构建的镜像将与任何容器运行时适配，只要运行时遵循并符合OCI规范。因此，无论你是用docker还是podman构建容器映像，你的容器镜像都将兼容多个规格，并继续在你的集群中运行。一些主流的OCI运行时有runC、Kata容器（英特尔Clear Containers和Hyper RunV项目）和Gvisor（goole项目）。

现在让我们重新回到主题Docker以及它被弃用的原因。Docker知道如何与容器交互，因为它使用ContainerD作为它的high-level运行时，使用runC作为它的low-level运行时，这两个运行时都位于Docker的多个内层组件中，并被抽象化给用户。尽管ContainerD和runC都是遵循CRI和OCI标准，我们也会遇到一个问题，因为Docker本身不能满足CRI的要求，而CRI是Kubernetes需要与运行时交互的。随着Dockershim的引入，这个问题得到了解决。Dockershim作为Kubernetes和Docker之间的中间件，并且兼容CRI。

然而，Dockershim的一个缺点是，你正在加载整个Docker堆栈，并让Kubernetes与shim通信，shim然后与Dock通信，docker通过调用栈直到它到达containerD。这在容器工作流程中增加了不必要的步骤，因为Kubernetes可以直接与containerD或任何其他CRI兼容的运行时交互。使用Dockershim本来是一种临时的解决方案，但它慢慢地变成了一种负担，因此不得不弃用它。

总之，Kubernetes需要一种与容器交互的方式。这是由处理容器生命周期的容器运行时解决的。Kubernetes可以与任何容器运行时交互，如果它们符合容器运行时接口(container runtime Interface)，该接口定义了Kubernetes将如何与提供的运行时交互。此外，所有的镜像/容器和运行时必须遵循OCI，它定义了如何创建镜像或容器。至于Docker，它是一个抽象了一个容器运行时的技术栈，不符合CRI。

docker 入门（二）：docker 和 沙盒、虚拟机以及 Kubernetes 的关系

做开发的基本都听说过沙盒 (Sandbox) 和虚拟机 (Virtual Machine，简称 VM) ，如今容器技术很火，其中以 docker 受大家欢迎。作为一种集群管理工具，K8s 近也是火的不要不要的。 我们经常会讲 docker 和 K8s 联系起来，那么两者之间又存在什么关联呢？

首先 Sandbox 和 VM 都是属于 虚拟技术 ，用来虚拟软件运行环境并具有资源隔离的功能。Sandbox 比较“轻”（只需要虚拟出一个小的且一旦退出就释放之前占用的资源；VM 则比较重（虚拟出整个作系统，相当于子电脑）。关于 Sandbox 和 VM 的区别可以参考博客： 。

容器是属于 Sandbox 的一种。 顾名思义，沙盒就是能够像一个集装箱一样，把你的应用“装”起来的技术。这样，应用与应用之间，就因为有了边界而不至于相互干扰；而被装进集装箱的应用，也可以被方便地搬来搬去。 容器技术的核心功能 ，就是通过 约束和修改进程的动态表现 ，从而为其 创造出一个“边界” 。正是因为这个边界才会让容器里面的程序看不到宿主机上其他的程序从而给程序一种它就是在一个独立的作系统上的假象。容器具有如下几个优点：

Docker 是一种 轻量级的虚拟化 技术，即容器技术。随着 Docker 的开源，docker 凭借其“轻”的特点得到迅速的普及。

这三个优点恰是 VM 的缺点。

Docker 原意是指处理码头集装箱的工人。 首先需要注意的是， Docker 本身不是容器 ，而是一个 开源的应用容器引擎 。Docker 让开发者可以以统一的方式 打包 他们的 应用以及依赖包 到一个 可移植的容器 中，然后 发布 到任何 安装了docker引擎的服务器上 （包括流行的Linux机器、windows机器），也可以实现虚拟化。从这个描述可以看出 Docker 的几种常用任务：

Docker 的两句口号很准确地描述了其功能：

1. Build, ship and run

顾名思义，创建、运输和运行。

举个例子来理解：比如说我在 A 地建好了一个厂区，该厂区主要的是车间，其次还有一些配套的生活设施（比如食堂、超市、宿舍、水电等）。现在我要将厂迁到 B 地，按照常规思路就是把 A 地的车间拆了运到 B 地重新组装、并在 B 地建好配套的生活设施，工程量明显很大。假设现在有一种魔法能够在A地将车间及其配套的生活设施 一份并打包成一个镜像 image（文件） ，然后将该镜像迁移到 B 地，这样在B地马上就能够投入使用，省去了拆机、重装以及搭建配套生活设施的工作，非常方便快捷。

现在我们将 车间类比成一个application ，将 配套的生活设施类比成依赖 ，那么 docker 就是这种魔法 。

2. Build once, run anywhere

顾名思义，一次创建、随地运行。

我们知道 车间是用于工业生产的 ，即一个application。在这个世界，还存在很多其他的application，比如学校、医院、写字楼、商场、体育场等，它们各自负责不同的用途。假设这些 application 都是能够共享的，那么这个效率将会很高，比如A需要用到体育馆，可以从B一个过来；B需要用到学校，可以从A一个过来。Docker 使用的就是这种理念，Docker 中包含三个核心部分：

镜像仓库（Repository）可以是私有的（比如本地机器的 Docker repository），也可以是公有的（比如 Docker 提供的Docker Hub、第三方的 Hub）。 负责管理镜像仓库（Repository）的是 Docker Registry 服务 （就像是图书馆管理员）。Docker 提供的 Docker Hub 对于镜像来源有着严格的把控，有很多高质量的 application 镜像，也是开发人员用的多的public registry 服务。

那么为什么需要 Kubernetes 呢？就在 Docker 容器技术被炒得热火朝天之时，大家发现，如果想要将 Docker 应用于具体的业务实现（当 容器和服务器的数量达到一定规模 的时候，就会碰到管理的

问题，即 如何有效管理大量的服务器和容器 ，保证 应用的稳定运行、方便升级和故障的快速解决 ），是存在困难的—— 编排、管理和调度等各个方面都不容易 。于是就迫切 需要一套容器编排工具 ，能够对 Docker 和容器进行 更高级、灵活的管理 。容器编排工具提供图形化界面或者命令行来管理容器和服务器集群，提供容器配置、任务发布、服务发现、负载均衡、系统监控和故障恢复、声明式系统配置以及有关容器部署和性能的规则和约束定义机制等。

就在这个时候， Google开发的 Kubernetes 从众多编排工具中脱颖而出 ，赢下了容器编排工具大战。Kubernetes 是一种 基于容器的集群管理平台 。Kubernetes 是希腊语，意为“舵手、领航员”，大家都习惯将 Kubernetes 简称为K8s（ubernete 包含8个字母）。K8s 初由 Google 创建而后加入 openstack 基金会并发布了 K8s V1.0。

Docker 公司自己有一款名为 Docker Swarm的产品，它是一个容器集群和调度工具，功能类似于Kubernetes。相比 Kubernetes，Swarm在集群搭建和使用上要相对简单一些，学习和部署成本相对低一些。较新版本的Docker已经集成了Swarm。Swarm支持跨多个主机进行编排，管理较小规模的容器集群也绰绰有余，对于初学者也可以很快的部署和运行。

笔者水平有限，如有错误，敬请指正！

参考：

kubernetes与docker的关系是什么？

合作关系，Docker作为单一的容器技术工具并不能很好地定义容器的“组织方式”和“管理规范”，难以独立地支撑起生产级大规模容器化部署的要求。因此容器技术的发展就迅速走向了以Kubernetes为代表的“容器编排”的技术路线.

Kubernetes的出现也重新定义了微服务架构的技术方向，“云原生”及“ServiceMesh(服务网格)”等概念，很大程度上也是依赖于Kubernetes所提供的基础能力。

扩展资料：

常用命令分享

拉取docker镜像

docker pull image_name

查看宿主机上的镜像，Docker镜像保存在/var/lib/docker目录下:

docker images

删除镜像

docker rmi

查看当前有哪些容器正在运行

docker ps

查看所有容器

docker ps -a

启动、停止、重启容器命令：

docker start container_name/container_iddocker stop container_name/container_iddocker restart container_name/container_id

后台启动一个容器后，如果想进入到这个容器，可以使用attach命令：

docker attach container_name/container_id

删除容器的命令：

docker rm container_name/container_id

查看当前系统Docker信息

docker info