Kubeflow是运行在K8S之上的一套技术栈，通过各种组件实现机器学习模型的训练和推理部署到云原生的模型平台。
Kubeflow组件
Kubeflow提供了一大堆组件，涵盖了机器学习的方方面面，Kubeflow中大多数组件的实现都是通过定义CRD来工作。为了对Kubeflow有个更直观深入的了解，先整体看一下Kubeflow都有哪些组件，并对Kubeflow的主要组件进行简单的介绍：
- Dashboard：Kubeflow的dashboard看板页面
- Notebooks：一个Jupyter交互式业务IDE编码环境
- Pipelines：一个基于Argo实现的ML的工作流组件，它允许编排整个机器学习工作流程，包括数据预处理、模型训练、部署和监控。
- Operator：是针对不同的机器学习框架提供资源调度和分布式训练的能力（TF-JobOperator，PyTorchJob-Operator，XGBoost-Operator，MPI-Operator，MXNet-Operator），这些Operator的本质，是K8S的Custom Resource
- Trainer：模型训练，使用TFJob和PyTorchJob运行TensorFlow和PyTorch工作负载的原生Kubernetes作业，简化了模型训练和部署过程，使其更加Kubernetes原生化。
- Katib：Hyperparameter Tuning是基于各个Operator实现的超参数搜索和简单的模型结构搜索的系统
-
KServe：支持部署各个框架训练好的模型的服务化部署和推理。
- Seldon Core Serving
- TensorFlow Serving:提供对Tensorflow模型的在线部署，支持版本控制及无需停止线上服务、切换模型等
- NVIDIA Triton Inference Server(Triton以前叫TensorRT)，大语言模型版本是TensorRT-LLM，是LLM推理加速神器
- TensorFlow Batch Prediction
TensorRT-LLM
TensorRT-LLM支持模型架构定义、预训练权重编译、推理加速，GPU 上的高效推理，做了 SOTA 级别的优化，包含了一个可与 Triton Inference Server 集成的 backend，自带主流的预定义热门大语言模型，包括 baichuan、LlaMA、ChatGLM、BLOOM、GPT等。
LightLLM
LightLLM是商汤发布的推理服务框架，简单高效，易于二次开发和其他框架的集成。
Knative
Knative 是谷歌发起的基于kubernetes平台的Serverless 开源项目,致力将Serverless标准化。Kubernetes作为基础设施，解决应用编排和运行环境。Knative 将kubernetes和istio的复杂度进行抽象和隔离，解决了繁琐的构建，部署，服务治理步骤，并且基于开放标准使得服务变得可移植。
- Isito作为通信基础设施层，保证服务的运行可检测、可配置、可追踪；
- Knative使用应用模板和统一的运行环境来标准化服务的构建、部署和管理；
- Knative构建在Kubernetes、Istio、Container的基础上，以K8S的CRD形式存在。
Knative的三个组件（Serving、Build、Eventing）遵循了三个云原生最佳实践的设计实现。
- 服务的编排要实现计算资源弹性化
- 服务的构建和部署要实现高度自动化
- 事件驱动基础设施标准化
使用KubeFlow进行TF分布式训练
启动TensorFlow的训练就很简单了。编写以下的配置文件。
apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
generateName: tfjob
namespace: kubeflow
spec:
tfReplicaSpecs:
PS:
replicas: 1
restartPolicy: OnFailure
template:
spec:
containers:
- name: tensorflow
image: gcr.io/your-project/your-image
command:
- python
- -m
- trainer.task
- --batch_size=32
- --training_steps=1000
Worker:
replicas: 3
restartPolicy: OnFailure
template:
spec:
containers:
- name: tensorflow
image: gcr.io/your-project/your-image
command:
- python
- -m
- trainer.task
- --batch_size=32
- --training_steps=1000
kind: 值是TFJob，这是这个Custom Resource固定的名字
spec.tfReplicaSpecs: 这里可以定义多个replica的类型、数量和具体的容器
类型的可选值是[Chief|Ps|Worker|Evaluator]，跟TensorFlow保持一致
replicas表示数量，比如这次训练时1个PS+3个Worker
批量调度引擎
在深度学习或者机器学习场景下，大部分任务都需要批量调度功能，也就是需要保证多个Pod同时地调度。它主要算法就是all or nothing的算法，保证整个资源要么可以调度，要么就不要调度，如果无法调度那么就排队，保证整个资源不会被饿死。这是一个比较常见的需求。
这里面主要是用volcano去做gang-scheduling。
核心功能：
* 作业管理 (Job): 扩展了 Kubernetes Job 的概念，支持更复杂的作业结构（如 MPI, Spark, TensorFlow/PyTorch 分布式作业）。
* 队列 (Queue): 引入队列概念，对作业进行分组和管理资源配额。
* 高级调度策略：
* Gang Scheduling (PodGroup): 确保作业的所有任务（Pod）要么全部调度成功，要么都不调度，解决“队头阻塞”问题。
* 公平/比例共享 (Fair-share, Proportion): 根据队列权重或作业优先级在用户/队列之间公平分配资源。
* 作业优先级和抢占 (Priority, Preemption): 高优先级作业可以抢占低优先级作业的资源。
* 回填 (Backfill): 利用碎片资源提前调度小作业，提高集群利用率。
* 拓扑感知调度 (Topology-aware): 优化需要低延迟或高带宽通信的作业（如 AI 训练）。
* 预留 (Reservation): 为未来即将到达的高优先级作业预留资源。
* 优点： 深度集成 Kubernetes，为批处理/AI/HPC 工作负载提供了强大且必需的调度能力，显著提高了集群资源利用率和作业调度效率。社区活跃 (CNCF Incubating 项目)。
* 缺点/局限： 需要额外部署和维护，配置相对复杂，主要聚焦于批处理场景，对纯在线服务场景的提升不如批处理场景显著。
* 适用场景： 大规模 AI/ML 模型训练和推理，科学计算 (HPC)，大数据处理作业 (Spark, Flink on K8s)，任何需要复杂作业调度策略（尤其是 Gang Scheduling）的场景。
多集群编排
跟k8s配合的多集群管理系统是Karmada，将k8s应用调度/分发到多个k8s集群。
为了解决多集群环境下AI作业的调度与管理问题，Volcano社区孵化了Volcano Global子项目。该项目也是基于Karmada，扩展了Volcano在单集群中的强大调度能力，为多集群AI作业提供了统一的调度平台，支持跨集群的任务分发、资源管理和优先级控制。
核心概念与调度机制：
* PropagationPolicy: 定义 哪些资源 (通过标签选择器) 需要被分发，以及分发到 哪些集群 (通过集群选择器)。
* OverridePolicy: 定义分发到特定集群时，如何 覆盖或修改 资源的某些字段（如镜像版本、副本数、环境变量等），实现集群差异化配置。
* 调度过程：
1. 用户创建资源 (Deployment, ConfigMap 等) 和 PropagationPolicy。
2. Karmada 控制平面根据 PropagationPolicy 的集群选择器，筛选出目标集群候选集。
3. Karmada 的调度器 (karmada-scheduler) 基于集群级属性（如集群资源利用率、区域、故障域、用户自定义权重/标签）评估哪个或哪些集群最适合运行该应用。它决定的是资源绑定到哪个集群 (ResourceBinding)。
4. 资源被分发到目标集群。
5. 目标集群上的原生 kube-scheduler (或替换的调度器如 Volcano) 负责将 Pod 调度到该集群内的具体 Node 上。
* 优点： 提供统一的多集群应用管理视图，实现跨集群高可用和自动故障转移，支持集群差异化配置，避免厂商锁定。
* 缺点/局限： 它本身不替代 kube-scheduler 或 Volcano。它解决的是更高层次的“集群选择”问题，底层集群内的 Pod 调度仍然依赖该集群自身的调度器。复杂性高于单集群管理。
* 适用场景： 多云/混合云部署，需要跨地域容灾的应用，多租户场景下隔离不同的集群资源池，集中管理多个边缘集群。
