Introduction

虚拟化与编排

虚拟机

虚拟机由某些特定的硬件和内核虚拟化组成,运行客户操作系统。称为管理程序的软件创建虚拟化硬件,其可以包括虚拟磁盘,虚拟网络接口,虚拟 CPU 等。虚拟机还包括可以与此虚拟硬件通信的宾客内核。管理程序可以托管,这意味着它是一些在主机操作系统(MacOS)上运行的软件,如示例中所示。它也可以是裸机,直接在机器硬件上运行(替换你的操作系统)。无论哪种方式,管理程序方法都被认为是重量级的,因为它需要虚拟化多个部分(如果不是全部硬件和内核)。

VM 需要硬件虚拟化才能实现机器级隔离,而容器则只需要在同一操作系统内进行隔离操作。 随着隔离空间数量的增加,开销差异变得非常明显。

容器

在过去几年里,云平台发展迅速,但其中困扰运维工程师最多的,是需要为各种迥异的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度,但仍然不能从根本上解决环境的问题。

Docker 的出现成为了软件开发行业新的分水岭,容器技术的成熟也标志着技术新纪元的开启。Docker 提供了让开发工程师可以将应用和依赖封装到一个可移植的容器中的能力,这项举措使得 Docker 大有席卷整个软件行业并且进而改变行业游戏规则的趋势,这像极了当年智能手机刚出现时的场景——改变了整个手机行业的游戏规则。Docker 通过集装箱式的封装方式,让开发工程师和运维工程师都能够以 Docker 所提供的镜像分发的标准化方式发布应用,使得异构语言不再是捆绑团队的枷锁。

容器是包含应用程序代码,配置和依赖关系的软件包,可提供运营效率和生产力。在这里,您可以确切地知道它将如何运行,这意味着它是可预测的,可重复的和不可变的。容器的兴起是 DevOps 即服务的一个巨大推动因素,可以克服当今面临的最大安全障碍。容器化通过在操作系统级别进行虚拟化来使应用程序可移植,从而创建基于内核的隔离的封装系统。容器化的应用程序可以放在任何地方,无需依赖项运行或需要整个 VM,从而消除了依赖关系。

容器可作为一个独立的单元,可以在任何支持它的地方运行。在每个实例中,容器本身都是完全相同的。如果主机操作系统是 CentOS,Ubuntu,MacOS,甚至是像 Windows 这样的非 UNIX 系统都无关紧要——从容器内部看操作系统将是容器指定的任何操作系统。容器还充当标准化的工作或计算单元。一个常见的范例是每个容器运行单个 Web 服务器,数据库的单个分片或单个 Spark 工作程序等。然后,为了扩展应用程序,你只需要扩展容器的数量。

每个容器都有一个固定的资源配置(CPU,RAM,线程数等),并且扩展应用程序需要只扩展容器的数量而不是单个资源原语。当应用程序需要按比例放大或缩小时,这为工程师提供了更容易的抽象。容器也是实现微服务架构的一个很好的工具,每个微服务只是一组协作容器。例如,可以使用单个主容器和多个从容器来实现 Redis 微服务。

Linux cgroups 为一种名为 Linux 容器(LXC)的技术铺平了道路。 LXC 实际上是我们今天所知的第一个实现容器的主要实现,利用 cgroup 和命名空间隔离来创建具有独立进程和网络空间的虚拟环境。从某种意义上说,这允许独立和隔离的用户空间。 容器的概念直接来自 LXC。 事实上,早期版本的 Docker 直接构建在 LXC 之上。

编排

随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多地提及。IaaS、PaaS 和 SaaS 是云计算的三种基本服务类型,分别表示关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务,以及关注业务应用的软件即服务。容器的出现,使原有的基于虚拟机的云主机应用,彻底转变为更加灵活和轻量的“容器+编排调度”的云平台应用。

容器单元越来越散落使得管理成本逐渐上升,大家对容器编排工具的需求前所未有的强烈,Kubernetes、Mesos、Swarm 等为云原生应用提供了强有力的编排和调度能力,它们是云平台上的分布式操作系统。容器编排是通常可以部署多个容器以通过自动化实现应用程序的过程。像 Kubernetes 和 Docker Swarm 这样的容器管理和容器编排引擎,使用户能够指导容器部署并自动执行更新,运行状况监视和故障转移过程。

容器单元越来越散落使得管理成本逐渐上升,大家对容器编排工具的需求前所未有的强烈,Kubernetes、Mesos、Swarm 等为云原生应用提供了强有力的编排和调度能力,它们是云平台上的分布式操作系统。

Kubernetes 是目前世界范围内关注度最高的开源项目,它是一个出色的容器编排系统,用于提供一站式服务。Kubernetes 出身于互联网行业巨头——Google,它借鉴了由上百位工程师花费十多年时间打造的 Borg 系统的理念,安装极其简易,网络层对接方式十分灵活。

Mesos 则更善于构建一个可靠的平台,用来运行多任务关键工作负载,包括 Docker 容器、遗留应用程序(如 Java)和分布式数据服务(如 Spark、Kafka、Cassandra、Elastic)。Mesos 采用两级调度的架构,开发人员可以很方便地结合公司的业务场景定制 Mesos Framework。

其实无论是 Kubernetes 还是 Mesos,它们都不是专门为了容器而开发的。Mesos 早于 Docker 出现,而 Kubernetes 的前身 Borg 更是早已出现,它们都是基于解除资源与应用程序本身的耦合限制而开发的。运行于容器中的应用,其轻量级的特性恰好能够与编排调度系统完美结合。

唯一为了 Docker 而生的编排系统是 Swarm,它由 Docker 所在的 Moby 公司出品,用于编排基于 Docker 的容器实例。不同于 Kubernetes 和 Mesos,Swarm 是面向 Docker 容器的,相较于 Kubernetes 面向云原生 PaaS 平台,以及 Mesos 面向“大数据+编排调度”平台,Swarm 显得功能单一。在容器技术本身已不是重点的今天,编排能力和生态规划均略逊一筹的 Swarm 已经跟不上前两者的脚步。

Kubernetes 和 Mesos 的出色表现给行业中各类工程师的工作模式带来了颠覆性的改变。他们再也不用像照顾宠物那样精心地“照顾”每一台服务器,当服务器出现问题时,只要将其换掉即可。业务开发工程师不必再过分关注非功能需求,只需专注自己的业务领域即可。而中间件开发工程师则需要开发出健壮的云原生中间件,用来连接业务应用与云平台。

链接