随着Freshworks从一个6人的团队发展为一个拥有11个产品的价值数十亿美元的组织，我们的基础设施和工程实力也在不断提升。在此过程中，我们采用了一些令人兴奋的技术。但是很少有人能像Kubernetes那样具有挑战性，或者说是有回报的，Kubernetes是来自Google的炙手可热的容器编排技术。一开始，我们可以使用一个简单的基于rubyonrails的应用程序托管在EngineYard平台上。自那以后，我们不断发展，现在我们的大部分基础设施都托管在Amazon Web服务上。它们跨越多个地理位置和数千个EC2实例，或者在AWS基础设施上运行应用程序的虚拟服务器。当我们扩展我们的工程功能以匹配组织的增长速度时，我们需要将我们的堆栈移动到一个现代的编排引擎中。为此，我们找了库伯内特斯。但是，当我们开始研究这项技术时，很明显，Kubernetes背负着多个运动部件和固有的复杂性。我们对那些大规模采用Kubernetes的大型科技公司的恐怖故事感到震惊。即便如此，Kubernetes还是为我们崇高的工程目标提供了一条充满希望的道路。这是很难忽视的。所以我们继续工作，开始把工作量转移到库伯内特斯。在这个过程中，我们学会了在运动部件和复杂性周围导航。我们学到了很多东西。有了这个博客，我们开始了一系列关于Kuberneteslearnings的系列文章，这段旅程还在继续。所以，骑着走吧！集装箱化之路如前所述，我们的旗舰应用Freshdesk是基于rubyonrails框架构建的。这种模式在最初的日子里运作良好。但随着规模的扩大，我们开始面临一些关键挑战：部署速度：我们非常关心所有应用程序和服务的正常运行时间。因此，推出应用程序的新版本或运行特性实验需要在不停机的情况下进行。这也适用于向我们的基础设施推出安全补丁或执行软件堆栈升级。直接在EC2基础设施上执行这项工作开始减慢我们的速度，我们很快意识到我们需要超越基于EC2/虚拟机的部署。不可变部署：另一个挑战在于确保我们基于EC2的部署是不可变的。我们很快从早期的"git克隆"部署（包括将存储库克隆到新目录中）发展到基于tarball的部署（包括将多个文件合并或压缩为一个文件）。但这仍然没有给我们足够的信心，代码或配置不会漂移。蜂窝架构：为了保持我们应用程序的全球可用性，并为客户提供更优质的服务，我们开始将我们的基础设施划分为所谓的外壳（从这样的灵感中汲取灵感）。shell本质上是我们整个基础设施堆栈的完全相同的副本，可以服务于我们的全球流量的一部分。我们尽可能多地为客户提供更多的可用性。同时，这使我们能够对基础设施事件做出快速反应。转向shell意味着需要更大的可预测性和对环境的控制，并且配置或代码没有任何变化。基础服务：我们还开始构建一些内部服务，这些服务被我们的产品所使用。这些是由不同团队开发的基础服务，如消息传递和事件。这些团队独立地决定了他们的技术堆栈，其中一些团队开始将这些服务构建为微服务。我们的团队迅速开始采用这些集装箱。较新的团队从一开始就开始将他们的应用程序和服务部署为容器。现有的团队通过更改部署管道开始迁移到容器。我们还有"炮弹"的好处，在那里我们能够逐步在我们的舰队中推广这些变化。管理我们的基础设施当我们在早期开始采用AWS时，我们寻找一种配置管理工具或服务来可靠地配置和管理我们的基础设施。我们喜欢Chef并采用了AWS Opsworks（Chef平台允许自动化AWS上的基础设施）。Opsworks带来了很多开箱即用的自动化技术，同时通过定制配方具有灵活性。然而，当我们进入容器的世界时，我们意识到我们需要一个适合容器工作流和生命周期的容器编排引擎。我们在新系统中需要这些关键功能/方面：我们的集装箱资源分配和隔离；安全/网络模型类似于我们在VMs中使用的模型；能够对我们习惯的组件/层等抽象进行建模；注意维护可用性和按需扩展。进入库伯内特斯如今，Kubernetes已经成为事实上的容器编排引擎，得到了社区和行业的巨大支持。尽管围绕库伯内特斯的警告和我们固有的恐惧，我们还是形成了拥抱库伯内特斯的强大势头。虽然这个体系存在着潜在的复杂性，但有了广大社区的支持和行业的支持，我们才有了向前迈进的信心。现在是时候付了。Kuberneteslearnings系列的未来博客将讨论我们在访问控制、联网、部署、调优、可观察性以及未来的发展方向等方面的经验教训。所以请继续关注这个空间！相关岗位对Kubernetes部署的访问控制专用群集的网络访问