挑战
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 上那些刚开始使用的用户的问题，”他说。“我也会密切关注其他对话。我必须承认，我能够避免我们设置中的许多问题，因为我知道其他人也面临过同样的问题。”
根据他获得的知识，Singh 决定基于 Terraform 和 Ansible 实现 Kubernetes 的自定义设置。“我编写了 Terraform 来启动 Kubernetes 主节点和工作节点（自动扩缩组），并编写了一个 Ansible playbook 来安装所需的组件，”他说。（该公司最近已切换到使用预烘焙的 AMI 来加快节点启动速度，并计划更改其网络层。）
首先，团队将一些预演服务从 Elastic Beanstalk 迁移到新的 Kubernetes 预演集群，然后在一个月后设置了生产集群以部署一些服务。结果令人信服。Singh 说：“到 2016 年 3 月底，我们确定所有新服务都必须部署在 Kubernetes 上。”“Kubernetes 帮助我们将部署时间从 15 分钟缩短到不到一分钟。由于 Kubernetes 的自愈特性，在节点或 Pod 故障的情况下，运维团队无需进行任何手动干预。”最重要的是，他说，“开发-生产环境的一致性得到了改善，因为开发人员可以在开发/预演集群中试验选项，一旦确定，他们只需在相应的代码仓库中提交配置更改。这些更改将通过 CI/CD 流水线自动复制到生产集群中。这提高了对所做更改的可见性，并保留了审计跟踪。”
在接下来的六个月里，团队致力于将所有服务从 Elastic Beanstalk 迁移到 Kubernetes，除了少数已被弃用并将很快终止的服务。服务一次迁移一个，每个服务的性能都监测了两到三天。今天，“我们已经完全迁移，并在 Kubernetes 上运行所有新服务，”Singh 说。
影响是巨大的：通过 Kubernetes，该公司在 Elastic Load Balancer 上节省了 90% 的成本，现在仅用于其公共、面向用户的服务。其 EC2 运营费用已减少多达 50%。
Crowdfire 的所有 30 名工程师都同时入职。“我做了一次内部演讲，分享了基本组件并演示了 kubectl 的用法，”Singh 说。“每个人都对使用 Kubernetes 感到兴奋和高兴。开发人员现在对在生产环境中运行的应用程序拥有更多的控制权和可见性。最重要的是，他们对低部署时间和自愈服务感到满意。”
他们的生产力也大大提高了。Singh 说：“我们过去每天大约部署 5 次，现在我们几乎每天进行 30 多次生产部署和 50 多次预演部署。”
Singh 指出，几乎所有工程师每天都与预演集群进行交互，这在 Crowdfire 创造了一种文化变革。“开发人员现在对云基础设施更加了解了，”他说。“他们已经开始遵循云最佳实践，例如更好的健康检查、结构化日志到 stdout [标准输出] 以及通过文件或环境变量进行配置。”
鉴于 Crowdfire 对 Kubernetes 的承诺，Singh 正在寻求扩展公司的云原生堆栈。团队已经使用 Prometheus 进行监控，他说他正在评估 Linkerd 和 Envoy Proxy，作为“获取更多关于请求延迟和故障的指标，并更好地处理它们”的方式。其他 CNCF 项目，包括 OpenTracing 和 gRPC 也在他的考虑范围之内。
Singh 发现，云原生社区在印度，特别是在班加罗尔也在不断发展。“许多初创公司和新公司都开始在 Kubernetes 上运行其基础设施，”他说。
当人们问他 Crowdfire 的经验时，他提供了以下建议：“Kubernetes 是一项伟大的技术，但它可能不适合你，特别是如果你只有一两个服务或者你的应用程序不容易在容器化环境中运行，”他说。“在全力投入之前，评估你的情况以及 Kubernetes 提供的价值。如果你确实决定使用 Kubernetes，请确保你了解底层运行的组件以及它们在顺利运行集群中的作用。另一个需要考虑的问题是你的应用程序是否‘Kubernetes-ready’，这意味着它们是否有适当的健康检查并处理终止信号以优雅地关闭。”
如果你的公司符合这个要求，那就去做吧。Crowdfire 显然做到了——现在正在收获益处。Singh 说：“在我们使用 Kubernetes 的 15 个月里，它对我们来说是惊人的。它使我们能够快速迭代，提高开发速度，并不断为用户提供新功能和错误修复，同时将我们的运营成本和基础设施管理开销控制在可控范围内。”