企业官网建设流程全解析

1. 从“容器编排器”到“通用调度平台”的十字路口

最近在社区里看到不少关于Kubernetes 1.35版本更新的讨论，一个很有意思的观点是：“K8s正在变成另一种系统”。作为一个从K8s早期版本就开始在生产环境里折腾的老兵，我对这个说法感触颇深。它不再仅仅是我们认知里那个“把Docker容器管起来”的编排工具了。这次更新，尤其是围绕AI Workload的一系列增强，更像是一个明确的信号，标志着Kubernetes正在从一个“容器编排器”向一个“通用、异构工作负载调度平台”进行深刻的范式转移。AI负载只是一个开始，它暴露了K8s底层架构为了适应未来更广泛、更复杂计算场景所必须做出的改变。

回想几年前，我们部署一个Web服务，关心的是副本数、服务发现、滚动更新。那时的K8s，核心是“调度Pod到Node”，资源模型相对简单：CPU、内存、磁盘、网络。但如今，当你试图把一个大规模语言模型训练任务或者一个实时推理服务塞进集群时，你会发现原有的那套模型有点“捉襟见肘”。你需要考虑的不再是几个容器，而是GPU卡的拓扑结构、高速网络（如InfiniBand）的亲和性、模型分片与流水线并行、Checkpoint存储的巨量I/O，甚至是特定AI芯片（如NPU、TPU）的驱动与资源隔离。K8s 1.35的更新，正是在这些“痛点”上持续发力，试图为这些异构、有状态、对资源拓扑极度敏感的工作负载提供原生级的支持。

所以，当我们说K8s在变成“另一种系统”时，我们到底在说什么？我认为核心在于两点：一是资源抽象模型的极大扩展与精细化，从简单的标量资源到复杂的扩展资源、拓扑感知调度；二是控制平面的职责边界在模糊和延伸，它开始更多地介入到工作负载的生命周期管理、硬件特性的协调，而不仅仅是容器的启停。接下来，我们就结合1.35版本的一些关键特性，深入聊聊这场静默的变革。

2. 1.35版本更新：为AI与异构计算铺平道路

Kubernetes 1.35版本包含了一系列更新，其中不少都直接或间接地服务于AI、高性能计算（HPC）以及更广泛的异构工作负载。这些更新不是孤立的功能点，而是构成新能力基座的一块块拼图。

2.1 动态资源分配（Dynamic Resource Allocation, DRA）进入稳定版

这是本次更新中最重磅的特性之一。在以前，K8s管理像GPU、FPGA、智能网卡这类设备，主要依赖device plugin机制和extended resources。这种方式是静态的：节点上报我有几个“nvidia.com/gpu”，调度器按整数个进行分配。但这带来了几个问题：1）无法细分资源（比如共享一块GPU的内存）；2）设备初始化配置（如GPU的MIG模式划分）与K8s调度脱节；3）设备的上报、分配、清理生命周期难以精细管理。

DRA机制就是为了解决这些问题而生的。它引入了一个名为ResourceClaim的API对象。工作负载（Pod）不再直接请求nvidia.com/gpu: 1，而是创建一个ResourceClaim来声明自己需要某种类型的资源。这个Claim会被一个特定的ResourceDriver（由设备厂商提供）处理。ResourceDriver可以动态地决定如何满足这个Claim——它可以分配一整块设备，也可以分配一个子分区（如一个MIG实例），甚至可以进行复杂的设备初始化配置。

为什么这对AI负载至关重要？想象一个场景：你的集群里有A100 GPU。有些训练任务需要整卡，有些小的推理任务只需要一部分算力。通过DRA和对应的NVIDIAResourceDriver，你可以实现：

• 将一块A100物理卡划分为多个MIG（Multi-Instance GPU）实例。
• 训练任务Pod申请一个“完整的A100” Claim，获得整卡。
• 推理任务Pod申请一个“A100-MIG-1g.5gb” Claim，获得一个算力为整卡1/7的实例。 调度器和资源驱动协同工作，实现了单块物理GPU资源的细粒度、动态共享，极大提升了昂贵硬件资源的利用率。这超越了简单的“调度”，进入了“资源切分与编排”的领域。

