dockerSwarm

Docker compose 、Swarm真的很不好用。k8s不难，只是需要学习的概念很多，不过，一旦你理解了那些概念，k8s将是一个简单的、稳定的、专业的容器编排工具。

Swarm对于中型业务，简单高效成本低，符合短平快的开发模式，而这种模式，开发人员并不需要服务提供商提供太多服务,k8s比较占用资源，搭建运维成本过高。

docker

namespace是kernel的，cgroup也是kernel的，docker家自己没有任何技术门槛。

Docker创新的是镜像，镜像构建方式;镜像，之前类似的技术很多，但都没能解决环境很麻烦的痛点.

docker的底层是containerd+runc，这些都是开放的标准，包括oci image spec和oci runtime spec。所以就基础功能，直接通过cri使用containerd或docker shim使用docker，并没有很大区别。

kubernetes直接对接containerd，其实更加合理。

为什么我们需要Docker？

在Docker容器技术出现之前，我们开发、测试、发布服务需要多个环境，开发环境用于开发人员写代码、调试、自测，测试环境用于测试人员进行功能测试、性能测试，生产环境用于发布正式版本，给用户使用。

首先需要一台服务器，然后在服务器上安装 Web Server （例如：Nginx 或者 Apache Server）。接着，根据应用的运行时要求，安装对应的软件包（例如：如果代码是用 Node.js 编写，就需要安装 Node.js 运行时环境）。最后，根据应用的其他功能，安装对应的软件，如数据库之类的。

现代服务器性能非常强悍，如果一台主机上仅运行几个程序，就可能造成机器资源利用率偏低。而且，由于程序是直接运行在宿主机上的，程序之间存在资源竞争关系，会互相影响。如果某个程序造成宿主机卡顿或挂掉，那么其他程序也无法正常工作了。

在 2013 年出现 Docker 容器技术之后，这种部署方式逐渐被淘汰了。

在我们从开发到上线的过程中，都在和环境打交道，在装环境之前还得先申请资源，安装操作系统、数据库、应用程序，并修改配置文件链接起来，这个过程是非常繁琐的，每次修改内容都还得重新部署一次，如果换个机器，不好意思，那就还得再来一轮。

Docker的出现解放了这个过程。Docker将应用运行的一整套环境，包括操作系统、数据库、消息队列等全都封装成镜像，研发人员可以在封装的镜像上面继续封装业务模块，交付给测试和运维人员。测试开展测试工作时，只聚焦于业务就好，由于环境不同带来的问题已经不存在了。并且Docker容器之间是进程隔离的，在利用好服务器资源的同时，谁也不会影响到谁。这也是为什么阿里、头条、美团等互联网巨头都纷纷把基础设施容器化的原因。

docker

Docker 方式运行的容器，可以理解为一个虚拟机（但和虚拟机还是有区别的，虚拟机是对硬件的虚拟化；Docker 是操作系统层的虚拟化）。它包含了运行程序所需的运行时环境和程序代码，启动后能够以端口映射的方式，将容器自身的服务暴露给宿主机和外部用户。

容器之间除了彼此隔离之外，也能够通过 Docker 引擎实现互联。容器之间的访问通常是以内部 IP 的方式进行的。

随着 web 应用规模的继续扩大，单主机不再能满足性能要求。现在的部署是基于多主机、多容器进行的,此时用到k8s。