本文选自 Google Cloud Platform Blog，是一个主要介绍容器技术的系列博客的开篇。文中通过对容器技术和kubernetes的大致介绍，阐述了容器技术的优势及Google对于容器技术的理解。基于单台服务器(如阿里云服务器)的容器虚拟化技术可为测试和部署提供方便，但在生产环境中，客户往往面对的是整个集群的资源。Google的kubernetes产品为容器的集群化部署和管理提供了解决方案，kubernetes从另一个角度对资源进行了抽象，把每一个服务当作一个整体来对待。作者认为容器技术仅仅是当前计算模型演变的一个开端，而Google将会在这场新的技术革命中扮演重要的角色。

　　各位好!欢迎来到我们新的系列博客，在这个系列中，我们将要为大家介绍当今计算模型创新中最时髦的领域之一：容器化技术(containerization)。

　　你也许会有很多疑惑：容器到底是什么，它究竟怎样工作?Docker、Kubernetes到底指的是什么，Google Container Engine及Managed VM又有什么用?它们之间有什么关联，我们怎样通过容器来构建一个功能强大的服务，并且能让它们在生产环境的大规模集群中使用? 用户采用这种技术，怎样才能获得商业价值?好了，我们不再卖关子，接下来就直入主题。我们首先会对容器技术进行具体的介绍，之后讲述容器技术究竟怎样使我们更好地进行工作。

　　随着计算模型(computing models)的不断发展衍化，我们曾经经历过几次计算模型解决方案的转变。回顾在过去的10年，我们从虚拟化技术的角度可很清楚看到这种变化的过程。受益于虚拟化技术的发展，我们对整体资源的使用效率有了巨大的提升，与此同时，我们工作的时间价值和为了交付服务所做的重复性工作得到了相应减少。随着多租户、基于API的管理及公有云(如阿里云)计算技术的到来，这一趋势更是被不断加强。这其中，最关键的突破就是资源使用方式所发生的变化。通过虚拟化的方式，我们可以在几分钟之内，虚拟出一个小的、独立的、随需随用CPU内核，这个虚拟的CPU内核感觉像是直接运行在物理机之外。那么问题来了，当你仅仅需使用一小部分资源时，是不是还有必要虚拟出一整台机器?

　　Google在很早时就已遇到了这个问题：我们需要更快、更便宜的方式发布软件，并且支撑服务运行所需要的计算资源的规模也以前从未有过的，那么这一问题应该怎样解决?为了满足这一需求，我们需对已有资源进行更高级别的抽象，使得服务可通过更细的粒度对资源进行控制。为此，我们为Linux内核添加了新的技术，这便是众所周知的cgroup，我们通过这一技术来对服务运行时环境进行隔离，这种被隔离起来的运行时环境就被称为容器。这是一种新的虚拟化技术，通过这一技术，我们简化了Google全部服务运行所需要的底层OS环境。之后的几年一直到现在，容器相关的技术不断发展，随着Docker的出现，这一技术的影响得到了进一步扩大，Docker也正是通过使用这一技术为基于容器的应用创建了一种可互操作的格式(interoperable format)。

　　为何使用容器?

　　容器技术究竟提供了哪些虚拟机所没有的?

　　简化部署(Simple deployment)：容器技术可将你的应用打包成单一地址访问的、registry存储的(registry-stored)、仅通过一行命令既可部署完成的组件。不论你想将服务部署在哪里，容器都可从根本上简化你的服务部署工作。

　　快速可用(Rapid availability)：容器技术对操作系统的资源进行再次抽象，而并非对整个物理机资源进虚拟化，通过这种方式，打包好的服务可以在1/20秒的时间内启动，相比之下，也许需要一分钟的时间才能启动一台虚拟机。

　　微服务化(Leverage microservices)：容器可允许开发者和系统管理人员对计算资源进行进一步细分，若一个小型的虚拟机所提供的资源相对于服务运行所需要的资源来说过于庞大，或对于你的系统而言，一次性地扩展出一台虚拟机会需要很多的工作量，那么容器也许会很好的改善这一状况。