2.2 基于污点的节点驱逐机制进入Beta

Node taint based eviction这个特性听起来很底层，但它对运行长时间任务（如AI训练）的稳定性至关重要。传统上，当节点出现内存压力、磁盘压力等问题时，kubelet会基于eviction signal直接驱逐Pod。这种方式是“一刀切”的，可能误伤那些高优先级或难以迁移的Pod（比如已经运行了数天的训练任务）。

新机制允许你给节点添加诸如memory-pressure、disk-pressure之类的污点。当节点条件满足时，自动打上污点。关键点在于：Pod可以通过tolerationSeconds来容忍这些污点一段时间。例如，一个AI训练Pod可以设置tolerations: - key: "memory-pressure", operator: "Exists", effect: "NoExecute", tolerationSeconds: 300。这意味着当节点内存不足时，该Pod不会被立即驱逐，而是获得了5分钟的“宽限期”。在这5分钟内，监控系统可以告警，运维人员可以介入排查，或者工作负载自身可能完成一个临时的Checkpoint。这给了复杂有状态负载一个宝贵的缓冲地带，避免了非受控的中断，是K8s向“任务感知型”平台演进的一小步。

2.3 结构化身份验证配置（Structured Authentication Configuration）稳定化

这个特性主要面向安全和管理。它允许集群管理员通过Kubernetes API（而不是静态文件）来定义身份验证链。例如，你可以配置同时支持客户端证书、静态Token、Webhook等多种认证方式，并定义它们的顺序。

对于AI/ML平台而言，这意味着可以更灵活地集成企业内部的统一认证系统（如LDAP、OIDC），并为不同的用户组（数据科学家、算法工程师、运维）配置不同的认证方式。平台团队可以动态管理认证策略，无需重启API Server。这虽然不直接提供算力，但为多租户、企业级的AI平台奠定了安全基石，使得K8s能更好地融入企业IT环境，承担更核心的调度角色。

2.4 其他值得关注的增强

• Pod就绪门（Pod Ready Gates）：Pod除了容器就绪外，可以定义自定义的“门”条件。这对于AI负载很有用，比如，一个推理服务Pod可能需要等待从外部存储加载完巨大的模型参数文件后，才能被视为真正“就绪”并接收流量。这使生命周期管理更精细化。
• 容器检查点（Container Checkpoint）API (Alpha)：允许对运行中的容器创建检查点并恢复。这虽然还在早期阶段，但为未来实现AI训练任务的“热迁移”或快速恢复提供了想象空间，是K8s向管理“有状态计算任务”迈进的技术储备。

3. AI Workload的独特挑战与K8s的应对逻辑

要理解K8s为何要变，必须看清AI工作负载到底带来了哪些传统微服务不曾有过的挑战。我结合自己部署和管理大规模分布式训练任务的经验，总结出以下几个核心痛点，以及K8s社区相应的解决思路。

3.1 挑战一：对硬件拓扑的极致敏感

传统的Web服务对“在哪台机器运行”不敏感，只要资源够用就行。但分布式AI训练（尤其是使用GPU）完全不同。

• GPU间通信：同一台机器上的多块GPU通过NVLink高速互联，跨机器的GPU则通过InfiniBand或RoCE网络。训练任务希望同一模型分片（Model Shard）或同一数据并行组内的GPU，能尽量放在NVLink互连的卡上，其次是同一台机器，最差才是跨机。
• 网络与存储：参数服务器（PS）或All-Reduce通信模式对网络延迟和带宽要求极高。数据预处理流水线则需要高吞吐的存储。

K8s的应对：拓扑感知调度（Topology-Aware Scheduling）这不仅仅是nodeSelector选个有GPU的节点那么简单。它需要调度器理解节点内部的硬件拓扑。K8s通过：

