从集装箱到容器

容器化是一种全新的交付方式，它把应用及运行环境，整体打包成一个的镜像，从而保证了运行环境的统一。

容器也是一种轻量级的隔离技术，在保证文件系统、网络、CPU等基础隔离的基础上，拥有更快的启动速度，更小的资源开销。

还记得我们在第一章指出的微服务缺点么？运维难度、上线速度。这些都可以通过容器 / 容器编排技术得到管理。可以说，微服务架构的落地，离不开容器技术。

从集装箱革命到运维革命

这是著名的容器开源项目Docker的logo：

以

你有没有注意到蓝色鲸鱼背上的东西呢？

没错，是集装箱。

尽管货物的海运已经出现了几百年，但直到20世纪中叶，货物运输依然是一种劳动力密集型工作。码头雇佣了数以万计的工人，将货物从岸上搬运到船舱中。由于货物的种类繁多，体积不一、传送带、铲车都不能根本的解决问题，货物装卸依然大量依赖人工，而且装卸时间大量占用了港口时间，装卸价格居高不下。

20世纪50年代开始，集装箱逐渐走向商用的舞台。货物在岸上按照整齐的规格码放整齐，从而可以封装进集装箱。而装卸货物只需要机械来搬运集装箱即可，极大提高了港口的装卸效率。

集装箱革命使得货物的装卸成本从5美元/吨骤降到16美分/吨，节约了97%……

而以docker为代表的容器化项目的崛起，也推进了运维圈的另一场“革命”：容器就是集装箱，货物则是运行于容器中的，各式应用。

容器技术的出现，根本性的解决了如下的技术难题：

  • 运行环境的标准化：为了让应用程序在生产机上跑起来，经常安装不同操作系统版本，不同版本的依赖软件库、环境配置……这些过程非常繁琐，还经常会由于版本的细微差异，和开发环境不一致，出现“这个程序本地好好的，放到服务器上就崩溃”这类情况。容器可以使用统一的描述语言(如Dockerfile)，快速构建出完全相同的、标准化环境，从而解决运行环境的问题。

  • 隔离化：如果都部署在一台物理机上，很可能会发生包、依赖冲突，导致无法运维，而容器可以为运行在同一台物理机上的应用程序，创建不同的隔离环境(文件系统、网络、物理资源等)。

docker是最成功的容器化项目之一，但并不是唯一的选项，这里列举几个强有力的竞争者：

  • rkt container：由RedHat主导的容器化项目，改进了Docker隔离模型的许多缺陷，具有更好的安全性能。

  • kata container：轻量级的定制化虚拟机(VM)，具有比肩容器化的技术，以及VM级别的隔离性。

从容器到容器编排

容器解决了运行环境标准化、隔离化的问题，但随着容器数量的不断提升增长，如何管理他们成为了一个新问题。

容器编排指的是：自动化容器的部署、管理、扩展和联网。

除了规模化，容器编排还面临以下问题：

它解决了以下问题：

  • 应用不是孤立的，容器的运行也会有依赖关系，如何进行管理？

  • 如何在不影响业务运行的前提下，升级容器（内的应用）？

  • 如何在容器应用挂掉的时候，自动恢复故障？

  • 如何管理容器的本地存储？

如今，Kubernetes已经成为容器编排领域的事实标准，它的特性有：

  • 滚动升级、回滚：支持渐进式的升级应用镜像版本，并可轻松地回滚到之前的版本。

  • 服务发现、负载均衡：内置了基于DNS / VIP的负载均衡机制。

  • 异构存储：CSI机制，支持云存储、NFS、Ceph等多种方式。

  • 密钥、配置存储：密码、配置等信息的存储。

  • 灵活的资源分配：支持多种资源保证方式，最大限度利用资源。

  • 批量任务：支持后台离线、批量任务。

  • 水平自动扩展：快速扩所容能力，支持人工 / 负载自适应

  • 健康、恢复：内置多种健康检查、自恢复机制

  • 拓展性：提供了多个扩展点，在不改变k8s代码的前提下，轻松拓展功能

纸上得来终觉浅，简单的介绍是远不够的。

在下一节，我们将使用一个例子，快速入门Kubernetes。