挑战
Crowdfire 帮助内容创作者在互联网上的任何地方创建内容，并以正确的格式将其发布到其他任何地方。自 2010 年推出以来，它已发展到 1600 万用户。该产品最初是一个在 Google App Engine 上运行的单体应用程序，2015 年，该公司开始向在 Amazon Web Services Elastic Beanstalk 上运行的微服务转型。“它最初适用于我们的用例，但随着服务数量、开发团队和规模的增加，部署时间、自我修复能力和资源利用率开始成为我们的问题，”领导 Crowdfire 基础设施团队的软件工程师 Amanpreet Singh 说道。
解决方案
“我们意识到我们需要一种更加云原生的方法来解决这些问题，”Singh 说。该团队决定实施基于 Terraform 和 Ansible 的 Kubernetes 自定义设置。
影响
“Kubernetes 帮助我们将部署时间从 15 分钟缩短到不到一分钟，”Singh 说。“由于 Kubernetes 的自我修复特性，如果节点或 Pod 出现故障，运维团队无需进行任何手动干预。”此外，他还表示，“开发-生产一致性得到了改善，因为开发人员可以在开发/测试集群中试验各种选项，并在最终确定后将配置更改提交到相应的代码存储库中。这些更改会通过 CI/CD 管道自动复制到生产集群中。”
对于大多数内容创作者来说，这部电影的引言可能只有一半是正确的。当然，像 Wordpress、YouTube 和 Shopify 这样的平台让几乎任何人都可以轻松地在网上发布新内容，但吸引受众并不容易。Crowdfire“帮助用户将他们的内容发布到他们的受众存在的所有可能的地方，”该公司驻印度孟买的软件工程师 Amanpreet Singh 说。自 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 上回答刚开始使用 Kubernetes 的用户的问题，”他说。“我也会密切关注其他对话。我必须承认，我能够避免在我们的设置中出现很多问题，因为我知道其他人也遇到过同样的问题。”
根据他获得的知识，Singh 决定实施基于 Terraform 和 Ansible 的 Kubernetes 自定义设置。“我编写了 Terraform 来启动 Kubernetes 主节点和节点（自动扩展组）以及一个 Ansible playbook 来安装所需的组件，”他说。（该公司最近改用预烘焙的 AMI 来加快节点启动速度，并计划更改其网络层。）
首先，该团队将一些测试服务从 Elastic Beanstalk 迁移到新的 Kubernetes 测试集群，然后在一个月后建立了一个生产集群来部署一些服务。结果令人信服。“到 2016 年 3 月底，我们确定所有新服务都必须部署在 Kubernetes 上，”Singh 说。“Kubernetes 帮助我们将部署时间从 15 分钟缩短到不到一分钟。由于 Kubernetes 的自我修复特性，如果节点或 Pod 出现故障，运维团队无需进行任何手动干预。”最重要的是，他说，“开发-生产一致性得到了改善，因为开发人员可以在开发/测试集群中试验各种选项，并在最终确定后将配置更改提交到相应的代码存储库中。这些更改会通过 CI/CD 管道自动复制到生产集群中。这为所做的更改带来了更高的可见性，并保留了审计跟踪。”
在接下来的六个月中，该团队致力于将所有服务从 Elastic Beanstalk 迁移到 Kubernetes，除了那些已被弃用且无论如何都将很快终止的服务。这些服务一次迁移一个，并对其性能进行两到三天的监控。今天，“我们已经完全迁移，并且我们在 Kubernetes 上运行所有新服务，”Singh 说。
影响是巨大的：借助 Kubernetes，该公司在 Elastic Load Balancer 上节省了 90% 的成本，现在 Elastic Load Balancer 仅用于面向用户的公共服务。他们的 EC2 运营费用减少了多达 50%。
Crowdfire 的所有 30 名工程师都同时入职。“我做了一个内部演讲，分享了基本组件并演示了 kubectl 的用法，”Singh 说。“每个人都对使用 Kubernetes 感到兴奋和高兴。开发人员现在可以更好地控制和了解他们在生产环境中运行的应用程序。最重要的是，他们对低部署时间和自我修复服务感到满意。”
他们的工作效率也提高了很多。“我们过去每天大约部署 5 次，”Singh 说，“现在我们几乎每天都进行 30 多次生产部署和 50 多次测试部署。”
Singh 指出，几乎所有工程师每天都会与测试集群互动，这在 Crowdfire 创造了一种文化变革。“开发人员现在更加了解云基础设施，”他说。“他们已经开始遵循云最佳实践，例如更好的运行状况检查、结构化日志到标准输出以及通过文件或环境变量进行配置。”
随着 Crowdfire 对 Kubernetes 的承诺，Singh 希望扩展公司的云原生堆栈。该团队已经在使用 Prometheus 进行监控，他说他正在评估 Linkerd 和 Envoy Proxy 作为“获取有关请求延迟和失败的更多指标并更好地处理它们”的一种方式。其他 CNCF 项目，包括 OpenTracing 和 gRPC 也在他的关注范围内。
Singh 发现云原生社区在印度也在发展，特别是在班加罗尔。“很多初创公司和新公司都开始在 Kubernetes 上运行他们的基础设施，”他说。
当人们问他关于 Crowdfire 的经历时，他提供了以下建议：“Kubernetes 是一项伟大的技术，但它可能不适合你，特别是如果你只有一两个服务或者你的应用程序不容易在容器化环境中运行，”他说。“在全力以赴之前，请评估您的情况以及 Kubernetes 提供的价值。如果您决定使用 Kubernetes，请确保您了解在幕后运行的组件以及它们在平稳运行集群中所起的作用。另一个要考虑的是您的应用程序是否‘Kubernetes 就绪’，这意味着它们是否具有适当的运行状况检查并处理终止信号以正常关闭。”
如果您的公司符合该情况，请放手一搏。Crowdfire 就是这样做的，现在他们正在享受成果。辛格表示：“在使用 Kubernetes 的 15 个月里，它对我们来说棒极了。它使我们能够快速迭代，提高开发速度，并持续向用户交付新功能和错误修复，同时控制运营成本和基础设施管理开销。”