从集装箱到容器

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

容器也是一种轻量级的隔离技术,在保证文件系统、网络、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。