1. 设备插件上报拓扑信息：NVIDIA k8s-device-plugin等可以上报GPU的NUMA节点归属、NVLink连接关系等。
2. 调度器扩展：使用NodeResourceTopologyAPI或调度器插件（如TopologyManager），让调度器在做决策时，不仅考虑资源数量是否足够，还要考虑资源的质量（拓扑关系）。例如，它可以优先选择那些能提供2块通过NVLink互连的GPU的节点，给一个需要紧密通信的2卡训练任务。

在1.35及之前的版本中，相关的特性如TopologyManager、CPUManager都在持续增强，目标就是让调度决策从“二维”（有/无资源）升级到“三维”（有资源，且资源的拓扑排列最优）。

3.2 挑战二：任务的生命周期与协同复杂度高

一个分布式训练Job不是一组独立Pod的集合。它通常包含：

• Master/Worker角色：一个负责协调的Master Pod和多个执行计算的Worker Pod。
• 严格的启动顺序：Worker需要等待Master准备好通信地址后才能启动。
• 集体故障处理：一个Worker失败，整个训练任务可能需要暂停、恢复或重启。
• 弹性伸缩需求弱：训练任务通常资源需求固定，但推理服务可能需要根据请求量快速伸缩。

K8s的应对：工作负载API与操作符（Operator）的兴起原生Deployment/StatefulSet擅长管理无状态和简单的有状态应用，但对上述复杂模式力不从心。因此，社区催生了更高级的抽象：

• Job与CronJob的增强：用于批处理任务，但分布式协同仍需自己处理。
• Kubernetes Operator模式：这是应对此挑战的“事实标准”。例如，Kubeflow Training Operator、PyTorch Operator、MPI Operator。这些Operator是专门为管理特定类型AI任务而生的控制器。它们封装了领域知识：
  • 知道如何为PyTorch Elastic Job配置正确的环境变量，让Worker能自动发现彼此。
  • 知道在训练任务失败时，是应该重启整个Job，还是尝试从最新的Checkpoint恢复。
  • 提供了自定义资源定义（CRD），如PyTorchJob、TFJob，让用户可以用声明式的方式提交一个分布式训练任务，而无需手动编排一堆Pod和服务。

Operator的出现，意味着K8s的控制平面被“扩展”了。用户不再直接与Pod API交互，而是与一个代表“AI训练任务”的高级抽象交互。K8s的核心系统（API Server, Scheduler, Controller Manager）提供了让这些领域特定控制器安全运行的平台，自身则专注于提供更强大的底层原语（如DRA、拓扑调度）供Operator调用。这是K8s变成“另一种系统”的典型体现：它成为了一个“用于构建领域特定编排系统的系统”。

3.3 挑战三：资源类型与配置的爆炸性增长

AI领域硬件迭代飞快，从通用GPU到训练专用芯片（TPU）、推理专用芯片（NPU），再到各种内存计算、光计算设备。每种设备都有其独特的驱动、运行时库和配置方式。

K8s的应对：扩展资源与设备插件框架的演进K8s很早就通过“扩展资源”（Extended Resources）和“设备插件”（Device Plugin）框架来支持自定义硬件。其演进逻辑是：

1. 标准化接入接口：提供一个统一的Device PluginAPI，任何硬件厂商只要实现这个接口，就能将其设备资源接入K8s集群，被调度器感知。
2. 资源抽象与解耦：Pod通过resources.limits来请求vendor-domain/resource-name（如amd.com/gpu）。调度器只关心资源的数量，不关心具体实现。
3. 向动态、精细化管理演进：这就是DRA要解决的问题，让资源的分配从静态整数走向动态、可配置。

这个框架的成功，使得K8s能够以相对统一的方式管理几乎任何类型的计算设备，为它成为“通用调度平台”打下了最关键的基础。

4. 超越AI：K8s作为通用调度平台的未来图景

如果K8s的改变仅仅是为了服务AI，那或许还称不上“变成另一种系统”。真正的趋势是，为AI负载打磨的这些能力，恰好解锁了K8s管理其他各类复杂、异构工作负载的潜力。我们可以从几个维度来看这个未来。

