AI时代，K8s还是企业敏捷开发的最好选择么？答案是肯定。以生成式AI“鼻祖”OpenAI为例，其底层使用的调度平台、计算平台就是K8s（Kubernetes）。
Kubernetes业内简称K8s，是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。
在Kubernetes中，企业可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。
从“1”到“N”
回看K8s的发展史，它源自谷歌一个内部服务和应用——Borg，彼时，谷歌正在面临着不断增长的应用程序和愈发复杂的服务管理的痛点，于是创建了Borg系统，用于管理和运行谷歌的内部服务和应用。Borg采用了容器化的思想，将应用程序打包成容器并在集群中运行。
直到2014前后，Google将Borg的一部分经验开源，推出了Kubernetes项目。Kubernetes最初是由Google、Red Hat、Microsoft等公司共同推动的，旨在为云原生应用提供一个开源的容器编排和管理平台。
同时期，云原生概念问世，随后，在2015年Google联合Linux基金会成立了CNCF（云原生计算基金会），Kubernetes成为CNCF管理的首个开源项目。CNCF组织开始推广云原生，并定义了云原生的三大支柱——容器化、微服务、DevOps。
而金融行业作为数字化转型较早的行业之一，其数字化转型初期的一大需求就是—满足业务快速多变的需求，在此背景下，云原生技术因其快速、弹性的特点，开始引起金融机构的重视，并与原先金融机构的大集中架构融合，共同形成目前银行IT系统的主流架构。
而这个过程中，K8s作为云原生容器化过程中的不二之选，受到了金融行业数字化转型的青睐，而容器化也成为了金融行业数字化转型最优先的“诉求”。对此，青云科技云原生产品负责人于爽表示，在2020年甚至更早以前，用户的诉求很简单——你帮我把容器用起来就行，“彼时，用户对于微服务、敏捷等服务的诉求不大。”于爽指出。
时至今日，再看金融机构对于K8s的使用，以银行为例，目前绝大多数银行的内部结算系统都放在了K8s平台上，“当下银行对于容器化平台的要求更高了，不仅要用起来，还要用得更好，”于爽进一步指出，“这也对云服务商提出了更高的要求，不止要容器化，还需要‘稳敏兼得’。”
这也意味着，K8s要实现用户从只需要容器化到的“1”，到需要稳敏兼得、微服务.....“N”的转变。
除此之外，用户对于K8s平台的差异化、定制化能力的要求也伴随着其数字化程度逐渐显现出来。于爽表示，以前用户的需求更多的停留在“表面”上，平台能有一个界面，能让用户使用K8s某个功能就足够了，但现在不是这样了，“现在用户的需求逐渐变多，需要进行容器化改造，而这些深度的需求也呈现出两极化发展。”于爽如是说。
一方面，用户对于底层的基础设施的大规模运维管理的稳定性提出了更高的要求，“无论是操作系统层面，还是异构硬件设备管理层面，用户都希望能通过K8s实现统一纳管，从而降低运维成本。”于爽指出。
另一方面，在上层，用户围绕数据库的容器化、操作系统内核优化、灾备和容灾，以及稳定性等更深层的云原生需求。
以中国建设银行为例，据了解，目前建行的数据库资产已经全面K8s化了，这里面还包括了建行的核心数据库资产。
AI时代，K8s也要“紧跟潮流”
如果把K8s比作一个人，那么它才刚刚步入成人的阶段，一方面，已经K8s已经具备了足够的技术成熟度，以及成熟的开源社区生态，并在很多行业、很多场景中得以应用；另一方面，K8s还有很多需要“学习”，进步的地方，比如在AI时代，企业AI应用落地的过程中，也对K8s平台提出了新的需求。
在AI大模型问世以前，标准的K8s加上一些上层的管理能力，以及诸如微服务、敏捷的一些业务场景能力，就基本能满足60%以上的云原生用户的需求，但在AI时代，很多用户涌现出了对于复杂工作负载管理的需求。于爽表示，“因为AI时代的工作负载，远比原先基于K8s运行一个Web应用，或者一个后台应用要复杂。尤其是在用户如何通过可观测的工具、调度工具，有效的解决他们的遇见的问题，满足需求，这就对K8s的后台管理能力和产品的复杂度提出了更高的要求。”
以可观测方面为例，随着AI应用开发的逐渐变多，对于K8s平台的可观测的规模也有了更大的要求，有些问题会随着规模的上升而显现出来，“目前来看500个节点、1000个节点已经算很大的了，但可能明年规模会翻一倍，到时候500节点、1000节点能解决的问题，在更大的规模下就无法解决了。”于爽强调。
另一方面，“观测”行为对于IT环境的区别性和异构性也在AI时代与原先有了很大的差异。原先环境下，异构计算的占比相对而言比较少，而如今异构计算几乎已经成为必需的存在，除此之外，企业为了不被同一厂商绑定，会在搭建IT环境时选择不同厂商的产品和解决方案，每个硬件厂商自身的监控指标、驱动不尽相同，这对于可观测来说是一个难题。
以青云科技为例，其解题思路是选择当下比较主流的内核技术—eBFF框架，eBPF 技术的兴起使得无侵入地对基础设施和应用进行可观测变得可行。这套框架可以以插件化的方式，可以无需侵入用户应用，从内核感知不同的可观测的数据，简化用户的配置和使用，”于爽进一步指出，“也能加强对AI 基础设施 和 AI 应用的可观测。”
可观测也成为了AI时代，K8s平台“跑”的更稳定、更安全的重要保障，“2025年，可观测一定是K8s平台主要优化的方向之一。”
除此之外，因为AI大模型训练的负载通常是阶段性的，因此对K8s平台也提出了更高的弹性伸缩的能力要求，需要根据负载情况自动调整资源分配，确保AI应用的稳定性和可用性。企业也需要再开发的过程中，不断优化资源调度算法，从而确保AI应用能够优先获得所需的计算资源，同时不影响其他应用的正常运行。
向更多应用场景延伸
显然，AI时代，企业在开发的过程中，对于K8s的使用程度会越来越深，而K8s平台也不再仅局限在金融行业可以“大展身手”。
从行业应用上看，目前除了金融行业以外，传统制造业在建设数字工厂的过程中，也大多会采用K8s平台作为底座，以此来快速提升工厂、底层运维等方面的标准化水平。
以某电池制造业龙头企业为例，在使用K8s平台之前，该企业有五个厂区采用物理机环境运行业务系统，各厂区之间缺乏统一管理，导致应用迭代只能依赖人工手动方式进行，无法实现自动化持续交付。此外，由于第三方供应商众多且开发语言不统一，造成管理和集成困难。内部应用未配备高可用机制，而工厂生产线必须保持 24 小时不间断运行，数据库管理人员的缺失导致数据库高可用性和维护性不足。
基于上述痛点，该企业采用了青云科技的 KubeSphere 容器平台进行了升级，实现了应用系统全面容器化部署，提升应用系统的交付效率和弹性扩展能力，提供灵活、开放、敏捷的基础设施服务。
并且，该企业基于KubeSphere平台构建了企业级容器云平台，在整合存量应用分布式微服务的同时，增量应用直接接入容器化平台，打通各个厂区间的系统流通性，对各大厂区进行统一管理，显著提升了厂区间协同效率与应用建设管理水平的同时，大幅提高业务定制化程度。
同时，通过数据库的容器化，降低了运维压力。使用RadonDB 数据库产品提供了从创建、运维、监控、告警到备份的全生命周期数据库管理方案，极大减轻了运维人员的工作负担。
而制造业的案例仅仅是K8s平台应用的“冰山一角”，政企、高校用户也在逐渐增多。
在AI的浪潮下，越来越多的学校科研项目中开始应用AI大模型的能力辅助科研，高校师生对于开发平台的各方面要求逐渐提升，“原先，高校可能应用虚拟化平台就足够支撑师生的科研项目，但随着AI大模型的问世，今年以来，高校对于云原生的建设需求也在不断涌现，”于爽指出，“而K8s也自然就成为了高校的重要IT 基础设施。”
随着用户群体的不断增加与变化，K8s平台也需要具备更广发的应用性，展望K8s在2025年的发展趋势时，于爽表示，2025年，K8s平台会向着三个方向演进，一是要提升可观测性，让K8s更稳定、更安全；二是要不断优化跨基础设施的集群管理，优化跨硬件、软件、混合云等场景下的使用便捷度；三是，随着边缘AI的发展，在边缘侧的平台部署和应用场景的发掘。（本文首发于钛媒体APP，作者｜张申宇，编辑丨盖虹达）
