中国IDC圈1月13日报道，为了降低成本、改善可伸缩性，大部分组织都搬迁到了AWS上。但通过搬到AWS上，至少有一家公司发现这既能节省成本、改进控制，还能维持一个健壮的服务器基础设施。在旧金山举行的KubeCon大会上，Vonli的CTO Paolo Kinney解释了他们在自动化Kubernetes基础设施来促进这一过程中所学到的东西。

Vinli是个车联网平台，能把数据从联网的智能汽车上传到云端。该公司让开发者可以通过一组API来访问这一数据，从而简化了为消费者创建应用的过程。开发者可以利用低级的遥测API以及安全、旅行、汽车分析以及行为服务等方面的高级API。

Kinney说Vinli决定用托管于Docker容器的微服务来部署整个后端基础设施以便进行定制化。所有的后端逻辑和前端模块都是基于容器发布的。因此该公司每天都要在自己的基础设施上加载和卸载数百个Docker镜像。

从AWS撤走

他们的微服务架构原来是部署在AWS Elastic Beanstalk上的。它运转得很好，但Kinney说随着后端增长超过15到20项服务而需要负载均衡时，成本就开始变得很高。后来由于Vinli必须负载均衡的服务数接近200，成本开始失去控制。

Kinney决定试用Kubernetes作为服务基础设施编排的手段。一个周末，他跟一支小规模团队重构了整个微服务架构，让它在Kubernetes上面跑。该基础设施包含有跨4个软件栈的大约45个应用、服务和Worker等。

这种过渡的关键部分是基于Kubernetes基元开发最后一层的应用管理层。简化Vinli内部团队开发工作的策略之一是保持需求的简单性。开发者实现其代码进Docker容器，而这些容器是可以命名并迅速发布出去的。开发者和设计师唯一的内部需求是通知运营团队有新服务了，并让他们进行应用级的健康检查。

像农夫一样思考

Vinli为自己的基础设施开发了若干简单的Kubernetes基元来优化集群管理器。它们的命名都跟农场运营有关：牧羊人(Shepherd)、领班(Foreman)、农夫(Farmer)、Burn(烧除草木)和屠夫(Butcher)。Kinney说整个编排基础设施实际上相当简单。所有这些独立的流程大概用200行代码就跑完了。它们从观察服务间的共性开始，然后在围绕着这些共性来开发工具。

Shepherd可以简化和加速把现有服务推到新的更新的过程。Kinney说标准的Kubectl集群控制工具只用30秒来做出新服务。Shepherd主要替Vinli的基础设施优化了服务的转换，用时只需要5秒钟。这使得Vinli可以移动容器时不需要担心从一个栈移到另一个栈的配置和管理。

Worker是Kubernetes内部的微服务进程，可帮助编排应用容器的加载和停转。这些需要以不同的节奏进行伸缩以配合不断变化的应用负载。Vinli创建了另一个叫做Foreman的内部工具来管理编排其他Docker进程的worker容器的生命周期。它还可以配合另一款叫做Famer的工具来增加或减少Docker容器的复制数，从而对服务负载做出响应。

Vinli总是会删除Kubernetes容器的pod。“我们扔掉pod只是为了让新的pod能上来，”Kinney说：“这能够帮助我们避免长时间的运行日志或内存问题。”名为Burn的工具会根据需要把一组里面的所有的pod都干掉、配合Butcher一起工作还可以杀死一个或多个pod，处理cron jobs(周期性指令)，发布更新到开发者和运营团队使用的内部Slack IRC源。

定期剔除集群来保持新鲜

每天Vinli都要把所有的pod干掉一遍，几秒钟之内整个基础设施都会备份并重新运行。Kinney说，“有了Kubernetes，一切都变得可以极度地随便舍弃。我们希望让东西能够自我刷新。”

另一个关键是让应用基础设施尽可能一次性使用来消除微服务架构的持久性。所有的持久层数据都用Redis和Elasticsearch保存在服务外面。这确保了新容器或新配置推送到生产环境时不会有任何数据丢失。“这让我们保持敏捷，”Kinney说。