Presslabs从研究到生产的Kubernetes之旅

原文：The Kubernetes Journey from Research to Production at Presslabs

作者：CALIN DON

翻译：无阻我飞扬

摘要：作者以自己所在Presslabs团队转向使用Kubernetes为例，介绍了使用Kubernetes的好处，分享了转换的经验。以下是译文。

Presslabs管理着WordPress主机，穿着用Django（Django是一个开放源代码的Web应用框架，由Python写成。）编写的客户仪表盘（dashboard是商业智能仪表盘的简称，它是一般商业智能都拥有的实现数据可视化的模块，是向企业展示度量信息和KPI现状的数据虚拟化工具）外衣创建了自己的堆栈。

仪表盘开始于2011年，作为一个普通的WordPress插件，允许客户支付每月的订阅。一年以后，我们用Python重写了每一个内部服务，通过Django App曝光了公开部分。这是一次重大改变，因为需要在它自己的堆栈上同样地托管它，并在其上添加开发过程。部署以“手动编写”的方式开始，接着是一系列混合bash脚本，synctool发展到用Ansible 和 Drone自动化部署。

第二次重写始于2014年，它涉及到将monolithic App（CSDN网站上有一篇著名的推特论战：Microservices vs. Monolithic）拆分成微服务（microservices），每一个都有它自己的API。起初，它们在虚拟机或裸机上运行。然后另一个重大的转变发生在2015年，我们规范了微服务在裸机上运行Docker容器，主要是为了开发目的。这是一次成功的重写，因此将其开源共享，对于其他寻求这种解决方案的人来说也是有意义的。

日益复杂的部署和微服务组件之间的互联，搭建一个临时环境的复杂性，无休止的维护问题，例如升级运行服务机器的底层操作系统——这些只是我们当时面临的最紧迫的一些问题。基本上，我们害怕破坏东西，这就导致了新功能部署的速度减慢和不频繁。

转换

2016年，我们开始关注容器编排工具；一年后，决定进行试验，看看是否至少能够解决上面的一些挑战。所以在这里分享一些我们转向Kubernetes时候学到的一些关键点，如果你计划或者已经在研究类似的转换，希望可以节省点时间。

首先，我们测试了Docker Swarm和Kubernetes。尽管Docker Swarm在一开始更友好，因为安装非常的容易和快速，但它没有让人感觉到生产准备就绪。例如，它将从DNS“丢失”服务，而且一些节点的CPU在没有过载的情况下也会发生尖峰。

Kubernetes在生产和一般的事情上执行的更好，但需要更高的安装工作量。从1.6版本，Kubernetes开始表现出一定的成熟度和更慷慨的功能集（诸如RBAC，动态容量配置，应用程序API），使其更适合生产，所以我们决定历经安装和配置它的痛苦。在这段旅程中，除了Kubernetes文档，我们发现两个指南特别有用：Kubernetes来之不易和Kubernetes通过Ansible不那么艰难。

只有当设法让Kubernetes运行起来的时候，它才能变的有趣。2017年的9月，我们开始内部服务的迁移，确保在复制它到托管栈之前，我们获得了所有的经验和最佳实践。

如果要总结经验，只有三个关键的教训，下面是想与大家分享的：

1. 部署和维护自己的集群是不必要的。

如果没有足够的需求部署和操作自己的机器，交给Kubernetes提供商托管。在AWS EKS, Azure Container Service 和 Google Kubernetes Engine之间选择。我们选择了GKE（Google Kubernetes Engine），因为在当时的情况下，与其它提供商早期提供的托管服务相比，GKE是唯一一个感觉足够成熟的（cli和第三方工具是可用的）。

此外，尽管Kubeadm最近的beta版本可以帮助建立一个最小可行的集群，但使用它也有一定的缺点。目前，它缺乏对HA master的支持，仍然被认为是一个测试版。尽管如此，希望大家能够有足够的雄心来部署一个实验室集群并面对内部的复杂性。如果公司足够小，开发团队会感谢使用托管服务的，因为维护一个集群至少需要一名专职的工程师全情投入。

2. 使用 Helm 的Kubernetes部署服务是一个好主意

由于缺乏标准的部署方法，只能为繁琐的额外工作和可能的错误预留空间，迁移到Kubernetes的希望是还可以获得一些运行速度。

我们需要可复制和版本控制的部署，所以探讨Kubectl, Terraform和 Helm。很早从列表中把Kubectl去掉，因为它缺乏模板支持和代码重用。我们意识到将要围绕它添加很多的定制代码，使其按照需要运行。

Terraform证明更适合做基础设施的供应，对Kubernetes的支持总是滞后。例如，在这写这篇文章的时候，还没有对Kubernetes部署的支持。

3. 管理部署机密是痛苦的。

现在是时候抱怨Helm了，因为它缺少一个完整的秘密管理。幸运的是，通过SOPS,整合Helm，Helm-Secrets 插件挽救了它，这是一个通过版本控制库管理和保密的工具。唯一缺失的部分是与我们所贡献的谷歌云密钥管理服务的集成。

使用Kubernetes的好处

现在仪表盘及其服务已经完全迁移，我们对结果非常满意。总的来说，使用Kubernetes给我们带来的好处有3个关键点：

1. 更容易部署。这直接影响了我们的生产能力，因为它加快了我们的开发周期，允许我们每天执行一些部署，而不是每周。

2. 更好的可用性。Kubernetes真是可靠到家；我们不再担心破坏构建，零部署宕机时间成为常态。

3. 维护更简单。不再需要为服务器升级安排停机时间，因为它运行的机器由云提供商管理。

使用Kubernetes也影响了团队的整体氛围，团队有更多的时间去研究、规划和开发其它功能，这些都是对产品成功至关重要的。

此外，我们已经为客户仪表盘的底层基础设施实现了标准化，连同自动化管理和部署。

从更广泛的角度来看，我们渴望跟上当前技术发展的步伐。至少在目前，如果你正在寻找编排容器和微服务的解决方案，Kubernetes的解决方案是值得选择的。当所有主要的云提供商选择在Kubernetes上管理服务时，你可能想了解并使用它们，以同样的方式，我们自己为托管WordPress网站提供服务。

也许最重要的一点是，企业客户将很快能够从一个更具有扩展性的WordPress的托管堆栈获益，这些WordPress的托管堆栈直接运行在Kubernetes集群。

如果你正在寻找更多关于我们迁移到Kubernetes的信息，请给我们写信。