没有Kubernetes你能活下去吗？

容器提供了一种方法，可以将应用程序封装到它自己的独立包中，其中包含成功运行所需的一切，例如库和运行时。显然，你可以在单个主机上运行容器，使用Ansible或Chef之类的工具进行部署，但这种方法越来越少见。因为实际上，大规模运行容器的关键是编排。

至少，编排器使你能够放置容器，在主机发生故障时迁移容器，并提供其他服务，如配置管理、网络配置和存储。

Kubernetes（K8s）显然是大众市场的领导者和自然而然的默认选择，但部署、操作和故障排除需要大量时间和深入了解。鉴于其复杂性，仔细考虑它是否适合你的组织。

另一种选择，特别是如果你希望部署到公共云上，只需从主要云供应商之一选择托管Kubernetes服务，例如Microsoft的Azure Kubernetes Service（AKS）、Amazon Elastic Kubernetes Service（EKS）或Google Kubernetes Engine（GKE）。

对于使用混合云方法或基于内部部署的企业来说，Kubernetes发行版非常有意义，它们在Kubernetes已经提供的功能的基础上添加了许多其他功能，包括通过OpenShift路由器将流量从外部世界路由到web服务。

独立技术顾问、《构建微服务》（Building Microservices）一书的作者Sam  Newman在接受采访时表示：“有了Kubernetes，你需要一种精心策划的体验。所以你看到的是，企业组织要么在构建自己的平台，要么在购买OpenShift。”

这一趋势似乎会继续下去，最终我们会发现自己可能使用了功能即服务（FaaS）或类似的抽象，而在很大程度上没有意识到这反过来又在使用Kubernetes。不过，还有什么其他编排选择值得考虑？

Nomad：比K8s更灵活

在Kubernetes的直接竞争对手中，Hashicorp的Nomad有一个非常灵活的模型来运行不同种类的应用程序工作负载，包括Java应用程序、虚拟机（VM）、Hadoop作业等，并允许大量定制。

它还可以与Hashicorp堆栈的其他成员（Vault和Consor）很好地协作，因此，虽然它可能不是大众市场的竞争对手，但如果你想要这种灵活性，它很值得一看。

Newman表示：“我最近与一位非常大规模的金融科技客户合作，他们正搬到Nomad。这样做的原因是，他们已经围绕内部抽象创建了应用程序堆栈，并发现Nomad比Kubernetes允许更多的定制，更适合在其公共云提供商上运行，然后将Nomad的东西改编在之上运行已有的堆栈。”

另一个Nomad案例研究涉及游戏公司Roblox。作为该公司游戏服务器从Windows大规模迁移到Linux的一部分，它选择Nomad作为其编排器，Docker作为容器运行时，Terraform用于配置。

Roblox在其自己的裸金属基础设施上运行其大部分服务，同时还战略性地利用多个云供应商，包括Azure、AWS和GCP，使游戏公司能够尽可能靠近游戏玩家运行服务，无论他们位于何处。

Nomad的灵活性是Roblox决定的关键。该公司表示，它“能够保持作为单一编排器的地位，在迁移之前、期间和之后无缝地部署Windows和Linux工作负载。”

这次迁移使这家游戏公司从降低的许可成本中一年节省了500多万美元。同时，通过切换到运行64位，他们能够增加可用内存并支持更大的游戏实例。

此后，该公司在20个集群的11000多个节点上部署了Nomad，跨裸金属和云，每月为200多个国家的1亿活跃用户提供服务，正常运行时间为99.995%。

你能跳过容器编排吗？

第二个值得考虑的选择是直接跳转到FaaS平台，如Azure Functions、AWS Lambda或Google Cloud Functions。这些平台提供了一种构建分布式系统的方法，非常简单。

你部署了一些代码（一个功能），这些代码在发生某些事情（例如文件到达特定位置或消息登录到队列）之前处于休眠状态，然后功能运行。当结束时，它会关闭。

