广告

没有Kubernetes你能活下去吗?

  • 浏览(124)
  • 评论(0)
  • 译者:k8s

容器提供了一种方法,可以将应用程序封装到它自己的独立包中,其中包含成功运行所需的一切,例如库和运行时。显然,你可以在单个主机上运行容器,使用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/


  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头