后端任务调度工作流自动化云原生MLOps微服务【免费下载链接】flyteDynamic, resilient AI orchestration. Coordinate data, models, and compute as you build AI workflows.项目地址https://gitcode.com/gh_mirrors/fl/flyte点击查看免费下载本指南面向希望在 Flyte v2 中参与 Executor 组件开发的工程师完整讲解从环境准备、kind 本地集群搭建、集群内外两种运行方式、手动测试验证到 TaskAction CRD 类型扩展与代码生成的全流程。读完本文你将掌握 Executor 的迭代式开发工作流并能独立完成改类型 → 生成 CRD/DeepCopy → 安装 → 验证的闭环。一、概述Executor 在 Flyte v2 中的角色Flyte v2 的 Executor 是一个基于 Kubernetes controller-runtime 构建的控制器管理器controller manager它通过自定义资源TaskActionflyte.org/v1来承载工作流中每个 action 的执行状态。从入口文件 executor/cmd/main.go 可以看到它注册到flytestdlib/app的SetupContext上初始化TaskActionReconciler后作为后台 worker 运行从 executor/setup.go 的装配逻辑看它还串联了事件服务客户端、缓存服务客户端、插件注册表plugin registry、PodTemplate informer 与注入 Webhook。本文档executor/DEVELOPMENT.md就是围绕这一组件的开发迭代指南下面按原文档脉络逐步展开并结合仓库源码补充实现细节。二、前置条件开始开发前请确保本机满足以下版本要求工具最低版本用途Gov1.26.5编译与测试 Executor 源码Docker17.03构建 Executor 容器镜像kubectlv1.11.3操作 kind 集群、应用 CRD 与部署清单kind推荐安装本地 Kubernetes 集群文档推荐的开发环境从 executor/Makefile 可以看到构建产物默认输出到executor/bin/下的manager二进制go build -o bin/manager cmd/main.go各类脚手架工具controller-gen、kustomize、setup-envtest、golangci-lint也统一安装到本地bin/目录。三、本地开发环境设置3.1 使用 kind 创建本地集群官方推荐使用kindKubernetes in Docker作为本地开发集群理由是其轻量、可重复、易于销毁重建。后续所有集群内运行步骤均围绕一个名为flytev2的 kind 集群展开。3.2 切换到 Go v1.26 工具链当前 Flyte v2 使用 Go v1.26 进行开发。若本机默认 Go 版本不一致可用官方提供的golang.org/dl下载器切换到指定版本go install golang.org/dl/go1.26.5latest go1.26.5 download export GOROOT$(go1.26.5 env GOROOT) export PATH$GOROOT/bin:$PATH说明GOROOT指向 go1.26.5 的安装目录将其bin前置到PATH即可让当前 shell 内的go、go1.26.5命令都使用该版本。切换后可用go version验证。3.3 清理本地旧二进制Makefile 会按固定版本把工具软链到executor/bin/下例如controller-gen固定为v0.19.0kustomize固定为v5.8.1。为保持代码生成结果与测试行为的一致性建议先清掉旧版本残留make clean该命令对应 Makefile 中的clean目标rm -rf $(LOCALBIN)即删除整个本地工具目录bin/下次调用make manifests、make install等目标时会按锁定的版本重新下载。四、在 kind 集群内运行 Executor以下步骤要求先切换到executor/目录cd executor4.1 创建 kind 集群kind create cluster --imagekindest/node:v1.34.0 --name flytev2这里固定使用kindest/node:v1.34.0节点镜像并命名集群为flytev2。若集群已存在kind 会报错可先kind delete cluster --name flytev2或改用其他名字。4.2 构建 Executor 镜像IMGflyteorg/executor:nightly make docker-builddocker-build目标在 Makefile 中定义为docker-build: ## Build docker image with the manager. $(CONTAINER_TOOL) build -t ${IMG} -f Dockerfile ..即使用executor/Dockerfile构建上下文为仓库根目录..打出镜像IMG变量控制镜像名与标签。注意镜像名中的仓库前缀此处为flyteorg/executor仅用于本地标识实际推送需替换为你自己的镜像仓库。4.3 加载镜像到 kind 集群kind load docker-image flyteorg/executor:nightly --name flytev2kind 集群内的节点无法直接访问宿主机的 Docker daemon必须通过kind load docker-image把镜像导入节点集群中的 Pod 才能拉取到。4.4 安装 CRDmake install该目标通过 kustomize 渲染executor/config/crd下的清单并kubectl apply到当前集群~/.kube/config指定的上下文。实际安装的 CRD 定义见 executor/config/crd/bases/flyte.org_taskactions.yaml资源名为taskactions.flyte.orgScope 为 NamespacedAPI 版本v1。4.5 部署 Manager控制器make deploy IMGflyteorg/executor:nightlydeploy目标先用 kustomize 将config/manager中的镜像替换为IMG指定的值再渲染config/default并kubectl apply完成 Deployment、ServiceAccount、RBAC 与 Metrics Service 等一整套清单的部署。便捷提示如果你希望把打镜像 装 CRD 部署一键串起来也可以参考 Makefile 中build-installer目标的做法make build-installer IMG...会生成一份合并后的dist/install.yaml再手动kubectl apply -f dist/install.yaml即可适合 CI 或离线分发场景。4.6 清理开发结束或需要重建环境时kind delete cluster --name flytev2这会删除整个 kind 集群包括其中所有 CRD 与 Deployment。Makefile 中还提供了配套的uninstall卸载 CRD与undeploy卸载控制器目标粒度更细时可单独使用。五、在集群外运行 Executor本地调试如果不想每次改动都重新打镜像、重部署可以只在集群中安装 CRD然后在本机直接编译运行 controller——这对调试断点、日志与快速迭代非常友好。创建 kind 集群同上kind create cluster --imagekindest/node:v1.34.0 --name flytev2安装 CRDmake install编译源码并运行# 编译源码 make build # 运行 executor ./bin/managermake build的完整依赖链是manifests generate fmt vet先生成清单与 DeepCopy、再格式化与静态检查最终go build -o bin/manager cmd/main.go。./bin/manager启动时会通过ctrl.GetConfigOrDie()见 executor/cmd/main.go读取~/.kube/config连接 kind 集群并在本地执行 reconcile 循环日志直接输出到终端非常适合加日志定位问题。提示集群外运行时 Executor 不会真正调度 Pod但 CRD 的 reconcile、条件Conditions状态更新、事件上报等逻辑均可完整触发足以覆盖大部分控制器逻辑调试场景。六、手动测试与验证6.1 应用示例 CRExecutor 仓库在executor/config/samples/下提供了可直接应用的示例清单kustomization 形式执行kubectl apply -k config/samples/这里注意开发文档中的config/sample对应仓库实际目录 executor/config/samples其中核心示例 executor/config/samples/flyte.org_v1_taskaction.yaml 内容如下apiVersion: flyte.org/v1 kind: TaskAction metadata: labels: app.kubernetes.io/name: executor app.kubernetes.io/managed-by: kustomize name: taskaction-sample spec: runName: sample-run org: demo project: default domain: dev actionName: sample-task inputUri: /tmp/input runOutputBase: /tmp/output各字段含义与校验约束取自 executor/api/v1/taskaction_types.go 中的 kubebuilder marker字段含义校验约束runName该 action 所属 run 的名称Required1–30 字符project/domain所属项目与域Required1–63 字符actionNamerun 内唯一的 action 名称Required1–30 字符inputUri输入数据路径task 必填condition 留空可选runOutputBaseaction 输出写入的基准路径可选6.2 查看 TaskAction 状态应用示例后可以看到 CRD 已创建❯ kubectl get taskactions NAME RUN ACTION STATUS AGE taskaction-sample sample-run sample-task Completed 59m或使用-o wide查看更多细节❯ kubectl get taskactions -o wide NAME RUN ACTION STATUS AGE PROGRESSING SUCCEEDED FAILED taskaction-sample sample-run sample-task Completed 59m False True这里的列之所以能直接展示RUN、ACTION、STATUS、PROGRESSING、SUCCEEDED、FAILED是因为 TaskAction 类型上声明了// kubebuilder:printcolumn注解见 executor/api/v1/taskaction_types.go 中TaskActionstruct 上方它们会被make manifests翻译成 CRD 的additionalPrinterColumnsRun取.spec.runNameAction取.spec.actionNameTaskType取.spec.taskTypeStatus取 Progressing 条件的reason如 Queued、Initializing、Executing、Completed 等子状态Age取创建时间Progressing/Succeeded/Failed取对应条件的status标记为priority1仅在-o wide时显示从条件定义ConditionTypeProgressing、ConditionTypeSucceeded、ConditionTypeFailed可以看出STATUS列展示的是 Progressing 条件的 reason任务仍在排队/初始化/执行时显示 Queued/Initializing/Executing完成后显示 CompletedSucceededTrue表示终态成功FailedTrue表示失败。七、修改 TaskAction CRDCRD 是 Executor 与 Kubernetes 交互的核心契约扩展字段或校验规则需要修改 Go 类型定义并重新生成。整套流程如下。7.1 修改类型定义文件编辑 executor/api/v1/taskaction_types.go按需做以下三类修改增改TaskActionSpec/TaskActionStatus字段例如给 spec 加新的配置项、给 status 加新的观测状态。类型文件中明确要求新增字段必须有 json tagjson:...否则无法序列化。增改打印列修改TaskActionstruct 上方的// kubebuilder:printcolumn注解例如新增一列nameRunId,typestring,JSONPath.status.runId。添加校验规则使用// kubebuilder:validation:系列 marker。仓库中已使用的包括kubebuilder:validation:Required必填字段kubebuilder:validation:MinLength1/MaxLength30字符串长度范围kubebuilder:validation:Enumtask;condition枚举约束actionType字段optional可选字段以TaskActionSpec为例ActionType字段通过Enum限定只能取task或conditionRunName、Project、Domain、ActionName均被标记为 Required 且限定了长度EnvVars、Interruptible、PodTemplateName等则来自 RunSpec 的运行时投影属于可选字段。7.2 生成 CRD 清单与 DeepCopy 代码make manifests generate这一步实际执行两个命令make manifests调用controller-gen的rbac crd webhook生成器产出两类文件executor/config/crd/bases/flyte.org_taskactions.yaml包含完整 schema、校验规则minLength/maxLength/enum与打印列的 CRD 定义config/rbac/role.yamlRBAC 权限清单。注意 Makefile 中该目标还附带cp config/crd/bases/*.yaml ../charts/flyte-binary/templates/crds/即同步更新 Helm chart 中的 CRD 副本仓库路径 charts/flyte-binary/templates/crds保证 Helm 安装方式也能拿到最新 CRD。make generate调用controller-gen的object生成器更新 executor/api/v1/zz_generated.deepcopy.go为TaskAction、TaskActionList、TaskActionSpec、TaskActionStatus等类型生成 Kubernetes 要求的DeepCopy、DeepCopyInto、DeepCopyObject方法。这两个目标都会按需自动下载controller-gen锁定CONTROLLER_TOOLS_VERSION ? v0.19.0到executor/bin/下。7.3 将新 CRD 安装到集群make install重新执行 kustomize 渲染并 apply 更新后的 CRD 定义集群中的 schema 即与本地类型保持一致。若同时部署了控制器且希望应用最新镜像再执行make deploy IMG...即可。八、开发期常用 Make 目标速查结合 executor/Makefile将本文涉及的与开发迭代强相关的目标汇总如下目标作用make clean清理本地工具二进制controller-gen、kustomize 等make manifests生成 CRD YAML、RBAC 与 Webhook 配置并同步 Helm chartmake generate生成 DeepCopy 等 Go 代码make fmt/make vet代码格式化与静态检查make build编译bin/manager前置 manifests/generate/fmt/vetmake run本机直接go run ./cmd/main.go运行控制器make docker-build构建镜像IMG控制名称标签make install将 CRD 安装到当前集群make uninstall卸载 CRD可用ignore-not-foundtrue忽略缺失make deploy用 kustomize 替换镜像并部署全套清单make undeploy卸载控制器清单make test运行单元测试使用 envtest排除 e2emake test-e2e创建专用 kind 集群executor-test-e2e跑端到端测试后自动清理从 executor/setup.go 的装配代码还可以看到Executor 启动时会初始化 TaskAction reconciler含MaxSystemFailures、RequeueDuration等可配置项、插件注册表、事件与缓存服务客户端以及可选的垃圾回收器GC——这些构成了改 CRD → 生成 → 安装 → 观察 reconciler 行为完整迭代回路中控制器一侧的支撑实现开发者在排查问题时可以顺着 executor/pkg/controller/taskaction_controller.go 继续深入阅读 reconcile 主流程与条件更新逻辑。九、小结围绕 Flyte v2 Executor 的本地开发本文完整覆盖了文档给出的三条主线环境与工具链准备Go v1.26、kind、make clean、两种运行方式集群内打镜像部署、集群外编译直跑、CRD 迭代扩展改类型 →make manifests generate→make install。结合TaskAction类型定义、CRD 打印列、示例清单与 Makefile 目标开发者可以快速建立改代码 → 生成 → 部署 → 用kubectl get taskactions -o wide验证的高效闭环为进一步深入控制器源码或贡献新特性打下基础。赞分享后端任务调度工作流自动化云原生MLOps微服务【免费下载链接】flyteDynamic, resilient AI orchestration. Coordinate data, models, and compute as you build AI workflows.项目地址https://gitcode.com/gh_mirrors/fl/flyte点击查看免费下载相关推荐Onyx Craft 本地 Kubernetes 开发指南基于 kind telepresence 的集群化调试工作流Onyx Craft 本地 Kubernetes 开发指南基于 kind telepresence 的集群化调试工作流 本指南面向在 Onyx httpsAI 应用大模型RAGAI Agent后端前端Jan 扩展开发完全指南基于 janhq/core 的 Extension 架构、构建、测试与调试实践Jan 扩展开发完全指南基于 janhq/core 的 Extension 架构、构建、测试与调试实践 Jan 的扩展机制将模型推理、会话管理、资源下载等能人工智能AI 应用大模型本地部署桌面应用交互助手AI AgentComfyUI-WanVideoWrapperComfyUI 里跑 WanVideo 文生视频、图生视频的完整新手指南ComfyUI WanVideoWrapperComfyUI 里跑 WanVideo 文生视频、图生视频的完整新手指南 ComfyUI WanVideoWra人工智能大模型媒体生成上一篇终极指南AI-System自动化机器学习系统如何实现智能模型搜索与调优下一篇CodeGuide安全咨询外部安全评估流程完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考