　　容器技术的这些优点能为你的工作带来哪些帮助?

　　最明显的一个方面就是：开发者只需通过他们的笔记本电脑就能同时运行多个容器，并进行方便快速的服务部署。虽然在一台笔记本电脑上运行多个虚拟机也是可以的，但显然通过容器的方式可以更快速、简单、轻量级。

　　不仅如此，容器还可使得服务发行版的管理变得更加容易，发布一个新的容器版本仅仅需一个单独的命令就能完成。同时，测试工作也变得更加容易，在公有云(如阿里云)平台中，虚拟机的计费方式可能至少以10分钟为单位(或者，一整个小时?)，若仅运行单个测试程序，由于测试所消费的资源可能并不多。但若你每天要运行上千个测试驱动导向的程序，资源成本就可能直线上升。若改用容器进行同样的测试工作，你只需用同样的资源消耗(与使用一台虚拟机相同的资源消耗)来完成这上千个测试，这将会大大节省你的服务运行成本。

　　另外一个重要的优势就是组合特性，采用容器的方式进行部署，整个系统会变得易于组合，特别是对于那些需要使用到开源软件的系统。对于系统管理人员，以下的工作可能会使人望而却步：安装和配置MySQL、GlusterFS、Memcatched、Hadoop、RabbitMQ、Node.js、MongoDB、Nginx等等，之后再将这些软件封装起来，为服务提供一个运行平台。然而，这些复杂的工作完全可通过启动几个容器来完成：先将这些服务封装在对应的容器中，之后结合一些脚本使这些容器按照要求相互协作，这样操作不仅可简化部署难度还可以降低操作风险。

　　若你想按照前面所描述的过程构建一个服务平台，也许会有许多容易出错的地方，整个配制过程也需要具备很专业的知识， 中间可能还会有许多重复的劳动。因此，我们可以先将核心的容器组件以规范的方式来实现，之后将它们添加在公共的registry服务中。这样其他用户就可以通过registry服务随时获得所需要的容器，拥有高质量组件的容器生态系统就这样被构建起来。

　　在相当长的一段时间内，容器技术最重要的价值就是为不同的主机上运行服务提供一个轻便的、一致的格式。例如，如果你今天要构建一个服务，你可能先要接入裸机服务器，并且使用虚拟化之后的预先定义好的基础设施，或者直接使用共有或者私有的云服务平台，当然也有许多PaaS提供商可以供你选择。然而，你为了使自己服务能够运行在不同的服务平台上，可能需要通过多种不通的方式对服务进行打包!而如果通过在容器格式进行标准化的操作，这些不同的计算模型的提供商们就可以给用户提供一种独特的交付体验，这可以允许用户方便地对工作负载地进行迁移，用户可以选择将工作任务部署在最便宜和最快的平台上，避免局限于单一的平台提供商。

　　Container Engine

　　Google Container Engine在Google的云平台上引入了“容器即服务”的理念。基于Kubernetes的技术，容器引擎为开发者提供了快速构建和运行容器的方法，此外，容器引擎还可以对容器进行部署、管理、并且使容器按着设定的边界进行扩展。在接下来的文章中我们会对容器引擎进行更多的介绍。

　　Deployment options

　　我们可以看到，容器化技术已经成为了计算模型演化的一个开端，Google在这场技术革命中扮演重着要的角色。随着读者开始逐渐接触容器，并对容器部署方式了解不断深入，在实际服务部署中，可以对下面几种方式进行调研，并从中选出最适合的一种：

　　若你打算运行一个被管理的集群或者启动几十个容器，使用Google Container Engine试一试。如果你想要在共有的基础设施上或者是自己的系统中构建自己的集群，可以使用Kubernetes来操作。想要在已经被管理好的基础设施上运行一个容器，可以尝试使用Google App Engine或者是Managed VMs。

