k8s和docker区别（k8s为啥不建议用docker了）

本文目录

• k8s为啥不建议用docker了
• kubernetes与docker的关系是什么
• docker+k8s简介
• docker和k8s有什么区别
• k8s和docker区别 具体是怎么样的
• kubernetes和Docker关系简单说明
• k8s和docker区别
• kubernetes 为何弃用docker

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的关系是什么

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

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

扩展资料：

常用命令分享

拉取docker镜像

docker pull image_name

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

docker images

删除镜像

docker rmidocker.io/tomcat:7.0.77-jre7 或者 docker rmi b39c68b7af30

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

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

docker+k8s简介

容器是镜像的可运行实例。容器是您机器上的沙盒进程，与主机上的所有其他进程隔离。总而言之，一个容器：

运行容器时，它使用隔离的文件系统。此自定义文件系统由 容器映像 提供。由于镜像包含容器的文件系统，它必须包含运行应用程序所需的一切——所有依赖项、配置、脚本、二进制文件等。镜像还包含容器的其他配置，例如环境变量、运行的默认命令、和其他元数据。

Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器镜像中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。 容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。

如果说以 Docker 为代表的容器引擎将软件的发布流程从分发二进制安装包转变为直接分发虚拟化后的整个运行环境，令应用得以实现跨机器的绿色部署；那以 Kubernetes 为代表的容器编排框架，就是把大型软件系统运行所依赖的集群环境也进行了虚拟化，令集群得以实现跨数据中心的绿色部署，并能够根据实际情况自动扩缩。 以容器构建系统 自从 Docker 提出“以封装应用为中心”的容器发展理念，成功取代了“以封装系统为中心”的 LXC 以后，一个容器封装一个单进程应用已经成为被广泛认可的最佳实践。然而单体时代过去之后，分布式系统里应用的概念已不再等同于进程，此时的应用需要多个进程共同协作，通过集群的形式对外提供服务，以虚拟化方法实现这个目标的过程就被称为容器编排（Container Orchestration）。 容器之间顺畅地交互通信是协作的核心需求，但容器协作并不仅仅是将容器以高速网络互相连接而已。如何调度容器，如何分配资源，如何扩缩规模，如何最大限度地接管系统中的非功能特性，让业务系统尽可能免受分布式复杂性的困扰都是容器编排框架必须考虑的问题，只有恰当解决了这一系列问题，云原生应用才有可能获得比传统应用更高的生产力 Docker 设计的 Dockerfile 只允许有一个 ENTRYPOINT，这并非无故添加的人为限制，而是因为 Docker 只能通过监视 PID 为 1 的进程（即由 ENTRYPOINT 启动的进程）的运行状态来判断容器的工作状态是否正常，容器退出执行清理，容器崩溃自动重启等操作都必须先判断状态。设想一下，即使我们使用了 supervisord 之类的进程控制器来解决同时启动 Nginx 和 Filebeat 进程的问题，如果因某种原因它们不停发生崩溃、重启，那 Docker 也无法察觉到，它只能观察到 supervisord 的运行状态，

在想要创建的 Kubernetes 对象对应的 .yaml 文件中，需要配置如下的字段：

也需要提供对象的 spec 字段。对象 spec 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。 Kubernetes API 参考 能够帮助我们找到任何我们想创建的对象的 spec 格式。

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括：

“Service” 简写 “svc”。如上文提到的，Pod不能直接提供给外网访问，而是应该使用service。Service就是把Pod暴露出来提供服务，Service才是真正的“服务”，它的中文名就叫“服务”。Service代理Pod集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端Pod中的容器。 k8s使用service还有一个原因。一般而言，k8s每创建一个新的Pod，它的ip地址都是不一样的，一个Service与特定的一个或者一组Pod挂钩，即使Pod挂掉了，k8s又创建了新的特定的Pod，Service仍然与这个新的Pod挂钩，这样，Pod的ip不一样了，哪怕端口也不一样了，仍然能通过Service来获取Pod所提供的服务。 Service是如何保持这种与特定Pod绑定的关系的呢？那就是“Label”和“Label Selector”，可以给Pod分配特定的Label，然后配置Service，通过“Lable Selector”选择具有这些特定“Label”的Pod来接受请求、提供服务。

为容器设定最大的资源配额的做法从 cgroups 诞生后已经屡见不鲜，但你是否注意到 Kubernetes 给出的配置中有limits和requests两个设置项？这两者的区别其实很简单：requests是给调度器用的，Kubernetes 选择哪个节点运行 Pod，只会根据requests的值来进行决策；limits才是给 cgroups 用的，Kubernetes 在向 cgroups 的传递资源配额时，会按照limits的值来进行设置。

docker和k8s有什么区别

docker和k8s区别有：虚拟化角度不同、部署角度不同。

一、虚拟化角度：

传统的虚拟技术，在将物理硬件虚拟成多套硬件后，需要再每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序。

Docker容器内的应用程序进程直接运行在宿主机（真实物理机）的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。每个集群有多个节点，每个节点可，我们的kuberbete就是管理这些应用程序所在的小运行环境（container）而生。

二、部署角度：

传统方式是将所有应用直接部署在同一个物理机器节点上，这样每个App的依赖都是完全相同的，无法做到App之间隔离，当然，为了隔离，我们也可以通过创建虚拟机的方式来将App部署到其中，但这样太过繁重，故比虚拟机更轻便的Docker技术出现，现在我们通过部署Container容器的技术来部署应用，全部Container运行在容器引擎上即可。

