ShareThis:Kubernetes投入生产

今天的来宾博客文章是ShareThis技术主管Juan Valencia的一项服务,该服务可帮助网站发布商推动跨社交网络的参与和消费者共享行为。

ShareThis从成立之初就已经发展为一个小部件,可让您共享自己喜欢的社交服务,从而取得了巨大的发展。现在,它每月可以为超过450万个域提供服务,从而帮助发布商创建更真实的数字体验。

快速增长需要付出代价。我们利用技术债务来快速扩展和发展我们的产品,尤其是在基础架构方面。随着我们公司的扩展,基础设施成本也在增加-无论是效率低下还是人力成本。大约一年前,很明显需要进行一些更改。

TL; DRKubernetes已成为我们减少基础架构中技术债务的重要组成部分,它可以:

  • 促进Docker的采用
  • 简化容器管理
  • 基础架构的入门开发人员
  • 解锁持续集成和交付 我们通过完全采用Kubernetes并将我们的DevOps团队切换到在容器和微服务方面工作的Cloud Platform团队来实现这一目标。这包括创建一些工具来解决我们自己的遗留债务。

问题

las,云是新的,我们还很年轻。我们从传统的数据中心思维开始。我们管理着我们所有的服务:MySQL,Cassandra,Aerospike,Memcache,您可以为它命名。我们就像在传统服务器上一样设置虚拟机,在其上安装我们的应用程序,并在Nagios或Ganglia中对其进行管理。

不幸的是,这种思维方式与以云为中心的方法相反。我们没有考虑服务,而是考虑服务器。我们不是在使用自动缩放,微服务甚至托管虚拟机等现代云方法,而是在脚本设置,服务器部署以及避免供应商锁定方面进行了思考。

这些思维方式本身并不坏,只是效率低下。他们没有利用很快发生的云更改。这也意味着,当需要进行更改时,我们将这些更改视为对数据中心的大的缓慢更改,而不是对云的小的快速更改。

解决方案

Kubernetes作为促进Do​​cker采用的工具

随着Docker逐渐成为我们行业中的一支力量,ShareThis的工程师也开始对其进行试验以取得良好的效果。很快变得很明显,我们需要为公司中的每个应用程序都拥有一个工作容器,以便我们可以简化开发环境中的测试。

一些应用程序很快就迁移到Docker中,因为它们很简单且几乎没有依赖性。对于那些依赖较小的用户,我们可以使用Fig进行管理(Fig是Docker Compose的原始名称)。尽管如此,我们的许多数据管道或相互依赖的应用程序太过粗糙,无法直接进行泊坞窗处理。我们仍然想这样做,但是Docker还不够。

2015年底,我们对传统基础架构感到非常沮丧,最终使我们感到震惊。我们评估了Docker的工具,ECS,Kubernetes和Mesosphere。显而易见,与我们的基础架构竞争对手相比,Kubernetes处于一种更加稳定和用户友好的状态。作为一家公司,我们可以简单地设定将所有基础架构都置于Kubernetes上的目标,从而巩固Docker上的基础架构。

最初,工程师对此表示怀疑。但是,一旦他们看到应用程序毫不费力地扩展到每个应用程序数百个实例,它们就会被钩住。现在,不仅有推动我们进入Docker以及扩展到Kubernetes的痛苦点,而且吸引我们加入该技术的确令人兴奋。这使我们能够相当迅速地进行非常困难的迁移。现在,我们在大约65个大型VM的多个区域中运行Kubernetes,并在接下来的几个月中将其增加到100多个。我们的Kubernetes集群目前每天处理8亿个请求,并计划在未来几个月内每天处理超过20亿个请求。

Kubernetes作为管理容器的工具

我们最早使用Docker对于开发很有希望,但对于生产则没有那么大的希望。最大的摩擦点是无法大规模管理Docker组件。知道哪些容器在哪里运行,什么版本的部署正在运行,应用程序处于什么状态,如何管理子网和VPC等,困扰着它投入生产的任何可能性。所需的工具本来就很大。

当您查看Kubernetes时,有几项立即吸引人的关键功能:

  • 它很容易在运行我们所有应用程序的AWS上安装
  • 从Dockerfile到yaml / json文件的复制控制器之间存在直接路径
  • Pod可以轻松扩展数量
  • 我们可以轻松扩展Kubernetes集群中在AWS上运行的VM的数量
  • 工具中内置了滚动部署和回滚功能
  • 通过健康检查对每个吊舱进行监控
  • 服务端点由工具管理
  • 有一个活跃而充满活力的社区

