Kubernetes在ShareThis生产环境中的实践

ShareThis从一个小插件起家，发展至今每月服务的网站超过450万家，为网站内容的发布者提供了高品质的服务。

快速发展是有代价的。ShareThis在扩张的过程中积累了技术负债，在基础设施方面的负债尤为突出。随着公司规模的进一步扩大，基础设施的开销因为人员和设备利用率低下的原因暴涨。一年前已经到了不得不变的地步。

Kubernetes是我们减轻基础设施负债的关键，它的作用主要体现在下面几个方面：

• 促进Docker的使用
• 简化容器管理
• 转化基础设施人才
• 实现持续集成与交付

除了Kubernetes的使用我们的devops团队也转向了容器和微服务的云计算平台架构。我们也创造了一些工具来解决技术负债的问题。

问题

云计算这个新玩意没啥经验就是玩不转，所以我们一开始完全是传统数据中心的观念。所有的MySQL、Cassandra、Aerospike、Memcache等服务都完全自己管理，就跟在传统数据中心一样架设虚拟机，安装应用然后再在Nagios或者Ganglia中进行管理。

显然这种做法是违背了云计算理念的，我们思考的方式还是服务器而不是服务。自动扩容啊微服务啊这些我们压根全没用，我们还是想的用脚本部署啥的。

这种传统数据中心用在云服务上的方式其实也没啥特别不好，就是效率低。云计算的福利完全没用上，这也就意味着没有理解云计算快速变化的本质。

解决办法

促进Docker的使用

随着Docker的流行，我们的工程师也开始实验着用Docker。很快我们就发现每个应用都得要个容器才能简化测试工作。

有的应用比较简单依赖也少所以很快就迁移到容器了。如果依赖比较简单的话我们可以用Fig来管理，Fig也就是后来的Docker Compose，但还是有很多应用和数据难以进行容器化。我们还是想迁移这部分应用的，但是Docker已经不够用了。

2015年下半年我们实在是对现有的基础设施忍无可忍了，于是评估了Docker工具、ECS、Kubernetes和Mesosphere这么几个工具。很快Kubernetes就以稳定性和易用性脱颖而出了。使用Kubernetes能够我们加强对Docker基础设施的利用。

一开始我们的工程师还有点担心，但当我们看到扩展到几百个实例有多轻松时心里的石头马上就落地了。所以不光是取代老旧基础设施的被动因素，我们也开始主动使用Docker了，艰难的系统迁移进度也快了很多。现在我们在多个地区的65个大型虚拟机上运行Kubernetes，未来几个月这个数字将超过100。我们的Kubernetes集群每天处理超过8亿个请求，未来几个月我们每天能够处理的请求数目将超过20亿。

管理容器

我们一开始因为容器管理的问题只在开发环境中用了Docker，生产环境中还没敢用多少。你在生产环境中用Docker必须知道哪个容器在哪运行，部署的是什么版本的代码，应用的状态。如何管理子网和VPC私有云都必须搞清楚。

对于容器的管理，Kubernetes有这些吸引我们的地方：

• 在AWS上安装很方便(我们所有的应用用的都是AWS)
• 配置副本控制器很方便，就是一个yaml文件
• Pod扩展起来很容易
• 增加AWS上Kubernetes集群中的虚拟机数目很容易
• 自带的部署和回滚功能
• 每个pod的状态都可以进行监控
• 服务端点endpoint可以进行管理
• 社区很活跃(意味着有问题解决起来会比较容易)

虽然有这么多好处，但它只是一个我们可以迁移的平台，这些好处都是迁移完成之后才能享受到的。总有一些奇奇怪怪的问题影响我们往新的VPC上迁移，对应用程序的修改也需要开发人员去搞定一些往常由运营团队去解决的问题。

转化基础设施人才

我们决定解决技术负债问题的时候用了傻瓜配置法来设置Kubernetes，对可能碰到的问题也没有足够的认识。我们之前服务器无论运行的方式还是网络配置都跟一个全新的Kubernetes VPC都有着很大的差别。

生产环境中我们在不同地区有的用了VPC有的则是EC2，所以不同应用可能子网和权限控制都不一样。我们既有VPC peering又有网络地址转换NAT还有代理，在Kubernetes世界中则只有VPC一种。Pod之间可以通信，服务端点也都是定义好的，这是为了简化开发人员所要掌握的内容以减少对专门的运营人员的需求。

我们最后的决定是让所有的基础设施和devops开发人员都去开发应用。你还别不信，我们根据他们应用开发的水平来安排岗位，所以也算是合理的安排。

接下来我们又安排所有的开发人员学学运营。不得不说开发人员很灵活，接受能力也很强，所以一个月之后所有的工程师都能完成修改架构这样的任务了。

我们进行这些培训的目的是让开发人员能够自如地在生产环境中使用Kubernetes。开始的一个月我还在纠结这样的选择是不是错了，两个月以后我看到了一点成功的希望，三个月以后我们已经一个礼拜部署十次了，四个月之后，每个礼拜40次都不在话下。虽然只迁移了30%的应用，但效果已经令人欣喜若狂了。Kubernetes让整个基础设施从拖后腿到加速整个公司的工作。

实现持续集成和交付

我们怎么实现每周部署40次的呢?简单来说就是持续集成和持续部署，这也是我们的迁移带来的好处之一。第一个部署在Kubernetes的应用是Jenkins，之后的每一个应用都被添加到Jenkins中。再之后Jenkins实现了进一步的自动化直到pod可以自动添加。

我们现在的问题是开发人员要部署的太多要排队。有了Kubernetes和Jenkins的帮助我们每周100次部署的目标是不难达到的。

下一步的计划

迁移的大部分问题都解决了，但剩下的任务非常地琐碎。把应用迁移到Kubernetes VPC意味着要改变很多网络配置，我们还在试图解决这一问题。

并不是所有的服务都能够被迁移到Kubernetes上，比如状态化分布式数据库。好在通常都有专门的第三方来帮我们管理这些服务。迁移完成之后我们只用负责Kubernetes上的pod就行了，这样我们的基础设施架构就简单太多了。

当然这些转变是有代价的。将基础设施迁移到Kubernetes意味着我们得有Kubernetes技术专家。虽然我们整个团队都能管理基础设施了，但他们主要的任务是进行应用开发，所以我们还没有专门的专家来研究Kubernetes和云计算技术。

我们组织了一个云平台小组来开发与Kubernetes对接的工具以及管理所有的云资源，当然他们也会对Kubernetes项目做些贡献。

小结

总的来说迁移的过程没有我们当初预想的复杂但效果很好，我们成了一家能够快速响应客户需求的公司。