我们为什么选择Kubernetes

q9989

　　【编者的话】这篇文章介绍了作者在选择容器编排工具过程中的一些总结和经验，各个编排工具的特性比较，以及自己团队为什么选择Kubernetes。
　　几个月前，我开始调研Docker容器的编排工具，例如一些可以帮助我们把docker容器部署到集群中节点上，并能保证容器一直处于运行状态的工具。首先我们来看下为什么需要这些。
Prior Setup
　　在我们移到Kubernetes之前我们也有一套正式的部署流程。我们使用Jenkins实现持续集成，对每一个提交我们都会运行对自身的测试以及与其他系统的集成测试（这些也是基于Docker容器），创建Docker镜像，推送到自己的Docker registry， 部署到测试环境， 然后通过一键就可以把当前的镜像或者老的镜像部署到生成环境。可以参考下面的图：

　　Sever John和Doe都各自包括了一个部署在该节点上的Docker容器集合。我们用Ansible来创建我们的节点，可以通过一个命令就可以创建一个新的云服务器， 在这个服务器里面安装了docker/docker-compose，配置了防火墙规则，安装了更新，邮件通知，New>

　　如果Server Doe在半夜挂了，我们也被叫醒了，但这个服务器上的容器还没有被移到其他的server上，服务必须经过一段时间当机。我们的服务器就像我们的宠物一样， 如果其中一个挂了，我们也会变得不爽。 与此同时还有其他的一些问题，比如一个机器上到底能运行多少个容器呢，怎么实现服务发现，怎样实现版本滚动更新，怎样收集日志，我们需要一些东西来帮我们。就像下面这样：

　　我们想一个具有魔力的编排框架帮我们分配容器到集群中的节点上去，我们想把整个集群看成一个整体，然后告诉这个整体说：“给我部署三个docker 容器实例，并且保证他们一直在运行，谢谢！”。现在我们要做的就是找到这么一个框架。
Wish List
　　这一块因为有大量的供应商以及竞争发展的的确很快。我们觉得这个框架的稳定性比较重要，这样不需要很多的时间去维护，同时我们也希望这个东西可以很方便上手。假如有个东西可以跟我们现在使用的docker-compose很像那就更好了，这样我们也不要重新做很多的配置和安装。还有就是这个框架的魔法性也不能太强，要不然要脱离我们控制了。如果需要的话，一些模块可以被其他的取代那就更好了。开源的项目更好，因为我们可以知道这个项目的发展以及在发展中出现的问题等等。并且如果当前的贡献者不做了，其他人也可以继续他的工作。如果框架还提供多个云平台的集成的功能那就更棒了，框架自身可以被部署在多个云平台上，也可以把容器部署在多个云平台上。另外就是集群中的服务发现了。
Finding a Framework
　　我们调研了下面的这些框架：

• 　　AWS ECS
  
• 　　Docker Swarm
  
• 　　Mesosphere DCOS
  
• 　　Tutum
  
• 　　Kubernetes
  

　　提示：我们是在2015年9-10月做的调研。所以现在可能不是100%准确了
AWS ECS
　　AWS ECS容器服务可以实现高扩展，部署很快， 使用容器管理服务也可以很方便的在Amazon EC2集群上启动，停止，管理Docker容器。如果你已经在使用AWS， 你一定要看一下这个服务。我们没有使用AWS， 但是迁移上去也没有什么麻烦。在AWS上运行容器的确非常的诱人。它的确是一个厉害的，成熟的云平台提供商，在上面还能使用到AWS的其他服务。ECS还会自动把容器分发到多个可用的区域，但是并不是一切都是那么的好玩，在这个服务完全公开发布之前我上去做了一些实验，感觉不是那么的顺畅（考虑到是在测试阶段，这样也是正常的），所以我想再深入的了解一下。我开始阅读他的文档，以及跟其他的产品进行比较，但是仍然让我觉得使用这个服务有点复杂。整个开始文档很长，包括的都是IAM的策略以及安全组，但也是一件好事，这让我在实际使用之前还要做一些其他调研，我需要尝试点其他路径，所以我开始先google资料。突然我发现他不支持服务发现，这就意味着你需要自己去管理和配置这些，还有个就是端口的管理，好像不可以运行多个容器暴露出一个端口出来，这些让我不得不去看看其他的产品（后面我发现了这一篇博客证实了我的想法）。
Docker Swarm
　　Docker Swarm是Docker自身的集群管理工具，因为Docker Swarm用的是标准的Docker API，所以任何已经同Docker deamon交互的工具可以直接使用Docker Swarm把容器分配到多个节点上去，这个听起来不错，我们正好也是在用docker-compose来启动服务的，这意味着我们不需要学太多的新东西，我们已经知道Docker和Swarm使用了Docker标准的API，但是此时我们看到Docker Swarm还没有到1.0版本，这是我们为什么没有选择Docker Swarm最主要的原因。当然还有些其他的事情有点烦人，比如我的前同事告诉我Docker Swarm支持很多种的服务发现引擎，保证这些引擎一直不断的工作有点麻烦。还有就是Docker Swarm不是一个可托管的服务，所以我们必须自己保证这些服务发现引擎的运行。另外与其他同等产品相比， 滚动更新也不是那么容易，至少在当时，你必须要自己实现在Swarm里面的滚动更新，例如在一组容器前面设置Nginx作为负载均衡器。这个时候还有一些担心Swarm的设计可能还有点缺陷，例如在stackoverflow上面一个Google的工程师就说到：