不幸的是,最大的痛点之一是该工具并不能解决我们现有的旧基础架构,而只是提供了可以迁移到的基础架构。仍然存在各种网络怪癖,使我们无法直接将应用程序迁移到新的VPC上。此外,对如此多的应用程序进行重做需要开发人员跳入系统管理员和运营团队经典解决的问题。

Kubernetes作为基础架构入门开发人员的工具

当我们决定从本质上是由厨师运行的设置切换到Kubernetes时,我认为我们不了解我们会遇到的所有痛苦点。我们以各种不同的方式在各种不同的网络配置中运行我们的服务器,这些配置与您在新的Kubernetes VPC上找到的干净设置有很大不同。  

在生产中,我们在多个区域中同时运行了AWS VPC和AWS Classic。这意味着我们在不同的应用程序中使用不同的访问控制来管理多个子网。我们最近的应用程序也非常安全,没有公共端点。这意味着我们结合了VPC对等,网络地址转换(NAT)和以各种配置运行的代理。

在Kubernetes世界中,只有VPC。理论上,所有Pod都可以互相通信,并且明确定义了服务端点。开发人员可以轻松掩盖一些细节,并且无需进行任何操作(大多数情况下)。  

我们决定将所有基础架构/ DevOps开发人员转换为应用程序开发人员(真的!)。我们已经开始根据他们的开发技能而不是他们的操作技能来聘用他们,所以也许这听起来并不那么疯狂。

然后,我们决定将整个工程组织加入运营部门。开发人员很灵活,他们享受挑战,享受学习。非常了不起1个月后,我们的组织从只有几个DevOps的人员发展到让每个工程师都有能力修改我们的体系结构。

在网络,生产,问题解决,根本原因分析等方面的入职培训基地正在使Kubernetes大规模投入生产。第一个月后,我咬指甲,担心我们的选择。 2个月后,似乎有一天是可行的。 3个月后,我们每周进行10次部署。 4个月后,每周40个应用程序。我们仅将30%的应用程序进行了迁移,但收益不仅惊人,而且令人震惊。 Kubernetes允许我们从基础设施发展缓慢的过程中走出来!组织,基础设施正在加速发展!组织。

Kubernetes作为解锁持续集成和交付的一种手段

我们每周如何进行40多个部署?简而言之,持续集成和部署(CI / CD)是我们迁移的副产品。我们在Kubernetes中的第一个应用程序是Jenkins,并且每个进入的应用程序也都添加到Jenkins中。随着前进,我们使Jenkins更加自动化,直到添加吊舱和从Kubernetes中取出吊舱的速度超过了我们的追踪速度。  

有趣的是,我们在扩展方面的问题现在是希望立即进行太多更改,而人们不得不等到轮到他们为止。我们的目标是每周通过新的基础架构进行100次部署。如果我们能够继续执行迁移并致力于Kubernetes和Jenkins上的CI / CD流程,这是可以实现的。

下一步

我们需要完成迁移。至此,问题已基本解决,最大的困难在于手头工作的繁琐。将事物移出我们的传统基础架构意味着更改网络配置,以允许在Kubernetes VPC和整个区域之间进行访问。这仍然是非常现实的痛苦,我们将继续解决这一痛苦。  

有些服务在Kubernetes中不能很好地发挥作用-考虑有状态的分布式数据库。幸运的是,我们通常可以将其迁移到由第三方负责管理。迁移结束时,我们将仅在Kubernetes上运行pod。我们的基础架构将变得更加简单。

所有这些更改都不是免费的。将整个基础架构交付给Kubernetes意味着我们需要拥有Kubernetes专家。我们的团队在基础架构方面一直畅通无阻,他们正忙于通过应用程序开发(如应有的那样)来增加业务价值。但是,我们(尚未)尚未承诺工程师及时了解Kubernetes和云计算的变化。  

因此,我们已经将一名工程师调到了一个新的“云平台团队”,并将聘用另外两名工程师(我已经提到过 我们正在招聘!)。他们将负责开发工具,我们可以使用这些工具与Kubernetes很好地接口并管理我们的所有云资源。此外,他们将使用Kubernetes SIG的一部分Kubernetes源代码,并且理想情况下将代码推入开源项目。

概要

总而言之,尽管最初迁移到Kubernetes似乎令人生畏,但它远没有我们想象的复杂和破坏性的。而另一端的回报是,一家公司可以按照客户希望的速度做出快速反应。编者注:在最近的Kubernetes聚会上,ShareThis团队介绍了他们在Kubernetes上的生产使用情况。视频嵌入在下面。