k8s为啥不建议用docker了,k8s放弃支持docker

2. Docker和k8s(Kubernetes)有什么关系

首先看看k8s[中间8个字母，数过了(逃](Kubernetes)是什么以及为啥会出现这个东西。

总的来说，k8s的出现和使用容器进行部署的趋势是分不开的。

总的来说，app的部署大致分为三个阶段。

最传统的方式中，所有app公用一个物理系统，这种方式会造成很多资源分配上的冲突。

而后进入了虚拟机部署的时代，各个app运行在其自己的VM上，允许一个物理服务器上运行多个系统，并提供了一定的安全级别（各个VM相互隔离）。

现如今，更流行使用容器进行部署。容器类似于 VM（见前文详细比较），但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。

在使用容器进行app部署的今天，需要一个平台对容器进行管理：

通俗一点，我理解的k8s就是对容器进行管理的工具。其中提供的很多功能能够提升部署的鲁棒性以及整体的运行效率：

至此，Docker和k8s的关系也就明了了：

Docker隔离并打包applications及依赖项。

Kubernetes部署协调管理容器，并提供一些其他的相关功能。

k8s为啥不建议用docker了？

因为社区认为Containerd 作为 Kubernetes 的容器运行时目前已经足够成熟，无需再通过 dockershim 使用 Docker 作为 Kubernetes 的容器运行时。

这也标志着 Docker 为 Kubernetes 提供一个现代化的容器运行时的承诺最终兑现了。

在 Kubernetes 提出 CRI 时，有人建议在 Docker 中实现它。但是这种方式也会带来一个问题，即使 Docker 实现了 CRI，但它仍然不是一个单纯的容器运行时，它本身包含了大量的非 “纯底层容器运行时” 所具备的功能。

Docker一问世就广受好评，发展迅速，于是在2015年左右，不满足只做容器引擎的Docker开始尝试提供容器编排能力，对单机场景推出了Docker Compose，对集群场景推出了Docker Swarm。

也就在同年，Google推出了同样具备容器编排能力的Kubernetes，并在与Docker Swarm和Apache Mesos的三方大战中大获全胜。于是在之后的一段时间里形成了“集群容器编排用Kubernetes，单机容器引擎用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 Swarm？

用过就知道了K8s比Docker Swarm还是要强一些些的……k8s api简直不要太好用……

docker和k8s的关系

概念：

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

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

docker一般是和传统的虚拟技术对比

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

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

K8s:每个集群有多个节点，每个节点可创建多个容器，kuberbete就是管理这些应用程序所在的小运行环境（container）而生。

在一般的认知中，Kubernetes 和 Docker 是互补关系：

Docker 源于 Linux Container，可以将一台机器的资源分成 N 份容器，做到资源的隔离，并将可运行的程序定义为标准的 docker image；Kubernetes 则可以把不同机器的每份容器进行编排、调度，组成分布式系统。

近几年，Kubernetes 已经成为自有机房、云上广泛使用的容器编排方案，最广泛的使用方式是 Kubernetes+Docker。从 DevOps 人员的角度，一面用 kubectl 命令、k8s API 来操作集群，一面在单机用 docker 命令来管理镜像、运行镜像。

单独用 docker 的情况，在一些公司的场景里面也是有的。一种场景是“只分不合”，把一台机器用 docker 做资源隔离，但是不需要将多容器“编排”。

[1]

[2]

[3]

[4]