从跟本上说，以我们在谷歌以及其他地方的一些经验来说节点的api作为集群的api是不够的。

Mesosphere DCOS

　　我们使用模板在AWS上启动一个DCOS（数据中心操作系统），登录到界面之后你会发现界面非常的棒。你能看到你的集群中有多少服务，以及他们使用的cpu和memory有多少，DCOS可以在任何云上面运行也可以跨多个云工作（我们没有验证过这个，因为这个需要企业级版本）。他是基于Mesos构建的，而Mesos已经被证明可以运行大规模集群。DCOS也有很多的特性，他不仅仅可以运行容器，也可以运行一个独立的app（比如Ruby），它还有个内部事件总线可以获得所有的被负载均衡使用的API请求，以及扩展事件，它另外还有Metric可以支持Graphite和Data dog（使用的是 [codehale metrics](http://codehale metrics)格式），另外还包括集群的自动扩展（使用宿主机的自动扩展功能实现），这里还有很多其他的功能。让我们非常感兴趣的是DOCS可以让你相同的集群里面运行多个框架，这就意味着你可以同时运行Marathon，Kubernets， Docker Swarm。 在安全方面，他提供了三个不同的“安全地带”：admin，private，public，可以让你在不同的安全级别部署你的应用，比如private zone不可以从internet来访问。另外一个非常cool的功能是你可以通过运行一个简单的命令来安装服务，比如：“dcos install … ”，你可以把他认为你的数据中心的apt-get， 可以在几分钟之内安装出一个高可用的HDFS集群，像Cassandra、Spark、Storm、CrateDB等这些服务也是可以安装。服务发现是由HAProxy来实现的，可以自动自动加载配置文件从而发现一个服务的创建和删除。它还支持滚动更新（在DCOS里面被称之为滚动重启— rolling restart），可以实现无当机工作（我没有测试过这个）。最后，但并不是最重要的一点，它支持Chronos项目，可以让你在集群中运行分布式的任务（就像分布式的cron job）。我非常想去试一下Mesosphere DCOS，但是它也有很多的限制，准确的说虽然称不上是一个限制，只有企业版才有跨多个云平台的能力这也是可以理解的。并且它也不是一个托管的服务，虽然很容易去构建一个集群，但是也需要自己去管理这些服务，作为免费版本来说这也是正常的。我曾经也去问过Mesosphere企业版的价格，但是让我失望的是并没有得到回复，但是一开始我们知道这个就好了，利用dcos install安装服务虽然很简便，但是大都还是处在初期或者测试版本，所以也不推荐使用与生产环境。另外一个让我们担忧的事情就是如何实现无当机的升级，读完文档之后说是使用ETL，好吧，那我是不是应该说声谢谢？如果我们没有运行有状态的服务，那么升级将是比较容易的（启动一个新版本的DCOS， 在它启动后把ELB切换到新的DCOS上），但是对于DCOS来说，他的意义就是在于运行有状态的服务，比如Hadoop、hdfs等等。如果我们不能够很容易升级集群到一个新的版本，我们也就没办法保持一个最新的release。我到他们的slack上面去问了这方便的事情，他们说正在实现这个功能，但是还没有完成。
　　非常遗憾，我只能说现在Mesosphere DCOS并不适合于我们，或许几年之后上面的服务或框架会更完善和成熟，Mesosphere DCOS会变得很厉害。但是恕我之言，现在他还不行，至少是在我看他的这个时候。
Tutum
　　Tutum描述自己是为DevOps而生的Docker平台，他的标语是：“构建, 部署，跨平台管理应用”， UI长的下面的这个样子：

　　虽然看起来不像DCOS那样好，但是你可以在Tutum的界面上做很多的事情。为了使用Tutum，你需要在各个节点上安装agent，从而加入集群，这个非常的容易，然后这个node就是出现在UI上，就可以使用了。让我们特别感兴趣的是它使用了跟docker-compose类似的格式来申明一个服务栈（多个服务或容器的组合），这意味着我们不需要修改太多的东西。其对Flocker也有非常好的支持，我们做了一些测试，删除了一些有状态的容器，他能在其他的节点上完整的将他们启动起来，我对此印象非常的深刻。另外一个特性就是服务链接（service link），可以让我们在容器之间创建连接，从而这些容器只会被暴露给组中的其他容器，如果我没有理解错的话，这个链接可以跨多个节点。Tutum也是使用HAProxy作为负载均衡，它支持虚拟主机，所以你可以在相同的HAProxy实例后面部署多个服务，也非常容易暴露这样的负载均衡到internet。，Tutum也有能力把服务部署到多节点上，从而实现HA，Tutum也可以把服务运行在每个节点（Every Node）上，Every Node是非常有意思的，如果你想保证服务或守护进程是被运行在每一个节点上，你可以使用这个功能。他们也在集群中提供了一键docker升级的功能。最后还不得不说他们提供了很好的support，即便我不是一个付费的用户，但是他们回答我的问题还是非常及时和积极的。再进一步了解的时候发现Tutum已经被Docker收购了，将成为docker生态圈中的一个核心产品。但是Tutum还是很多事情并不完美，首先它还是个测试版本，并且价格还没有定（今天价格显示为15刀每个节点），这让我们很难知道当它不在是测试版的时候我们是否能负担的了。但是让我们惊讶的是当一个node挂掉的时候，上面的容器并没有移动到可用的节点上去，我跟技术支持说了这个事情，他们说已经意识到这个问题了，会在将来解决这个问题。不幸的是我们要使用这个用来生产，所以这一点对我们来说非常重要。我有提到说是不是可以通过限制资源来解决那个问题，但是他们还没有实现这个功能。
　　我们一度非常接近使用Tutum，但是因为它没办法在主机快挂了的时候把我们的服务移动到其他可用的节点上，我们不得不看看其他平台。
Kubernetes
　　Kubernetes描述自己是：“把一个Linux容器集群当做一个系统来管理，以加速开发和简化运维”。Kubernetes是一个开源的项目，是由Google发起的，但是很多其他公司，诸如Red Hat、Microsoft、 SaltStack、Docker、CoreOS、Mesosphere、IBM也参与到这个项目上面。对于Kubernetes，非常棒的是，Google把他们数十年的运行和构建集群的经验免费的贡献了出来。你可以在bare metal上面运行Kubernetes，也可以在cloud provider上面运行Kubernetes。Google自己也提供了可托管的Kubernetes版本Google Container Engine服务，所以我们决定去试试Google Container Engine，尽管没有Tutum那么容易上手（更多是因为不能从UI上控制），一旦我理解了概念之后，就觉得非常的可靠。那时候Kubernetes已经是1.0了，现在是1.1，是可以考虑用于生产的。我们做了很多测试，比如在做滚动升级的过程中杀掉一些节点，随机的杀掉一些容器，扩展容器等等。尽管并不是每一件事都很完美，但是我们能够找到一些方法来解决问题。一个大大的好处就是可以实现无当机滚动升级，他在我们的测试中表现的非常好。服务发现也是Kubernetes的一部分，在使用服务发现的过程中我们还没有遇到什么问题，在集群里只要连接到服务名字(http://my-service)，Kubernetes就能够保证让你同service后面的pod通信。Kubernetes本身被设计的就具有模块化和可扩展性，所以他的组件可以很容易扩展。他有很多其他的特性：例如： resource limits、volume claims、secrets、service accounts等等。另外一个很棒的特性就是Kubernetes同时支持Docker和Rocket容器。Kubernetes很明显也有它的弊端，当使用Google Container Engine的时候，你会被限制只是在一个数据中心，如果这个数据中心挂了，那你的服务也就挂了，当然，也有解决办法，就是负载均衡后面使用多个集群，但是Kubernetes对这个不提供原生支持，我已经与Google的工程师说了这个事情，如果我理解正确的话，一个轻量级服务Ubernetes将在1.2里面发布，这将允许在跨多个数据中心部署应用。Kubernetes是用自己的YAML格式来描述pods, services以及其他资源，这就意味着我们要对docker-compose的描述文件进行转化了。与Mesos相比，Kubernetes并不是那么成熟，也不能应对那么多的节点，因为目前位置Kubernetes说可以支持250个节点，但是Mesos可以支持到1000个节点。还有就是Kubernetes的UI还有很多的事情要完成。
结束语
　　在最后我们说到Kubernetes，它是我们试过的最稳定的解决方案（我们在Google Container Engine做个尝试），我对他能支持我们以后的成长很有信心，这并不是说其他服务就不好，就像我之前说的，这个领域发展的太快，说不定我现在说的已经过时了。我还会一直关注Mesosphere DCOS的发展，因为它看起来真的很有前途，但是到目前我们用Kubernetes还是很开心的，并且我们已经使用它生产好几个月了，但这并不意味着它没有问题，我会在后面继续更新我使用kubernetes的感受和遇到的问题，以及如何去解决这些问题。
　　原文链接：Why We Chose Kubernetes （翻译：左伟 ）
　　＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
　　译者介绍
　　左伟，就职于IBM，软件工程师，现从事于DevOps，云计算相关的研究，实现和推广