4.1 边缘计算与混合云

边缘场景的特点是资源极度异构（从x86服务器到ARM工控机，再到带GPU的边缘盒子）、网络不稳定、需要轻量级。K8s的衍生项目K3s、KubeEdge等已经证明了其架构在边缘的适用性。而1.35中稳定的DRA、增强的拓扑调度，使得K8s能更好地调度边缘设备上特定的硬件加速器（如AI推理卡、视频编码卡），并根据网络拓扑优化任务放置（例如，将人脸识别任务调度到摄像头最近的、带NPU的边缘节点上）。

4.2 高性能计算（HPC）

传统HPC使用Slurm、PBS等作业调度系统。这些系统对MPI任务调度、高性能网络（InfiniBand）绑定有着深厚的积累。现在，我们看到K8s正在通过MPI Operator、对RDMA网络的支持、以及拓扑感知调度，逐渐侵入这个领域。K8s的优势在于其统一的API、强大的容器化隔离、以及丰富的生态系统。未来，一个科研机构或许可以用同一套K8s集群，既运行传统的Web服务，也运行需要MPI和InfiniBand的分子动力学模拟任务。

4.3 大数据处理

Spark、Flink等大数据框架早已支持在K8s上运行。但它们的资源请求往往是粗粒度的。随着DRA等技术的成熟，Spark任务或许可以更精细地申请带特定SSD的本地存储资源用于Shuffle，或者申请带智能网卡的节点来加速网络传输。K8s提供的统一资源视图和调度能力，有望让大数据平台和AI平台更深度地融合，共享底层硬件资源池。

4.4 平台工程的基石

最后，从软件工程的角度看，K8s正在成为“平台工程”（Platform Engineering）的理想底座。平台团队基于K8s提供的强大原语（CRD、Operator、调度框架、资源模型），为内部用户（开发者、数据科学家）构建高度抽象、领域特定的“内部开发者平台”。数据科学家提交一个PyTorchJob，开发者部署一个Serverless Function，所有这些都运行在同一个K8s集群上，但通过不同的Operator和抽象层被管理。K8s本身，则退居幕后，成为那个稳定、可靠、提供无限可能的“资源操作系统”。

5. 拥抱变化：从业者的实操思考与建议

面对K8s的这种演进，作为一线工程师或架构师，我们应该如何应对？以下是我基于实践经验的一些思考。

5.1 技术选型与学习路径的调整

过去学习K8s，核心是Pod、Service、Deployment、Ingress这些对象。现在和未来，你需要拓宽视野：

• 深入理解调度原理：不能满足于知道nodeSelector和affinity。要去理解Scheduler Framework、Scheduling Profile、TopologyManager的工作原理。这是K8s智能化的核心。
• 掌握Operator开发模式：如果你所在团队有特定的、复杂的工作负载（不一定是AI），考虑学习Operator SDK，为你自己的领域构建一个自定义控制器。这能极大提升运维效率和用户体验。
• 关注硬件与底层：多了解一些硬件知识，比如GPU的架构、NVLink、InfiniBand、NUMA。当你需要排查“为什么我的训练任务比别人慢”时，这些底层知识会成为关键。
• 拥抱云原生生态：关注像Kueue（用于作业队列管理）、Volcano（用于批处理调度）这样的上游孵化项目。它们代表了社区在特定调度领域的最新探索。

5.2 集群规划与运维的考量