底层平台可以根据需要上下旋转这些功能，你可以在适当的地方运行多个副本。一些非常先进的工程将冷启动和热启动时间保持在可管理的水平，这种方式很难在内部部署上复制。

你可以从平台获得一定程度的健壮性，而不需要自己做任何工作，并且只需为正在运行的代码付费，这使得FaaS在负载较低或不可预测的情况下成为一个特别好的选择。

BBC采取了这条路线，利用Lambda功能作为构成BBC网站的核心技术堆栈的一部分。整个系统混合使用Lambda和EC2实例，后者用于Lambda功能调用过于昂贵的情况。

也许一个更令人惊讶的FaaS案例是Honeycomb.io。他们产品的核心是一个名为Retriever的定制数据库，其灵感来自Facebook的Scuba。Retriever没有固定的模式，除了时间戳之外没有预定义的索引，并且是多租户的。

它接收来自Kafka主题的数据，将其存储在本地SSD或Amazon S3中，数据读写层在AWS Lambda中实现。这对供应商来说是一个挑战，但这样做可以将Honeycomb的响应时间提高一个数量级。

然而，使用FaaS平台的缺点是，它们仍然处于开发的早期阶段，因此它们确实存在局限性。

你对每个运行时调用的资源控制有限；功能通常根据其可以运行的时间限制；大多数功能调用被认为是无状态的，尽管Azure Durable Functions支持挂起给定函数的状态，并允许它在调用停止的地方重新启动。

此外，如果基础设施的其他部分不能很好地扩展，FaaS的动态扩展特性可能会导致问题。

PaaS选项

第三种选择是平台即服务（PaaS），例如Heroku，Platform.sh或Railway。Heroku确实为开发人员的生产力设定了基准，但不幸的是，自Salesforce收购Heroku以来，Heroku并没有太大的发展。也就是说，如果你的应用程序能够适应给定的平台约束，那么PaaS可能是一个有效的选择。

成立于2015年的Cycle.io是这个领域中一个有趣的、相对较新的供应商，位于PaaS和编排器之间。它不是建立在Kubernetes之上，也不使用Docker。它也与Kubernetes API不兼容，但它符合OCI，这意味着底层容器是交叉兼容的。

该公司首席执行官兼创始人Jake Warner表示：“我们开始了构建周期，因为我以前在OpenStack上也经历过这种情况，我打赌，Kubernetes也会发生同样的事情：也就是说，在某个时候，人们会说‘嘿，我对能够定制一切都不感兴趣。我只希望它能正常工作’。”

Cycle采用了一种与供应商无关的容器编排方法，目前支持AWS、Equinix Metal和Vultr，还有其他一些方法。Warner强调，该公司提供自动更新，大约每10到14天一次，这是管理Kubernetes服务（如EKS和GKE）所面临的困难。相比之下，2021的一项Datadog研究报告称，最受欢迎的Kubernetes版本是17个月大的。

除了自动更新之外，Cycle的重点是尽量对开发人员友好，而不是像大多数平台一样专注于DevOps。此外，该团队的目标是找到一个最佳点，在这个点上，它可以将复杂性降至最低，同时仍然支持大多数用例，从而减少对大型Ops团队的依赖。

目前，Cycle的大多数客户都是种子和A轮初创企业，跨多个行业。Warner说，他们的共同点是，已经发展了自己的整体工程团队，但尚未开始专门建设运维团队。有了Cycle，Warner希望这些初创公司永远不需要传统的运维团队。

Cycle可以支持深层次的技术用例，但它并不最适合那些需要空腔部署、需要控制内存加密或具有非常特定硬件要求的应用程序的组织。

它目前也没有GPU支持，尽管Warner表示将在下个月左右推出。

如果你正在寻找一种能够在自己的基础设施上实现PaaS功能的解决方案，那么Cycle值得一看。

原文链接：

https://thenewstack.io/can-you-live-without-kubernetes/