挑战
Crowdfire 帮助内容创作者在互联网上的任何地方创建内容，并将其以正确的格式发布到其他地方。自 2010 年推出以来，其用户已增长到 1600 万。该产品最初是运行在 Google App Engine 上的单体应用，2015 年，公司开始转型，采用运行在 Amazon Web Services Elastic Beanstalk 上的微服务架构。Crowdfire 基础设施团队负责人、软件工程师 Amanpreet Singh 说：“最初这对我们的用例来说还可以，但随着服务数量、开发团队和规模的增加，部署时间、自愈能力和资源利用率开始成为我们的问题。”
解决方案
Singh 说：“我们意识到，我们需要采用更云原生的方法来解决这些问题。” 团队决定基于 Terraform 和 Ansible 实施定制的 Kubernetes 设置。
影响
Singh 说：“Kubernetes 帮助我们将部署时间从 15 分钟减少到不到一分钟。” “由于 Kubernetes 的自愈特性，运维团队在节点或 Pod 发生故障时无需进行任何手动干预。” 此外，他说，“开发和生产环境的一致性（Dev-Prod parity）得到了改善，因为开发者可以在开发/预演集群中试验各种选项，最终确定后，只需将配置更改提交到相应的代码仓库即可。这些更改会通过 CI/CD 流水线自动同步到生产集群。”
对于大多数内容创作者来说，那句电影台词可能只说对了一半。当然，像 Wordpress、YouTube 和 Shopify 这样的平台使得几乎任何人都可以轻松地在线发布新内容，但吸引受众却并非易事。Crowdfire 位于印度孟买的软件工程师 Amanpreet Singh 说，Crowdfire “帮助用户将他们的内容发布到受众存在的任何地方”。自 2010 年推出以来，Crowdfire 已拥有超过 1600 万用户，包括博主、艺术家、创客和小型企业。
面对这样的增长——以及用户对新功能和持续改进的高需求——Crowdfire 团队在后台难以跟上。2015 年，他们将单体 Java 应用迁移到 Amazon Web Services Elastic Beanstalk，并开始将其分解为微服务。
这是一个很好的第一步，但团队很快意识到他们需要沿着云原生路径走得更远，这将把他们引向 Kubernetes。Crowdfire 基础设施团队负责人 Singh 说：“最初这对我们的用例来说还可以，但随着服务数量和开发团队的增加，以及我们规模的进一步扩大，部署时间、自愈能力和资源利用率开始出现问题。” “我们意识到，我们需要采用更云原生的方法来解决这些问题。”
Singh 在寻找解决方案时，列出了 Crowdfire 的需求清单。他说：“我们希望将一些事项分开处理，以便它们可以独立于其他事项发布；这将有助于消除障碍，让不同的团队按自己的节奏工作。” “我们还做了很多数据驱动的决策，因此快速发布功能及其迭代是必须的。”
Kubernetes 满足了所有需求，甚至更多。他说：“其中一个最好的方面是内置的服务发现。” “当你有大量需要相互调用的微服务时，随时可用的内部 DNS 以及自动设置为环境变量的服务 IP 和端口非常有帮助。” 此外，他补充说，“Kubernetes 的主见式方法（opinionated approach）使其更容易上手。”
采用云原生方法还有另一个令人信服的业务原因。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，除了少数已被弃用并即将终止的服务。服务被逐个迁移，并且每个服务的性能都被监控了两到三天。Singh 说，如今，“我们已经完全迁移完成，所有新服务都运行在 Kubernetes 上。”
影响是巨大的：使用 Kubernetes 后，公司在弹性负载均衡器（Elastic Load Balancer）方面的成本节省了 90%，现在仅用于面向公众、用户可见的服务。其 EC2 运营费用也降低了高达 50%。
Crowdfire 的所有 30 名工程师都同时完成了入职。Singh 说：“我做了一次内部演讲，分享了基本组件并演示了 kubectl 的用法。” “每个人都对使用 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 就绪’，这意味着它们是否具有适当的健康检查，并能处理终止信号以优雅地关闭。”
如果你的公司符合这个情况，那就大胆尝试吧。Crowdfire 显然是这样，现在正在从中获益。Singh 说：“在使用 Kubernetes 的 15 个月里，它对我们来说非常棒。” “它使我们能够快速迭代，提高开发速度，并持续为用户提供新功能和错误修复，同时控制运营成本和基础设施管理开销。”