太平洋科技企业站

Kubernetes奇点

佚名整合编辑：王珂玥发布于：2024-03-11 15:11

结合其他趋势，去年出现的生成人工智能(尤其是开源生成模型)再次改变了云的定义和经济。而组织的IT战略和战术——一如既往——也必须跟上。

Kubernetes能实现技术奇点吗?

虽然数字化转型的概念已经出现了一段时间，并且已经成为一个流行词，但在许多组织中，转型的实际过程正在加速。业务领导现在可以品尝到一些ROI和收益。他们兴奋。尤其是关于人工智能——与许多处于萌芽状态的技术创新不同，他们每天都在阅读和使用人工智能——制造了FOMO和紧迫感。

与此同时，数字化转型的现实比大多数人想象的要复杂得多。似乎目标总是简单，但随着复杂性的增加，构建和人员配置成为现实……并招致越来越多的成本。现在(虽然还在慢慢地)人们认识到这是一种生存威胁。

长期存在的假设受到质疑:

*公共云最终将比本地云更便宜，操作更简单。对于某些用例来说并非如此。对其他人来说是有争议的。虽然“遣返”并不是一年前的大趋势，但许多组织的战略需要混合公共云和私有云和平台，以支持无处不在的容器和Kubernetes(以及vm和/或裸机上的传统工作负载)。

*向多云/集群、混合和边缘/物联网的发展将是简单和无破坏性的，现有平台(包括开源和专有)将顺利发展以理解这些架构。并非如此:对所有这些云拓扑的需求正在增加，但解决方案仍然复杂、脆弱，并且涉及锁定。

*历史上“安全”的选择仍将是安全的。事实并非如此:重大收购和其他变化正在重塑大型传统专有私有云供应商的优先级，一些客户正在寻找(开源)出口。

在更基本的层面上，组织正在质疑经典的深度云堆栈(IaaS、Kubernetes、CaaS/PaaS/无服务器等)或多样化的公共云多服务架构(所有这些不同的api和cli)是否有效。越来越多的人相信，Kubernetes为所有“与云相关”的东西提供了更好的抽象，并可能为平台工程师、DevOps和开发人员提供更好(更简单、更一致、更可互操作)的工作方式。

KubeCon + CloudNativeCon Europe 2024上你将看到的一些最有趣的东西来自以下假设:

每一种工作负载——包括容器、微服务、功能即服务(FaaS)、无服务器和容器即服务(CaaS)、平台即服务(PaaS)，以及WASM、虚拟机工作负载等——都应该“在Kubernetes上运行”。

*许多PaaS解决方案太“笨重”(例如，从开发人员的角度来看，经典的PaaS提供了冗余的抽象，不能降低平台的复杂性)，公共云FaaS太不灵活。使用任何一种都会导致锁定，Kubernetes可以在“简化”的开源服务框架的帮助下本地提供这些服务。

* Kubernetes(以及一系列Kubernetes原生技术和概念，如集群API、云平台提供商和Kubernetes运营商)应该用于编组基础设施，“隐藏”IaaS层和裸机管理。

这意味着Kubernetes抽象应该是每个人每天使用的，一套工具，一个基础设施即代码(IaC)范式。

重述问题以找到答案

这一切将走向何方?对当代IT问题的看法——在最近的过去，被概念化为全球性问题，而Kubernetes只是复杂解决方案的一部分——现在被重新思考为以Kubernetes为中心的挑战:

“我们如何构建混合云?”变成了“我们如何配置Kubernetes，以便在商品化的本地IaaS(或Kubernetes)和公共云IaaS(或Kubernetes)之间提供一个统一的、连续的平台?”

“我们如何实现多集群?”不再是“我们如何在IaaS或其他地方部署大量Kubernetes集群并管理它们?”，变成了“我们如何配置Kubernetes，让我们在Kubernetes上高效地创建、共享和管理集群?””

“我们如何做边缘和物联网?”我们如何集成一套神秘的工具或购买专有的公共云模型，以便集中管理，同时在数千个位置和/或小型移动设备的远程硬件上分布计算/传感?’，开始变成‘我们如何配置Kubernetes工作负载，使其在任何地方都能运行，并将其连接到集中控制平面上?以及“我们如何使用Kubernetes和开源应用程序来增强边缘的功能，并在分布式端点上有效地训练、改进、部署和管理机器学习，以管理边缘的视觉和其他任务?””

*当然，我们如何做到这一切，并为大规模人工智能创造一个家园?

Kubernetes社区现在正在积极构建技术来应对所有这些挑战。其结果可能是合作的新前沿——例如，围绕托管控制平面和快速发展的子项目，如连接性和集群API。

如果Kubernetes成为“云”，那么会怎样?

如果Kubernetes正在成为“云”(或者更准确地说，是“使云工作的底层胶水”)，这也会产生影响。

Kubectl、YAML和kubecconfigs不能很好地扩展到大型组织和不同的技能集。所以你需要一个标准的环境(应用程序、工具、服务)来帮助平台工程师、DevOps和开发人员更少地使用Kubernetes:

*提供视图和工具，让专家有效地处理Kubernetes基础设施和平台内部

*扩展到许多上下文-围绕Kubernetes系统组件和服务，关键操作(例如，安全，更新管理)和其他复杂技术(如CI/CD)包装用户界面。

*简化应用程序的开发、管理和操作——提供应用程序命名空间、元数据、日志、度量、安全扫描、策略和其他信息的约束视图。

*促进大规模工作:协调对集群、应用程序、团队的安全访问并支持协作

Kubernetes上的AI怎么样?

与此同时，人工智能(显然)把一个巨大的煤渣块扔进了游泳池。虽然未来(正如作家威廉·吉布森所说)是不均匀分布的，但它现在就在这里。科技界的每个人都知道，人工智能将改变组织如何利用技术构建、购买和创新的一切，以竞争和获得商业利益。

人工智能正在使软件开发的旧模式——以及数字化转型的旧模式——变得过时。对于许多组织来说，现在(或即将)的大项目是利用人工智能来帮助每个人在一个越来越紧密的优化循环中运行业务。实际上是使用仪表板，而不是花费那么多时间和资源来构建它们。

Kubernetes就在这一切的中间，对于Kubernetes社区的我们来说，这是非常令人兴奋的，也有一点可怕。

虽然用于训练和运行OpenAI大型模型的Azure超级计算平台是面向虚拟机的，但Kubernetes显然是许多企业人工智能将被开发和部署的地方。对于利用预先训练的开源模型(易于以容器形式分发)以及所谓的检索增强生成(retrieve - augmented Generation, RAG)实现中的矢量数据库的企业AI来说尤其如此。(RAG是一种避免需要构建和操作“训练运行”的方法——预先训练的模型提供了良好的语言性能，而向量数据库提供了特定于用例的“知识”，可能是专有的，以一种可以保持私有的形式。)

如何在Kubernetes(以及其他新兴的企业AI范例)上有效地托管和操作RAG设置可能需要标准化和开源选项。

进行合作

随着所有这些事情同时发生，可以毫不夸张地说，技术正在接近(或者可能已经达到)一个奇点——以Kubernetes、CNCF和云原生开源生态系统为中心。

原文《The Kubernetes Singularity》

Kubernetes

佚名

原创栏目