挑战
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 这样的平台让几乎任何人都可以轻松地在网上开始发布新内容，但吸引受众并不容易。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 剧本来安装所需的组件，”他说。（该公司最近开始使用预先制作的 AMI 来加快节点启动速度，并计划更改其网络层。）
首先，该团队将几个预发布服务从 Elastic Beanstalk 迁移到新的 Kubernetes 预发布集群，然后在一个月后设置了一个生产集群来部署一些服务。结果令人信服。“到 2016 年 3 月底，我们确定所有新服务都必须部署在 Kubernetes 上，”Singh 说。“Kubernetes 帮助我们将部署时间从 15 分钟缩短到不到 1 分钟。由于 Kubernetes 的自愈特性，运维团队无需在节点或 Pod 故障时进行任何手动干预。”此外，他还表示，“开发环境与生产环境的保持一致性得到了提升，因为开发人员可以在开发/预发布集群中尝试各种选项，并在最终确定后，只需将配置更改提交到相应的代码库中。这些更改会通过 CI/CD 管道自动复制到生产集群。这将提高对所做更改的可见性，并保持审计跟踪。”
在接下来的六个月里，该团队致力于将所有服务从 Elastic Beanstalk 迁移到 Kubernetes，除了几个即将停止使用的过时服务以外。服务是逐个迁移的，并且每次都对其性能监控了 2-3 天。如今，“我们已经完全迁移，所有新服务都在 Kubernetes 上运行，”Singh 说。
影响相当大：借助 Kubernetes，该公司在 Elastic Load Balancer 上节省了 90% 的成本，现在该服务仅用于他们的公共用户端服务。他们的 EC2 运营支出减少了高达 50%。
Crowdfire 的所有 30 名工程师都同时加入了 Kubernetes。“我做了一个内部演讲，介绍了基本组件，并演示了 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 说。“它使我们能够快速迭代、提高开发速度，并不断为用户提供新功能和错误修复，同时将运营成本和基础设施管理开销控制在可控范围内。”