1. 资源模型标准化：提前规划你的扩展资源命名规范。例如，统一使用company.com/gpu而不是混用nvidia.com/gpu和amd.com/gpu，可以通过设备插件来映射。这为未来混合硬件池打下基础。
2. 混合工作负载隔离：在同一个集群内运行AI训练（抢占式、高资源消耗）和在线服务（延迟敏感），需要精细化的隔离策略。除了传统的Namespace配额，要善用PriorityClass、Pod Disruption Budget，并考虑使用Node Pool或Taint/Toleration进行物理或逻辑隔离。
3. 监控与可观测性升级：传统的CPU/内存监控不够了。你需要监控GPU利用率、显存、NVLink带宽、InfiniBand网络状态、自定义设备指标。Prometheus生态的node-exporter需要搭配dcgm-exporter、kube-state-metrics以及各设备厂商的exporter来构建全景视图。
4. 存储与数据流水线：AI对存储的需求是海量和高速的。对象存储（如S3兼容）用于模型仓库和数据集，高性能分布式文件系统（如CephFS， Lustre）用于训练过程中的Checkpoint和临时数据。在K8s中，需要通过CSI驱动妥善集成这些存储，并利用Local PersistentVolume等特性优化数据本地性。

5.3 一个具体的场景：部署支持多租户的AI平台

假设我们要基于K8s 1.35+构建一个内部AI平台，支持多团队提交训练和推理任务。架构思考如下：

1. 底层资源池：集群节点分为多个节点组：高配GPU训练节点组、通用GPU推理节点组、CPU节点组。为GPU节点打上相应的taint，如dedicated=gpu-training:NoSchedule。
2. 调度与队列：使用Kueue项目。用户提交的PyTorchJob（通过Training Operator创建）并不会直接创建Pod，而是先成为一个Workload资源进入Kueue管理的队列。Kueue根据集群资源情况、团队配额（Quota）和优先级，决定何时、何地启动这个Job。这实现了公平共享和资源超卖的管理。
3. 多租户与安全：每个团队一个Namespace。使用ResourceQuota限制总资源用量。结合Structured Authentication Configuration，集成公司的OIDC，实现单点登录和团队映射。使用NetworkPolicy严格隔离网络。
4. 任务管理：平台提供封装好的PyTorchJob/TFJobCRD模板，用户只需填写镜像、命令、数据集路径等业务参数。平台Operator负责注入必要的配置，如GPU拓扑感知的环境变量、分布式训练的初始化方法等。
5. 数据与存储：为每个团队创建独立的PVC，后端连接高性能共享存储。通过初始化容器（Init Container）在任务启动前，将指定数据集从中心仓库（如S3）同步到该PVC。训练输出的模型和日志，也统一写入该PVC，再由Sidecar容器同步回中心仓库。
6. 监控与成本：集成DCGM、Prometheus，为每个训练任务提供实时的GPU指标看板。开发一个简单的成本核算系统，根据任务消耗的GPU小时数，按团队进行统计。

在这个架构里，K8s扮演的角色远远超出了容器编排。它是资源池化者、调度决策者、安全边界实施者，并通过Operator模式，将领域知识（如何运行一个分布式训练）固化为了平台能力。用户感受到的是一个“AI平台”，而非一个“容器平台”。

Kubernetes的这次演进，本质上是在回应一个更根本的需求：在云原生时代，如何统一地管理所有类型的计算任务？从无状态Web服务到有状态数据库，再到如今的AI训练、边缘推理、科学计算，这些工作负载形态各异，但对资源调度、生命周期管理、运维可视化的核心诉求是相通的。K8s没有停留在容器的层面，而是选择向下吸收更复杂的硬件抽象，向上通过扩展点（CRD, Operator, Scheduler Framework）开放出无限的可能性。AI Workload只是一个催化剂，它加速了K8s内核中那些为“通用性”而设计的能力的成熟。

所以，是的，Kubernetes正在变成另一种系统。它正在从一个优秀的“容器编排系统”，蜕变为一个更具野心的“通用工作负载调度与管理系统”。对于开发者而言，这意味着我们需要更新对它的认知；对于企业而言，这代表了一个更具性价比和统一性的技术战略选项。这个过程不会一蹴而就，中间会有复杂度提升的阵痛，但方向已然清晰。我们能做的，就是理解其背后的逻辑，然后顺势而为，利用这些新能力去解决更实际、更复杂的生产问题。毕竟，最好的技术，永远是那个能优雅地适应变化的技术。