　　最后，我们要说明的是，我们对你的使用容器技术的经历，对容器技术的需求以及想法(甚至你在github中提出的每个请求)都很感兴趣。不要犹豫，请联系我们，我们会尽所能举办尽量多的会议和Meetup。我们期望能与你联系。让我们一起讨论关于容器技术如何给你的工作带来改变。期待与你交流!

　　Kubernetes

　　Google通过产品的不断迭代解决了这个问题：我们构建了一个管理系统，它可以用来管理集群、网络以及命名系统。这个管理系统的第一个版本被称为Brog，它的后续的版本称为Omega。通过这个管理系统，我们可以在Google的大规模的集群资源上使用容器技术。我们现在每秒会启动大约7000个容器，每周可能会超过20亿个容器。我们利用Google在容器技术上的实践经验和技术积累，构建了Kubernetes(在论坛上有些时候被简写为K8s)。

　　Kubernetes从另一个角度对资源进行抽象，它让开发人员和管理人员共同着眼于服务的行为和性能的提升，而不是仅仅关注对单一的组件或者是基础资源。那么Kubernetes集群到底提供了哪些单一容器所没有功能?它主要关注的是对服务级别的控制而并非仅仅是对容器级别的控制，Kubernetes提供了一种“机智”的管理方式，它将服务看成一个整体。在Kubernete的解决方案中，一个服务甚至可以自我扩展，自我诊断，并且容易升级。例如，在Google中，我们使用机器学习技术来保证每个运行的服务的当前状态都是最高效的。

　　若说单一容器能够帮助开发者减少部署工作的繁琐，那么Kubernetes就可以最大化的减少团队开发过程中协同工作的复杂性。Kubernets可以让团队以容器的方式将服务结合在一起，并且让这些容器按照指定的规则来进行部署，以确保服务能够正确运行。在传统的方式下，由于缺乏隔离性，服务之间或服务之间的各个部分很容易产生相互干扰，但是通过Kubernetes，这些矛盾可以从系统的角度上被避免，在Google，通过使用这种增强的协同工作的方式，开发者的生产力得以提高，服务的可用性也进一步增强，这也使得在大规模的集群上的部署变得更加敏捷。

　　然而我们的技术仍然处于早期的发展阶段。目前，Kubernetes已经被许多客户和公司的知名团队所采用，包括RedHat ，VMware，CoreOS，以及Mesosphere 等等。这些公司迫切地希望通过Kubernete进行的规模化部署来帮助他们的客户提取出容器技术的商业价值。

　　Docker

　　网上已经有很多的对于容器技术和Docker相关技术如何实现的细致的介绍文档，特别是这里、这里和这里。这些文档已经足够能说明，Docker是一个“很棒的解决方案”，也就是说，目前可能还没有其它方案能够和它相媲美。

　　容器技术增强了对资源控制的粒度，这一点确实有很高的实用价值，但是对于那些需要上千台服务器一起来运行的服务而言，单纯的容器技术并没有从本质上提高任何工作负载的运行效率。如今的Docker仅仅是为了在单一的机器操作而设计，于是我们又可以提出一连串的问题：这些在集群上所运行的容器和容器中运行的工作负载应该被如何分配和协调，它们怎样才能按照资源的消耗量来进行管理?它们如何在多租户的网络环境下进行运行?它们的安全性能又该如何被保证?

　　或许从系统设计的角度来看，我们可以提出一个更本质的问题：当前我们所讨论的到底是不是正确的资源抽象方式?与我交流过的大多数开发者以及公司的赞助商，他们对在指定的机器上的指定容器并不感兴趣，他们真正想要自己的服务如何能被启动运行，产生价值，并且易于监管和维护，他们并不想了解全部的琐碎细节(至少他们希望这样)，例如指定个机器上的指定个容器到底在做什么。

　　博文出处：http://dockerone.com/article/140