挑战
Crowdfire 帮助内容创作者在互联网的任何地方创建内容，并以正确的格式将其发布到其他地方。自 2010 年推出以来，它已增长到 1600 万用户。该产品最初是一个在 Google App Engine 上运行的单体应用程序，并且在 2015 年，该公司开始转型为在 Amazon Web Services Elastic Beanstalk 上运行的微服务。“最初对于我们的用例来说还可以，但随着服务数量、开发团队和规模的增加，部署时间、自我修复能力和资源利用率开始对我们构成问题”，Crowdfire 基础设施团队负责人、软件工程师 Amanpreet Singh 说。
解决方案
“我们意识到，我们需要一种更加云原生的方法来解决这些问题”，Singh 说。该团队决定基于 Terraform 和 Ansible 实现 Kubernetes 的自定义设置。
影响
“Kubernetes 帮助我们将部署时间从 15 分钟缩短到不到 1 分钟”，Singh 说。“由于 Kubernetes 的自我修复特性，在节点或 pod 发生故障时，运维团队无需进行任何手动干预。”此外，他说，“由于开发人员可以在开发/暂存集群中尝试各种选项，并且在最终确定后，他们只需在各自的代码存储库中提交配置更改，因此开发-生产一致性得到了改善。这些更改会通过 CI/CD 管道自动复制到生产集群上。”
对于大多数内容创作者来说，这句电影台词可能只对了一半。当然，像 Wordpress、YouTube 和 Shopify 这样的平台使几乎任何人都可以轻松地开始在线发布新内容，但是吸引受众并不容易。位于印度孟买的该公司软件工程师 Amanpreet Singh 说，Crowdfire “帮助用户将内容发布到所有可能存在受众的地方”。自 2010 年推出以来，Crowdfire 已获得超过 1600 万用户——从博主和艺术家到制造商和小企业。
随着这种增长以及用户对新功能和持续改进的强烈需求，Crowdfire 团队努力在幕后跟上。 2015 年，他们将其单体 Java 应用程序迁移到 Amazon Web Services Elastic Beanstalk，并开始将其分解为微服务。
这是很好的一步，但团队很快意识到他们需要进一步深入云原生之路，这将引导他们走向 Kubernetes。 “最初对于我们的用例来说还可以，但随着服务数量和开发团队的增加以及我们规模的进一步扩大，部署时间、自我修复能力和资源利用率开始出现问题”，Crowdfire 基础设施团队负责人 Singh 说。“我们意识到，我们需要一种更加云原生的方法来解决这些问题。”
在寻找解决方案时，Singh 列出了 Crowdfire 需要的清单。“我们希望将某些东西分开，以便它们可以独立于其他东西进行交付；这将有助于消除障碍，并让不同的团队以自己的节奏工作”，他说。“我们还做了很多数据驱动的决策，因此快速交付一项功能及其迭代是必须的。”
Kubernetes 不仅满足了所有条件，而且还更多。“最好的事情之一是内置的服务发现”，他说。“当您有一堆需要相互调用的微服务时，拥有现成的内部 DNS 以及自动设置为环境变量的服务 IP 和端口会有很大帮助。”此外，他补充说，“Kubernetes 的规范性方法使其更容易入门。”
云原生方法还有另一个令人信服的商业理由。“在当今瞬息万变的业务需求的世界中，使用云原生技术提供了多种选择，甚至可以在混合云环境中运行服务”，Singh 说。“企业可以将服务保留在最接近用户的区域，从而受益于高可用性和弹性。”
因此，在 2016 年 2 月，Singh 使用提供的 kube-up 脚本设置了一个测试 Kubernetes 集群。“我探索了这些功能，并且能够非常轻松地部署应用程序”，他说。“然而，它看起来像一个黑匣子，因为我没有完全理解这些组件，也不知道 kube-up 脚本在底层做了什么。因此，当它坏了时，很难找到问题并修复它。”
为了更好地理解，Singh 深入研究了 Kubernetes 的内部结构，阅读了文档，甚至阅读了一些代码。他还在 Kubernetes 社区中寻找更多见解。“我过去常常每天晚上熬夜（很多用户只有在印度晚上才活跃），并且会尝试回答 Kubernetes 社区 Slack 上刚入门的用户提出的问题”，他说。“我还会密切关注其他对话。我必须承认，我能够避免我们设置中的许多问题，因为我知道其他人也面临着同样的问题。”
基于他获得的知识，Singh 决定基于 Terraform 和 Ansible 实现 Kubernetes 的自定义设置。“我编写了 Terraform 来启动 Kubernetes 主节点和节点（Auto Scaling Groups），以及一个 Ansible playbook 来安装所需的组件”，他说。（该公司最近切换到使用预先构建的 AMI 以加快节点启动速度，并计划更改其网络层。）
首先，该团队将一些暂存服务从 Elastic Beanstalk 迁移到新的 Kubernetes 暂存集群，然后在 一个月后设置了一个生产集群来部署一些服务。结果令人信服。“到 2016 年 3 月底，我们确定所有新服务都必须部署在 Kubernetes 上”，Singh 说。“Kubernetes 帮助我们将部署时间从 15 分钟缩短到不到 1 分钟。由于 Kubernetes 的自我修复特性，在节点或 pod 发生故障时，运维团队无需进行任何手动干预。”最重要的是，他说，“由于开发人员可以在开发/暂存集群中尝试各种选项，并且在最终确定后，他们只需在各自的代码存储库中提交配置更改，因此开发-生产一致性得到了改善。这些更改会通过 CI/CD 管道自动复制到生产集群上。这使得对所做的更改更加可见，并保留了审计跟踪。”
在接下来的六个月中，该团队致力于将所有服务从 Elastic Beanstalk 迁移到 Kubernetes，除了少数已被弃用并将很快终止的服务。服务一次迁移一个，并对其性能进行为期两到三天的监控。如今，“我们已完全迁移，并且我们在 Kubernetes 上运行所有新服务”，Singh 说。
影响是巨大的：借助 Kubernetes，该公司在 Elastic Load Balancer 上节省了 90% 的成本，现在仅将其用于面向公众的用户服务。他们的 EC2 运营支出减少了高达 50%。
Crowdfire 的所有 30 名工程师都一次性入职。“我做了一次内部演讲，我在其中分享了基本组件并演示了 kubectl 的用法”，Singh 说。“每个人都对使用 Kubernetes 感到兴奋和高兴。现在，开发人员可以更好地控制和了解他们在生产中运行的应用程序。最重要的是，他们对较短的部署时间和自我修复服务感到满意。”
他们的工作效率也更高了。“我们以前每天进行大约 5 次部署”，Singh 说，“现在我们几乎每天进行 30 多次生产部署和 50 多次暂存部署。”
Singh 指出，几乎所有工程师每天都与暂存集群交互，这在 Crowdfire 创造了一种文化变革。“开发人员现在更加了解云基础设施”，他说。“他们开始遵循云最佳实践，例如更好的运行状况检查、结构化日志到 stdout [标准输出] 以及通过文件或环境变量进行配置。”
随着 Crowdfire 对 Kubernetes 的承诺，Singh 希望扩展该公司的云原生堆栈。该团队已经使用 Prometheus 进行监控，他说他正在评估 Linkerd 和 Envoy Proxy，作为“获取有关请求延迟和故障的更多指标并更好地处理它们”的一种方式。其他 CNCF 项目，包括 OpenTracing 和 gRPC 也都在他的考虑之中。
Singh 发现，云原生社区在印度也在发展，尤其是在班加罗尔。“许多初创公司和新公司都开始在 Kubernetes 上运行其基础设施”，他说。
当人们问他关于 Crowdfire 的经验时，他会提供以下建议：“Kubernetes 是一项很棒的技术，但它可能并不适合您，特别是如果您只有一两个服务或者您的应用程序不容易在容器化环境中运行”，他说。“在全力投入之前，请评估您的情况以及 Kubernetes 提供的价值。如果您决定使用 Kubernetes，请确保您了解在底层运行的组件及其在集群平稳运行中所起的作用。需要考虑的另一件事是您的应用程序是否‘已为 Kubernetes 做好准备’，这意味着它们是否具有适当的运行状况检查并处理终止信号以正常关闭。”
如果您的公司符合该要求，请放手去做。 Crowdfire 显然做到了——并且现在正在收获回报。“在我们使用 Kubernetes 的 15 个月里，它对我们来说非常棒”，Singh 说。“它使我们能够快速迭代，提高开发速度，并不断向用户交付新功能和错误修复，同时控制我们的运营成本和基础设施管理开销。”