以kubernetes为代表的容器集群管理系统，我们用kubernetes去管理Docker集群，即可以将Docker看成Kubernetes内部使用的低级别组件。另外，kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。

简介：

docker是一个开源的应用容器引擎，开发者可以打包他们的应用以及依赖到一个容器中，发布到流行的liunx系统上，或者实现虚拟化。k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等。

k8s和docker区别 具体是怎么样的

1、k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

2、Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。

3、Docker容器与传统虚拟化方式的不同，传统的虚拟技术，在将物理硬件虚拟成多套硬件后，需要再每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序。

4、Docker容器内的应用程序进程直接运行在宿主机(真实物理机)的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。

kubernetes和Docker关系简单说明

最近项目用到kubernetes（以下简称k8s，k和s之间有8个字母)。虽然之前也有简单使用过，但最近发现k8s概念较多，命令也有些不够用了，故想借此机会写点东西，更全面认识并使用k8s。本篇文章目的：让你更全面了解k8s概念，以及学到在工作中常用的操作。整体更偏向于原理和应用。在正式开始k8s之前，我们先看看k8s和Docker的关系，分别从虚拟化角度、部署方式角度叙述why use容器，话不多说，开干。 目前发现并没有将kubernetes和Docker技术产生背景和需求进行比较的文章，本文从最纯正的官方定义角度出发并展开，阐述二者产生背景及与传统技术对比。 简要介绍： 官方定义1：Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。 官方定义2：k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。 与传统技术对比： 接下来我们看两张经典的图： 一、从虚拟化角度： 图1 上图是Docker容器（可用k8s管理的玩意儿）与传统虚拟化方式的不同之处，传统的虚拟技术，在将物理硬件虚拟成多套硬件后，需要再每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序。而Docker容器内的应用程序进程直接运行在宿主机(真实物理机)的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。 每个集群有多个节点，每个节点可，我们的kuberbete就是管理这些应用程序所在的小运行环境（container）而生。 二、从部署角度 图2 注意，大家别把这幅图与上面Docker的那张图混淆了，图1是从虚拟化角度，说明了为应用提供必要的运行环境所需要做的虚拟化操作（即：传统：虚拟出的虚拟机装操作系统、Docker：容器引擎管理下的容器）。 而图2是在这些具体运行环境上进行真实应用部署时的情况，传统方式是将所有应用直接部署在同一个物理机器节点上，这样每个App的依赖都是完全相同的，无法做到App之间隔离，当然，为了隔离，我们也可以通过创建虚拟机的方式来将App部署到其中（就像图1上半部分那样），但这样太过繁重，故比虚拟机更轻便的Docker技术出现，现在我们通过部署Container容器的技术来部署应用，全部Container运行在容器引擎上即可。既然嫌弃虚拟机繁重，想用Docker，那好，你用吧，怎么用呢？手动一个一个创建？当然不，故kubernetes技术便出现了，以kubernetes为代表的容器集群管理系统，这时候就该上场表演了。 说白了，我们用kubernetes去管理Docker集群，即可以将Docker看成Kubernetes内部使用的低级别组件。另外，kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。希望我这篇文章中简单的描述能让你对两者有所理解和认识。

k8s和docker区别

Docker和K8s是两个不同的技术，docker是一种容器化技术，而K8s是一种容器编排技术，其主要的区别在于其使用场景和应用范围上。

Docker是一种开源的容器化平台，它可以将应用及其依赖打包到一个可移植的容器中，从而使应用可以在任何地方运行。Docker容器可以在计算机上运行，并且在不同的计算机之间移动，从而实现快速、可靠的应用部署。Docker容器自身具有独立性，可以在没有任何特殊环境设置的情况下运行，并且每个Docker容器都可以拥有自己的网络端口和IP地址。

相比之下，K8S是一个容器编排平台，它能够管理多个Docker容器，并将它们组合成一个整体。K8s提供了一种动态管理Docker容器的方法，可以将它们平衡分配到集群中的不同节点上，并自动部署、升级和伸缩应用程序。

Docker容器的开发和部署非常简单，但是对于多容器应用程序，需要手动编写启动、停止脚本以及实现容器间的互联互通。而K8s提供了更为高级的部署，升级和伸缩能力，可以自动化完成大量的操作，从而提高了生产力和效率。

Docker和Kubernetes各自的优势

Docker的优势：

①隔离性：Docker容器是相互隔离的，每个容器运行着自己的进程、文件系统和网络接口，从而保证了应用程序容器之前的独立性和安全性。

②可移植性：Docker容器可以在任何地方运行，无需修改，从而实现了在不同的环境中快速分发、部署和移植应用。

③简洁性：Docker容器中仅包含所需的组件和软件包，不像虚拟机需要运行整个操作系统，因此具有更小的存储和内存开销。

④可重复性：Docker容器的构建和部署过程可以自动化，从而保证了应用程序的可重复性和一致性。

Kubernetes的优势：

①可扩展性：K8S可以快速伸缩应用程序，从而应对不同的流量和负载变化，提高生产效率和灵活度。

②健壮性：K8S可以自动进行容器的部署、扩展、更新和滚动回滚，从而使线上应用具有更高的可用性和健壮性。

③自适应性：K8S可以根据资源需求自动部署、迁移和删除容器，从而实现了应用程序的自适应性，避免了资源浪费和性能瓶颈。

④可观察性：K8S提供了丰富的监控和日志记录功能，可以对应用程序和容器进行细粒度的监控和调试。

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。