ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Bitnami KubeRay Helm Chart 实战指南:在 Kubernetes 上以 Operator 方式部署与管理 Ray 集群

Bitnami KubeRay Helm Chart 实战指南:在 Kubernetes 上以 Operator 方式部署与管理 Ray 集群 云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载KubeRay 是一个基于 Kubernetes 自定义资源CRD的 Ray 集群运维方案而 Bitnami 提供的 KubeRay Helm Chart 将其封装为一条命令即可安装的完整发行版Operator、API Server 与 RayCluster 自定义资源一次到位。本文以bitnami/kuberay的 README.md 为核心骨架结合本仓库中的 values.yaml 与各模板源码逐层展开帮助你掌握从安装、参数配置、Ray 集群扩缩容到 Prometheus 可观测性、安全加固与版本升级的完整实战链路。KubeRay 与 Bitnami Helm Chart 概述什么是 KubeRayKubeRay 是用于在 Kubernetes 上部署和管理 Ray 应用的 Kubernetes Operator其核心机制是通过CustomResourceDefinitionsCRD描述 Ray 资源。Ray 是面向分布式计算与 AI 应用的运行时KubeRay 让 Ray 集群包含 head 节点与 worker 节点、RayJob、RayService 等资源以 Kubernetes 原生的方式被创建、扩缩容、观测与回收。本 Chart 由 Bitnami 打包其定位在 Chart.yaml 中描述为“KubeRay is a Kubernetes operator for deploying and management of Ray applications on Kubernetes using CustomResourceDefinitions”当前 Chart 版本为1.4.30对应的appVersion为1.4.2依赖common子 Chart2.x.x。也就是说本 Chart 安装后会在集群内同时交付KubeRay Operator监听 Ray 自定义资源并负责协调集群状态KubeRay API Server提供 HTTP/gRPC 接口管理 Ray 集群RayCluster 等 CRD由crds/目录中的 ray.io_rayclusters.yaml、ray.io_rayjobs.yaml、ray.io_rayservices.yaml 定义。为什么选择 Bitnami Secure ImagesChart 默认使用 Bitnami 构建的加固镜像其特性在 README 中列明基于企业级、面向云优化的Photon Linux操作系统构建属于“硬化hardened、最小化 CVE”的镜像提供接近零漏洞的安全镜像并配套VEX 声明、KEV已知被利用漏洞与 EPSS 评分的漏洞分诊与优先级排序面向合规场景提供FIPS、STIG 与 air-gap离线选项以及安全物料清单SBOM通过in-toto提供软件供应链来源证明provenance attestation对 Helm Chart 生态提供一流支持。关于历史遗留的 Debian 版本镜像可以查看 Bitnami Legacy registry。这一点在配置层面与global.security.allowInsecureImages跳过镜像校验参数直接相关详见下文“安全加固默认值”一节。快速开始前置条件与一键安装前置条件Kubernetes 1.23Helm 3.8.0。TL;DR 安装使用 OCI 仓库一条命令完成安装release 名为my-releasehelm install my-release oci://registry-1.docker.io/bitnamicharts/kuberay指定仓库的常规安装方式helm install my-release REGISTRY_NAME/REPOSITORY_NAME/kuberay其中REGISTRY_NAME与REPOSITORY_NAME需要替换为实际 Chart 仓库地址例如 Bitnami 官方即registry-1.docker.io/bitnamicharts。安装完成后可用helm list查看所有 release。Chart 默认即开启 Operatoroperator.enabledtrue、API Serverapiserver.enabledtrue以及一个 Ray 集群cluster.enabledtrue因此安装后即可在集群内看到完整的 KubeRay 控制面与一个默认的 Ray 集群head 一组 worker。理解 Chart 的组件架构结合模板源码Chart 的模板目录结构清晰地对应了三大组件从源码可以确认它们各自负责的职责templates/operator/Operator 的 Deployment、Service、RBACClusterRole/ClusterRoleBinding、PDB、NetworkPolicy、HPA/VPA、ServiceMonitor 等templates/apiserver/API Server 对应的全套资源templates/cluster/以apiVersion: ray.io/v1、kind: RayCluster渲染的集群定义与集群专用 ServiceAccount。Operator 的启动参数与探针在 operator/deployment.yaml 中可以看到Operator 容器默认启动参数为--metrics-addr:8080 --health-probe-bind-address:8082对应operator.containerPorts.metrics默认8080与operator.containerPorts.health默认8082两个端口值。当operator.watchAllNamespacesfalse时模板还会追加--watch-namespacenamespaces参数默认监听当前 release 所在命名空间也可通过operator.watchNamespaces指定。就绪探针与启动探针默认通过httpGet检查/healthz端口存活探针使用tcpSocket检查 health 端口这些细节都可以在模板第 122-150 行的探针渲染逻辑中核对。API Server 的启动参数与端口在 apiserver/deployment.yaml 中API Server 默认参数为-rpcPortFlag:8887 -httpPortFlag:8888对应apiserver.containerPorts.grpc8887与apiserver.containerPorts.http8888。就绪探针与启动探针同样基于/healthz的httpGet检查。Ray 镜像Chart 通过rayImage参数控制 Ray 工作节点镜像默认在 values.yaml 中为docker.io/bitnami/ray:2.49.0-debian-12-r0pullPolicy: IfNotPresent。同一份镜像同时用于 head 容器与 worker 容器这在 raycluster.yaml 中表现为ray-head与ray-worker两个容器都引用kuberay.ray.image。核心配置Operator 与 API Server镜像、副本与镜像拉取参数说明默认值operator.enabled是否启用 Operatortrueoperator.replicaCountOperator 副本数1operator.image.registryOperator 镜像仓库REGISTRY_NAME默认docker.iooperator.image.repositoryOperator 镜像仓库路径REPOSITORY_NAME/kuberay-operator默认bitnami/kuberay-operatoroperator.image.pullPolicy镜像拉取策略IfNotPresentoperator.image.pullSecrets私有仓库拉取 Secret[]apiserver.enabled是否启用 API Servertrueapiserver.replicaCountAPI Server 副本数1从源码看operator与apiserver两组参数的结构完全平行镜像、探针、安全上下文、亲和性、环境变量、Sidecar、自动扩缩容等几乎一一对应因此下文以 Operator 为主讲解API Server 可照搬同样的配置范式。探针配置Operator 与 API Server 默认都开启了 liveness 与 readiness 探针startup 探针默认关闭。以operator.*为例的默认值参数说明默认值operator.livenessProbe.enabled启用存活探针trueoperator.livenessProbe.initialDelaySeconds初始延迟5operator.livenessProbe.periodSeconds检查周期10operator.livenessProbe.timeoutSeconds超时时间5operator.livenessProbe.failureThreshold失败阈值5operator.livenessProbe.successThreshold成功阈值1如需完全自定义可覆盖operator.customLivenessProbe、operator.customReadinessProbe、operator.customStartupProbe默认{}设置后模板会优先渲染自定义探针而忽略默认探针。命名空间监控范围Operator 与 API Server 都可以控制监听范围参数说明默认值operator.watchAllNamespaces监听所有命名空间的 KubeRay 资源trueoperator.watchNamespaces仅监听指定命名空间[]operator.crNamespacedRbacEnablewatchAllNamespacesfalse时是否创建命名空间级 RBACtrueoperator.enableBatchScheduler启用批处理调度器组件false当watchAllNamespacesfalse且未指定watchNamespaces时模板会默认退化为监听当前 release 所在命名空间见 operator 模板第 100-103 行的--watch-namespace逻辑。资源请求与限制resourcesPreset 与 resources这是生产环境最重要的配置项之一。Bitnami Chart 统一支持两种方式resourcesPreset按预设档位自动生成resources段允许值包括none、nano、micro、small、medium、large、xlarge、2xlarge。预设的具体定义可在公共 Chart 的 bitnami/common/templates/_resources.tpl 中查看其入口为common.resources.preset。resources直接书写 requests/limits。模板渲染逻辑是“如果显式设置了resources则忽略resourcesPreset”例如 operator 模板第 117-120 行。各组件默认预设档位组件默认预设operator.resourcesPresetnanoapiserver.resourcesPresetnanocluster.head.resourcesPresetlargecluster.worker.common.resourcesPresetsmallREADME 明确建议生产工作负载应直接使用resources而非resourcesPreset因为预设档位“可能无法完全适配你的具体需求”。一个推荐的resources写法operator: resources: requests: cpu: 2 memory: 512Mi limits: cpu: 3 memory: 1024Mi部署 Ray 集群Head 与 Worker GroupSpecsBitnami KubeRay Chart 支持直接通过cluster段部署一个RayCluster对象apiVersion: ray.io/v1。README 中的核心用法是head 节点参数定义在cluster.head段worker 节点参数定义在cluster.worker段可以在cluster.worker.groupSpecs下描述多个不同的 worker 分组group spec任何未在分组中定义的参数都会从cluster.worker.common继承。集群级参数参数说明默认值cluster.enabled是否部署 Ray 集群truecluster.serviceType集群 Service 类型head 对外暴露方式LoadBalancercluster.serviceType会直接渲染进 raycluster.yaml 的headGroupSpec.serviceType字段。若集群不对外提供 LoadBalancer 服务可改为ClusterIP或NodePort。Head 节点配置参数说明默认值cluster.head.rayStartParamsRay 启动参数如dashboard-host、num-cpus等{}cluster.head.resourcesPresethead 容器资源预设largecluster.head.resourceshead 容器显式资源{}cluster.head.automountServiceAccountToken是否自动挂载 SA Tokenfalse例如为 head 指定 Ray 启动参数与显式资源cluster: head: rayStartParams: dashboard-host: 0.0.0.0 num-cpus: 4 resources: requests: cpu: 4 memory: 8Gi limits: cpu: 4 memory: 8GiWorker 分组配置groupSpecscluster.worker.groupSpecs是一个数组默认值为一个groupName: default的分组。每个分组可以独立设置replicas、rayStartParams、资源、探针、亲和性等未设置的字段通过coalesce逻辑回退到cluster.worker.common。这一点在 raycluster.yaml 的workerGroupSpecs渲染中体现得非常明显——例如replicas: {{ coalesce .replicaCount $.Values.cluster.worker.common.replicaCount }}rayStartParams、affinity、podLabels、resources等都遵循同样的回退规则。cluster: worker: common: replicaCount: 1 rayStartParams: num-cpus: 2 resourcesPreset: small groupSpecs: - groupName: default replicaCount: 2 - groupName: gpu-group replicas: 1 nodeSelector: gpu: true resources: limits: nvidia.com/gpu: 1通过这种“common 兜底 分组覆盖”的模型可以轻松在一个 Ray 集群内混布 CPU 与 GPU 两类 worker。集群 ServiceAccount参数说明默认值cluster.serviceAccount.create是否创建集群专用 ServiceAccounttruecluster.serviceAccount.nameServiceAccount 名称未设置时自动生成可观测性Prometheus 指标与 ServiceMonitor开启原生指标Chart 支持将 KubeRay 原生 Prometheus 指标暴露出来。方法是在operator与apiserver两个 section 下分别设置operator: metrics: enabled: true apiserver: metrics: enabled: truemetrics.enabledtrue后模板会在容器与 Service 上同时暴露指标端点Service 上默认会带有抓取注解prometheus.io/scrape: true prometheus.io/port: {{ .Values.operator.service.ports.metrics }}API Server 的注解对应apiserver.service.ports.http。这样 Prometheus 即可自动抓取。前置条件集群内需要已运行的 Prometheus 或 Prometheus Operator。可以部署同仓库中的 Bitnami Prometheus Chartbitnami/prometheus或 Kube Prometheus Chartbitnami/kube-prometheus来快速获得可用环境。集成 Prometheus OperatorServiceMonitor如需为 Prometheus Operator 生成ServiceMonitor对象需要同时满足两个条件operator: metrics: enabled: true serviceMonitor: enabled: true apiserver: metrics: enabled: true serviceMonitor: enabled: true*.metrics.serviceMonitor.enabledtrue的前提是metrics.enabledtrue模板才会创建 ServiceMonitor对应templates/operator/servicemonitor.yaml与templates/apiserver/servicemonitor.yaml。如果集群未安装 Prometheus Operator 的 CRD安装会直接报错no matches for kind ServiceMonitor in version monitoring.coreos.com/v1解决方式同样是先安装 Bitnami Kube Prometheus Chart它自带所需 CRD 与 Prometheus Operator。ServiceMonitor 的其他常用参数包括namespacePrometheus 所在命名空间、interval抓取周期如10s、scrapeTimeout、honorLabels、labels、selectorPrometheus 实例选择标签、relabelings与metricRelabelings。扩展与定制环境变量、Sidecar 与 Init 容器额外环境变量operator、apiserver、clusterhead 与 worker三处都支持extraEnvVars、extraEnvVarsCM、extraEnvVarsSecret三个维度注入环境变量operator: extraEnvVars: - name: LOG_LEVEL value: errorextraEnvVars直接追加键值对渲染到envextraEnvVarsCM引用已有 ConfigMap渲染到envFrom.configMapRefextraEnvVarsSecret引用已有 Secret渲染到envFrom.secretRef。从 raycluster.yaml 可以看到 head 与 worker 的envFrom渲染逻辑完全一致均支持同时引用一个 ConfigMap 与一个 Secret。适用于自定义初始化脚本、调整日志级别、接入链路追踪等高级场景。Sidecar 容器如需在 KubeRay 所在 Pod 内追加额外容器例如日志收集器、指标导出器等可以使用sidecars参数位于operator、apiserver、cluster.head、cluster.worker.common/groupSpecs 各处sidecars: - name: your-image-name image: your-image imagePullPolicy: Always ports: - name: portname containerPort: 1234如果这些 sidecar 需要额外暴露端口可以使用对应 Service 的extraPorts在可用处service: extraPorts: - name: extraPort port: 11311 targetPort: 11311注意本 Chart 已经内置了 Prometheus 导出器 sidecar在部署时通过--enable-metricstrue激活。因此sidecars参数只应用于额外追加的容器避免重复部署导出器。Init 容器初始化容器使用initContainers参数在业务容器启动前完成准备工作initContainers: - name: your-image-name image: your-image imagePullPolicy: Always ports: - name: portname containerPort: 1234调度与亲和性affinity / nodeSelector / tolerationsChart 允许通过affinity参数设置完全自定义的亲和性规则同时为operator、apiserver、cluster.head、cluster.worker.common提供三组开箱即用的预设参数说明允许值podAffinityPresetPod 亲和性预设soft/hardpodAntiAffinityPresetPod 反亲和性预设soft/hardnodeAffinityPreset.type节点亲和性预设类型soft/hardnodeAffinityPreset.key节点标签键任意标签键nodeAffinityPreset.values节点标签值列表标签值数组预设的实现来自 Bitnami common Chart 的common.affinities模板。注意一旦设置了affinity三类 preset 都会被忽略模板中的if .Values.xxx.affinity ... else ...分支逻辑。配套的还有nodeSelector节点标签选择与tolerations容忍污点均可按需配置。参数参考表下表汇总 README.md 与 values.yaml 中定义的完整参数体系按区块组织。Global 与 Common 参数名称描述默认值global.imageRegistry全局镜像仓库global.imagePullSecrets全局镜像拉取 Secret 数组[]global.defaultStorageClass全局默认 StorageClassglobal.storageClass已废弃改用global.defaultStorageClassglobal.security.allowInsecureImages允许跳过镜像校验falseglobal.compatibility.openshift.adaptSecurityContextOpenshift restricted-v2 SCC 兼容适配移除 runAsUser/runAsGroup/fsGroup交由平台分配默认 ID。可选auto/force/disabledautokubeVersion覆盖 Kubernetes 版本apiVersions覆盖.Capabilities报告的 API 版本[]nameOverride/fullnameOverride覆盖资源名称namespaceOverride覆盖命名空间commonLabels/commonAnnotations附加到所有对象的标签/注解{}clusterDomain集群域名cluster.localextraDeploy随 release 额外部署的对象数组[]diagnosticMode.enabled诊断模式禁用全部探针并覆盖命令falsediagnosticMode.command/diagnosticMode.args诊断模式下覆盖所有容器的命令/参数[sleep]/[infinity]Operator 参数节选核心项名称描述默认值operator.enabled启用 Operatortrueoperator.replicaCount副本数1operator.containerPorts.metrics/health指标 / 健康检查容器端口8080/8082operator.watchAllNamespaces监听所有命名空间trueoperator.watchNamespaces监听指定命名空间[]operator.enableBatchScheduler启用批处理调度器falseoperator.resourcesPreset资源预设档位nanooperator.resources显式资源推荐用于生产{}operator.podSecurityContext.fsGroupPod fsGroup1001operator.containerSecurityContext.runAsUser/runAsGroup容器运行 UID/GID1001/1001operator.containerSecurityContext.runAsNonRoot非 root 运行trueoperator.containerSecurityContext.readOnlyRootFilesystem只读根文件系统trueoperator.containerSecurityContext.allowPrivilegeEscalation禁止提权falseoperator.containerSecurityContext.capabilities.drop丢弃的能力列表[ALL]operator.containerSecurityContext.seccompProfile.typeseccomp 配置RuntimeDefaultoperator.podAntiAffinityPresetPod 反亲和预设softoperator.pdb.create创建 PDBtrueoperator.autoscaling.hpa.enabled启用 HPAfalseoperator.autoscaling.vpa.enabled启用 VPAfalseoperator.extraEnvVars/extraEnvVarsCM/extraEnvVarsSecret额外环境变量来源[]//operator.extraVolumes/extraVolumeMounts额外卷与挂载[]operator.sidecars/operator.initContainersSidecar / Init 容器[]operator.service.typeOperator Service 类型ClusterIPoperator.service.ports.metricsService 指标端口80operator.networkPolicy.enabled创建 NetworkPolicytrueoperator.networkPolicy.kubeAPIServerPortskube-apiserver 端点端口values.yaml 中默认[443, 6443, 8443][]operator.ingress.enabled启用 Ingressfalseoperator.ingress.hostnameIngress 默认主机kuberay-operator.localoperator.rbac.create创建 RBACtrueoperator.serviceAccount.create创建 ServiceAccounttrueoperator.metrics.enabled启用 Prometheus 指标falseoperator.metrics.serviceMonitor.enabled创建 ServiceMonitorfalseAPI Server 参数节选核心项名称描述默认值apiserver.enabled启用 API Servertrueapiserver.replicaCount副本数1apiserver.containerPorts.http/grpcHTTP / gRPC 容器端口8888/8887apiserver.resourcesPreset资源预设档位nanoapiserver.watchAllNamespaces监听所有命名空间trueapiserver.service.ports.http/grpcService HTTP / gRPC 端口80/8887apiserver.ingress.hostnameIngress 默认主机kuberay-apiserver.localapiserver.metrics.enabled启用 Prometheus 指标falseapiserver.metrics.serviceMonitor.enabled创建 ServiceMonitorfalseAPI Server 的探针、安全上下文、亲和性、扩展容器等参数结构与 Operator 完全平行可参照上一节。Ray Cluster 参数Head 与 Worker名称描述默认值cluster.enabled部署 Ray 集群truecluster.serviceType集群 Service 类型LoadBalancercluster.head.rayStartParamsHead 的 Ray 启动参数{}cluster.head.resourcesPresetHead 资源预设largecluster.head.resourcesHead 显式资源{}cluster.head.automountServiceAccountToken自动挂载 SA Tokenfalsecluster.worker.common.rayStartParamsWorker 通用 Ray 启动参数{}cluster.worker.common.replicaCountWorker 通用副本数1cluster.worker.common.resourcesPresetWorker 通用资源预设smallcluster.worker.groupSpecsWorker 分组定义未定义项从 common 继承[{groupName: default}]cluster.serviceAccount.create创建集群 ServiceAccounttrue以上参数均通过--set keyvalue或-f values.yaml方式在安装时注入。使用--set覆盖参数helm install my-release \ --set apiserver.enabledtrue \ REGISTRY_NAME/REPOSITORY_NAME/kuberay上例显式启用了 KubeRay API Server虽然默认即为true。更常见的是使用 YAML 文件helm install my-release -f values.yaml REGISTRY_NAME/REPOSITORY_NAME/kuberay默认的 values.yaml 可以直接作为编写自定义配置的模板。注意Chart 部署后应用访问凭据如用户名、密码无法通过 Helm 直接修改。如需更改需要删除 Chart 使用的持久卷PV后重新部署或使用应用内置的管理工具。安全加固默认值镜像校验开关Chart 从 1.3.0 起默认启用镜像校验image verification。如果使用的镜像不满足校验要求可以通过以下参数关闭global: security: allowInsecureImages: trueSecurity Context 默认值从模板与 values.yaml 可见三个组件的容器默认都处于加固状态runAsNonRoottrue、privilegedfalse、readOnlyRootFilesystemtrue、allowPrivilegeEscalationfalse、capabilities.drop[ALL]、seccompProfile.typeRuntimeDefaultPod 级fsGroup1001。这些默认值与“Bitnami Secure Images”的安全定位保持一致。Openshift 兼容global.compatibility.openshift.adaptSecurityContext默认值为auto即在检测到集群是 Openshift 时自动适配 restricted-v2 SCC移除 runAsUser/runAsGroup/fsGroup交由平台分配默认 ID。可选值auto检测到 Openshift 时应用force总是执行适配disabled不执行适配。升级与版本迁移升级建议先阅读 CHANGELOG.md 了解每次版本变更的影响面。README 中特别说明了两个关键版本升级到 1.3.01.3.0 引入了镜像校验机制。若因安全校验导致安装/升级失败可设置global.security.allowInsecureImagestrue关闭校验仅建议在可信任的离线环境使用。升级到 1.0.0这是 1.0.0 大版本的安全默认值变更resourcesPreset从none改为测试套件中验证过的最小可用档位注意resourcesPreset并非为生产设计生产请改用按需定制的resourcesglobal.compatibility.openshift.adaptSecurityContext从disabled改为auto。如果你的部署依赖自定义初始化脚本或定制逻辑升级前需要评估这些默认值变化必要时显式恢复旧默认值。备份与恢复Kubernetes 上的 Helm 应用备份/恢复通常需要备份源部署的持久卷PV并在新部署上挂载这些卷。Bitnami 官方推荐的方案是使用 VeleroKubernetes 备份/恢复工具。核心步骤概括为在集群中部署 Velero 并配置备份目标为 KubeRay 相关命名空间/持久卷创建备份恢复时在目标集群中执行 Velero 恢复将备份的 PV 挂载到重新部署的 Chart 实例上。滚动标签 vs 不可变标签README 强烈建议在生产环境使用不可变标签immutable tags避免同一标签被更新到不同镜像时部署在无感知的情况下自动变更。Bitnami 会在主容器发布新版本、出现重大变更或存在关键漏洞时通过发布新 Chart 版本的方式来更新容器镜像——这也是为什么本 Chart 中同时提供image.digest形如sha256:aa....参数一旦设置 digest就会覆盖 tag 对应的镜像为生产环境的镜像内容提供更强保证。TroubleshootingBitnami 官方提供了针对 Helm Chart 常见错误的排障指南如镜像拉取失败、CrashLoopBackOff、探针超时、ServiceMonitor CRD 缺失等场景。结合本文出现问题时建议按以下顺序排查使用helm list与helm status my-release确认 release 状态用kubectl describe pod检查 CrashLoopBackOff 与探针失败原因若报no matches for kind ServiceMonitor确认已安装 Prometheus Operator CRD安装 Bitnami Kube Prometheus Chart若为镜像校验失败评估是否设置global.security.allowInsecureImagestrue检查operator.watchAllNamespaces与 RBAC 的匹配关系确认 Operator 能观察到目标命名空间的 Ray 资源。结语通过本文你已经掌握了 Bitnami KubeRay Helm Chart 的完整实战路径从一行命令安装 Operator、API Server 与 Ray 集群到深入理解cluster.head与cluster.worker.groupSpecs的分层配置模型、Prometheus 指标与 ServiceMonitor 集成、Sidecar/Init 容器扩展、亲和性调度再到镜像校验、Security Context 与 Openshift 兼容等安全加固细节。如果你需要进一步定制values.yaml 与templates/目录下的各组件模板是理解全部可配置项的第一手资料而 raycluster.yaml 中coalesce继承逻辑则是理解“common 兜底 分组覆盖”这一核心设计的关键源码入口。赞分享云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载相关推荐Bitnami ClickHouse Operator Helm Chart 实战指南在 Kubernetes 上以 Operator 模式部署与管理 ClickHouse 集群Bitnami ClickHouse Operator Helm Chart 实战指南在 Kubernetes 上以 Operator 模式部署与管理 Cli云原生容器编排Ragas 多模态 Faithfulness 指标实战指南基于视觉与文本上下文的幻觉检测Ragas 多模态 Faithfulness 指标实战指南基于视觉与文本上下文的幻觉检测 导读 MultiModalFaithfulness 是 Ragas云原生容器编排Cassandra OperatorCassKopHelm Chart 部署指南在 Kubernetes 上以 CRD 方式创建与管理 Cassandra 集群Cassandra OperatorCassKopHelm Chart 部署指南在 Kubernetes 上以 CRD 方式创建与管理 Cassandra上一篇TypeSpec JSON Schema 装饰器完全指南typespec/json-schema 的 16 个核心装饰器详解下一篇Agent Governance Toolkit 外部操作问责配置文件External Operation-Accountability Profiles互操作模式详解创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表