Seldon Core 2 Helm 配置完全指南:Envoy 优雅停机、原生自动缩放、模型控制面与日志级别调优

发布时间:2026/10/15 16:00:30
Seldon Core 2 Helm 配置完全指南:Envoy 优雅停机、原生自动缩放、模型控制面与日志级别调优 人工智能大模型MLOpsLLMOps模型推理服务云原生后端【免费下载链接】seldon-coreAn MLOps framework to package, deploy, monitor and manage thousands of production machine learning models项目地址https://gitcode.com/gh_mirrors/se/seldon-core点击查看免费下载Seldon Core 2Seldon Core V2通过多组 Helm Chart 提供高度可配置的部署框架允许针对部署行为、资源管理、日志、自动缩放与模型生命周期策略进行精细化调优。本文以仓库文档 docs-gb/installation/helm/README.md 为骨架逐项讲解 Envoy、Autoscaling、Server Prestop、Model Control Plane 与 Logging 五大类配置参数的默认值、作用机制与底层实现并结合k8s/helm-charts下的 values 文件与scheduler/目录下的 Go 源码进行佐证。读完本文你将掌握如何通过--set或 values 文件定制 Seldon Core 2 各组件行为、如何为 Envoy 与模型 Server 配置优雅停机、如何开启实验性的原生自动缩放与模型打包server packing、如何单独控制每个组件的日志级别。一、配置的入口五张 Helm Chart 与 values 文件Seldon Core 2 的 Helm 图表全部位于仓库的 k8s/helm-charts 目录共五张详见 docs-gb/getting-started/kubernetes-installation/helm.mdChart作用seldon-core-v2-crds集群级安装自定义资源CRDseldon-core-v2-setup安装 operator/manager可限定命名空间或集群级并附带默认的SeldonConfig与ServerConfig资源使 Runtimes 和 Servers 可按需快速安装seldon-core-v2-runtime通过创建SeldonRuntime自定义资源在目标命名空间创建核心组件Scheduler、Envoy、Dataflow、ModelGateway、PipelineGateway、Hodometer 等seldon-core-v2-servers安装示例Server自定义资源默认 1 个 MLServer 1 个 Tritonseldon-core-v2-certs提供一组用于 TLS 的默认证书本文讨论的所有配置参数envoy.*、autoscaling.*、serverConfig.*、logging.*、agent.*都属于seldon-core-v2-setup这张 Chart——也就是说这些选项最终被渲染进 setup 阶段创建出的默认SeldonConfigmlops.seldon.io/v1alpha1的defaultSeldonConfig中并由运行时组件读取。set up 图表的完整默认值位于 k8s/helm-charts/seldon-core-v2-setup/values.yaml渲染模板位于 k8s/helm-charts/seldon-core-v2-setup/templates/_components-statefulsets.tpl 与 k8s/helm-charts/seldon-core-v2-setup/templates/_components-deployments.tpl。安装时通过--set传入的每个值最终都会以环境变量的形式注入对应的 Pod例如 Scheduler Pod 的启动参数中就有--server-packing-enabled$(SERVER_PACKING_ENABLED)、--enable-model-autoscaling$(ENABLE_MODEL_AUTOSCALING)等见_components-statefulsets.tpl中 scheduler 容器的 args 定义。这意味着改动这些 Helm 值后需要重新helm upgrade组件 Pod 会以新环境变量重启。二、Envoy 配置优雅停机与访问日志Envoy 是 Seldon Core 2 的数据平面入口负责接收推理请求并将其路由到模型 Server 副本。以下配置均在 k8s/helm-charts/seldon-core-v2-setup/values.yaml 中给出默认值。2.1 Prestop下线前的优雅停机KeyChart说明默认值envoy.preStopSleepPeriodSecondscomponents执行 prestop 命令后继续 sleep 的秒数30envoy.terminationGracePeriodSecondscomponentsEnvoy Pod 等待 prestop 完成的宽限期120底层实现在 k8s/helm-charts/seldon-core-v2-setup/templates/_components-statefulsets.tpl 中Envoy 容器配置了如下的lifecycle.preStop钩子lifecycle: preStop: exec: command: - /bin/sh - -c - | echo -ne POST /healthcheck/fail HTTP/1.1\r\nHost: localhost\r\nConnection: close\r\n\r\n /dev/tcp/localhost/{{ .Values.envoy.adminInterfacePort }} sleep {{ .Values.envoy.preStopSleepPeriodSeconds }}也就是说当 Envoy Pod 收到终止信号时会先通过管理端口默认envoy.adminInterfacePort值为 9901向 Envoy 自身发送POST /healthcheck/fail让健康检查立即失败从而把流量摘除随后 sleeppreStopSleepPeriodSeconds秒给正在途中的请求留出完成时间。Pod 级terminationGracePeriodSeconds则被设置为envoy.terminationGracePeriodSeconds默认 120 秒作为整个下线流程的总宽限。调优建议如果推理请求耗时较长应适当增大preStopSleepPeriodSeconds同时务必保证terminationGracePeriodSeconds preStopSleepPeriodSeconds否则 sleep 未结束 Pod 就被强制杀死。2.2 Access Log访问日志KeyChart说明默认值envoy.enableAccesslogcomponents是否记录请求日志trueenvoy.accesslogPathcomponents日志文件在磁盘上的路径仅在enableAccesslog为 true 时生效/tmp/envoy-accesslog.txtenvoy.includeSuccessfulRequestscomponents是否包含成功请求设为 false 时仅记录失败请求仅在enableAccesslog为 true 时生效false底层实现这三个值会经由 Scheduler 的启动参数--envoy-accesslog-path、--enable-envoy-accesslog、--include-successful-requests-envoy-accesslog传入见 scheduler/cmd/scheduler/main.go最终由 Scheduler 生成 Envoy 的 xDS 监听器配置。在 scheduler/pkg/envoy/xdscache/resource.go 中可以看到if config ! nil config.EnableAccessLog { var filter *accesslog.AccessLogFilter nil if !config.IncludeSuccessfulRequests { filter createAccessLogFilterMatchErrors() } manager.AccessLog []*accesslog.AccessLog{ ... } }当includeSuccessfulRequestsfalse时代码会调用createAccessLogFilterMatchErrors()构造一个Status 码过滤器StatusCodeFilter的 OR 组合只让非 2xx 的响应写入日志日志写入器为envoy.access_loggers.file输出到accesslogPath指定的文件。因此在生产环境中可以保持默认配置只记录失败请求用很小的磁盘开销换取完整的错误观测需要全量请求审计时再把includeSuccessfulRequests改为true。三、Autoscaling原生自动缩放实验特性Seldon Core 2 提供了**独立于外部自动缩放服务如 Kubernetes HPA**的原生自动缩放能力由 Scheduler 与 Agent 配合实现。相关默认值位于 k8s/helm-charts/seldon-core-v2-setup/values.yaml。KeyChart说明默认值autoscaling.autoscalingModelEnabledcomponents为 Model 启用原生自动缩放与外部自动缩放如 HPA正交falseautoscaling.autoscalingServerEnabledcomponents为 Server 启用原生自动缩放与外部自动缩放如 HPA正交trueagent.scalingStatsPeriodSecondscomponents用于自动缩放的指标采样周期秒20agent.modelInferenceLagThresholdcomponents触发模型副本扩容的队列积压lag阈值30agent.modelInactiveSecondsThresholdcomponents触发模型副本缩容的空闲时间阈值秒600autoscaling.serverPackingEnabledcomponents是否允许将模型打包到更少的 Server 上falseautoscaling.serverPackingPercentagecomponents允许打包的事件比例取值 0.01.0越高越激进仅在serverPackingEnabled为 true 时生效0.0底层实现与机制开关注入 Scheduler在_components-statefulsets.tpl中ENABLE_MODEL_AUTOSCALING与ENABLE_SERVER_AUTOSCALING分别取自autoscaling.autoscalingModelEnabled与autoscaling.autoscalingServerEnabled并以--enable-model-autoscaling、--enable-server-autoscaling参数传给 Schedulerscheduler/cmd/scheduler/main.go。SERVER_PACKING_ENABLED/SERVER_PACKING_PERCENTAGE则对应--server-packing-enabled/--server-packing-percentage。采样与阈值来自 Agentagent.scalingStatsPeriodSeconds、agent.modelInferenceLagThreshold、agent.modelInactiveSecondsThreshold在 Agent 中对应--scaling-stats-period-seconds、--model-inference-lag-threshold、--model-inactive-seconds-threshold三个启动参数见 scheduler/cmd/agent/cli/flags.go 与 scheduler/cmd/agent/cli/cli.go。Agent 以ScalingStatsPeriodSeconds为周期通过 scheduler/cmd/agent/main.go 将“推理 lag 统计”与“模型最后使用时间统计”两类包装器交给modelscaling.StatsAnalyserService从而判断模型是应该扩容lag 超过modelInferenceLagThreshold还是缩容空闲超过modelInactiveSecondsThreshold。打包packing的代码兜底Scheduler 的parseFlags()中有一个值得注意的细节——如果serverPackingEnabled为 false则强制把serverPackingPercentage置为 0scheduler/cmd/scheduler/main.go。另外代码内部的allowPackingPercentageDefault为 0.25但 Helm 图表默认值是 0.0因此以 Helm 默认安装时打包完全关闭。调优建议autoscalingModelEnabled默认关闭、autoscalingServerEnabled默认开启即默认只对 Server 副本做原生缩放。若希望按模型粒度扩容需开启 Model 自动缩放并同时调小modelInferenceLagThreshold更快扩容与modelInactiveSecondsThreshold更快缩容。该特性在文档中明确标注为experimental上线前应在测试环境充分验证。四、Server 配置优雅停机与模型控制面Server 是承载模型推理的副本MLServer / Triton其行为由serverConfig.*与agent.*控制。相关默认值位于 k8s/helm-charts/seldon-core-v2-setup/values.yaml。4.1 Server PrestopKeyChart说明默认值serverConfig.terminationGracePeriodSecondscomponents该 Server Pod 等待 prestop 进程完成的宽限期120该值被渲染为每个 Server Pod由 ServerConfig 派生的 StatefulSet/Deployment的spec.terminationGracePeriodSeconds保证 Server 在被删除前有足够时间完成在途推理与模型资源清理。4.2 Model Control Plane模型控制面模型控制面负责模型副本的加载load、卸载unload与错误处理由每个 Server Pod 内的Agent 边车执行。所有agent.*值都以字符串形式配置在 values.yaml 的serverConfig.agent下。KeyChart说明默认值agent.overcommitPercentagecomponents允许的内存超卖百分比范围 010010agent.maxLoadElapsedTimeMinutescomponents单个模型在某个 Server 副本上执行 load 命令允许的最大耗时分钟调低可更快暴露错误120agent.maxLoadRetryCountcomponents单个模型在某个 Server 副本上 load 失败的最大重试次数调低可让控制面命令更快失败5agent.maxUnloadElapsedTimeMinutescomponents单个模型在某个 Server 副本上执行 unload 命令允许的最大耗时分钟调低可更快暴露错误15agent.maxUnloadRetryCountcomponents单个模型在某个 Server 副本上 unload 失败的最大重试次数调低可让控制面命令更快失败5agent.unloadGracePeriodSecondscomponents防止 Envoy 实际应用集群变更移除路由与随后执行模型副本卸载命令之间的竞态条件的保护期2底层实现超卖overcommitAgent 用overCommitPercentage计算可用的额外内存。在 scheduler/pkg/agent/state_manager.go 中GetOverCommitMemoryBytes()返回overCommitPercentage / 100 * totalMainMemoryBytes而GetAvailableMemoryBytesWithOverCommit()在已超卖时返回overCommitBytesMax - overCommitUsedBytes未超卖时返回availableMainMemoryBytes overCommitBytesMax。即 Agent 允许模型占用的内存总量略高于 Server 物理内存以换取更高的模型密度。对应指标seldon_server_replica_memory_capacity_overcommit_bytes_gauge定义在 scheduler/pkg/metrics/agent.go。load 的退避重试在 scheduler/pkg/agent/agent_svc_manager.go 中加载模型时调用backoffWithMaxNumRetry(loaderFn, am.agentConfig.maxLoadRetryCount, am.agentConfig.maxLoadElapsedTime, logger)——即在maxLoadElapsedTime总时限内、以maxLoadRetryCount为上限做退避重试全部失败后发送LOAD_FAILED事件并清理现场。unload 的竞态保护UnloadModel的第一行就是time.Sleep(am.agentConfig.unloadGraceTime)见 agent_svc_manager.go注释明确说明“由于 Envoy 是最终一致的需要在卸载前等待一个宽限期让 Envoy 排空连接并反映集群变更大约 500ms”。这就是agent.unloadGracePeriodSeconds的实际用途。随后同样以backoffWithMaxNumRetry执行卸载agent_svc_manager.go。关于默认值的仓库现状说明文档表格中agent.maxUnloadRetryCount默认值为 5而当前仓库的 values.yaml 实际写的是1Agent 代码中的defaultMaxUnloadRetryCount也是 1见 scheduler/cmd/agent/cli/cli.go。其余参数maxLoadRetryCount5、maxLoadElapsedTimeMinutes120、maxUnloadElapsedTimeMinutes15、unloadGracePeriodSeconds2、overcommitPercentage10与文档一致。调优时请以helm show values seldon-charts/seldon-core-v2-setup输出的实际默认值为准。调优建议对加载耗时长的大模型建议调大maxLoadElapsedTimeMinutes与maxLoadRetryCount避免加载抖动导致模型频繁标记失败对需要快速失败反馈的在线场景可调低 unload 相关超时与重试次数。五、Logging组件级日志级别logging.logLevel是全局兜底设置只要某个组件未单独设置日志级别就使用该值。全局默认值位于 k8s/helm-charts/seldon-core-v2-setup/values.yaml。KeyChart说明默认值logging.logLevelcomponents组件级通用日志级别未单独设置时生效。可选值debug、info、errorinfocontroller.logLevelcomponentscontrolleroperator manager日志级别遵循 zap 日志级别常量未设回退到logging.logLeveldataflow.logLevelcomponentsDataflow 引擎日志级别遵循 klogging 级别未设回退dataflow.logLevelKafkacomponentsDataflow 中 Kafka 客户端库的日志级别未设回退scheduler.logLevelcomponentsScheduler 日志级别遵循 logrus 级别未设回退modelgateway.logLevelcomponentsModelGateway 日志级别遵循 logrus 级别未设回退pipelinegateway.logLevelcomponentsPipelineGateway 日志级别遵循 logrus 级别未设回退hodometer.logLevelcomponentsHodometer 日志级别遵循 logrus 级别未设回退serverConfig.rclone.logLevelcomponentsrclone 的日志级别遵循 rclonelog-level取值infoserverConfig.agent.logLevelcomponentsAgent 边车日志级别遵循 logrus 级别未设回退底层实现在_components-statefulsets.tpl中每个组件的LOG_LEVEL环境变量都通过 Helm 模板三元表达式实现“组件级优先、全局兜底”value: {{ hasKey .Values.scheduler logLevel | ternary .Values.scheduler.logLevel .Values.logging.logLevel }}即若scheduler.logLevel显式设置则使用它否则回退到logging.logLevel。类似地Dataflow 使用SELDON_LOG_LEVEL_APP与SELDON_LOG_LEVEL_KAFKA两个环境变量并做upper大写处理rclone 使用RCLONE_LOG_LEVELAgent 使用SELDON_LOG_LEVEL分别见_components-statefulsets.tpl第 1233、1376、1487 行附近的渲染逻辑。由于各组件使用不同的日志框架取值语义略有差异Go 组件scheduler、modelgateway、pipelinegateway、hodometer、agent遵循 logrus 的fatal/error/warn/info/debug/trace级别controller 遵循 zap 级别DataflowKotlin 实现遵循 klogging 级别。关于 Kafka 日志级别的注意事项文档原文明确提示Kafka 客户端库librdkafka期望的是 syslog 风格的级别与组件传入的日志级别体系不同。实现会对传入的日志级别做最佳匹配映射因此dataflow.logLevelKafka设置的值与最终 librdkafka 实际生效级别可能存在细微差异排查 Kafka 相关日志时需留意这一层映射。调优建议全局保持info定位具体问题时用--set单独调高某个组件的级别例如--set dataflow.logLeveldebug --set dataflow.logLevelKafkadebug避免全量开 debug 造成日志洪峰。六、实战如何在安装时应用这些配置6.1 通过--set覆盖单值seldon-core-v2-setup支持所有上述参数例如开启 Model 原生自动缩放并收紧缩容阈值helm install seldon-core-v2 seldon-charts/seldon-core-v2-setup \ --namespace seldon-mesh \ --set autoscaling.autoscalingModelEnabledtrue \ --set autoscaling.autoscalingServerEnabledtrue \ --set agent.modelInactiveSecondsThreshold300 \ --set envoy.enableAccesslogtrue6.2 通过 values 文件批量定制将参数写入自定义 values 文件建议先执行helm show values seldon-charts/seldon-core-v2-setup my-values.yaml再编辑然后helm upgrade --install seldon-core-v2 seldon-charts/seldon-core-v2-setup \ --namespace seldon-mesh \ --values my-values.yaml仓库中的示例文件如 k8s/samples/values-strimzi-kafka-mtls.yaml、k8s/samples/values-tls-dataplane-example.yaml展示了如何叠加安全与 Kafka 配置可作参考。6.3 三个图表的分工与叠加需要注意本文讨论的配置全部位于seldon-core-v2-setup。运行时副本数、组件启停等由 k8s/helm-charts/seldon-core-v2-runtime/values.yaml如envoy.replicas、scheduler.replicas、各组件disable开关控制Server 的副本数则由 k8s/helm-charts/seldon-core-v2-servers/values.yamlmlserver.replicas、triton.replicas等控制。典型安装顺序为详见 helm 安装指南helm install seldon-core-v2-crds seldon-charts/seldon-core-v2-crds helm install seldon-core-v2 seldon-charts/seldon-core-v2-setup --namespace seldon-mesh helm install seldon-v2-runtime seldon-charts/seldon-core-v2-runtime --namespace seldon-mesh helm install seldon-v2-servers seldon-charts/seldon-core-v2-servers --namespace seldon-mesh若采用集群级部署为 setup 图表追加--set controller.clusterwidetrue即可对应 docs-gb/examples/k8s-clusterwide.md 中的示例用法。6.4 验证配置是否生效查看渲染结果helm get manifest seldon-core-v2 --namespace seldon-mesh | grep -A5 LOG_LEVEL\|SERVER_PACKING\|ENABLE_MODEL_AUTOSCALING查看运行时环境变量kubectl exec -n seldon-mesh deploy/seldon-scheduler -- env | grep -E LOG_LEVEL|AUTOSCALING|PACKINGEnvoy 访问日志kubectl exec -n seldon-mesh envoy-pod -- tail -f /tmp/envoy-accesslog.txt七、小结Envoy的preStopSleepPeriodSeconds与terminationGracePeriodSeconds决定了下线时的流量摘除节奏enableAccesslog/includeSuccessfulRequests决定访问日志的开关与粒度底层由 scheduler/pkg/envoy/xdscache/resource.go 生成带状态码过滤器的 Envoy xDS 配置。原生自动缩放实验特性默认对 Server 开启、对 Model 关闭采样周期、lag 阈值、空闲阈值由 Agent 参数控制server packing 默认关闭且代码层强制在未启用时把打包比例置零。Server 模型控制面的 load/unload 超时、重试次数与 unload 宽限期共同决定了模型生命周期管理的健壮性与故障暴露速度overcommitPercentage控制内存超卖密度其计算逻辑见 scheduler/pkg/agent/state_manager.go。日志级别采用“组件级优先、logging.logLevel全局兜底”的策略各组件遵循各自日志框架zap / klogging / logrus / rclone的级别语义Kafka 客户端库级别会经过一次近似映射。配置时请始终以helm show values输出与当前仓库 k8s/helm-charts/seldon-core-v2-setup/values.yaml 为准并结合实际负载逐步调整避免照搬文档默认值造成误配。赞分享人工智能大模型MLOpsLLMOps模型推理服务云原生后端【免费下载链接】seldon-coreAn MLOps framework to package, deploy, monitor and manage thousands of production machine learning models项目地址https://gitcode.com/gh_mirrors/se/seldon-core点击查看免费下载相关推荐Seldon Core 2 基于 HPA 的 Model 自动扩缩容自定义 RPS 指标配置与生产调优实战Seldon Core 2 基于 HPA 的 Model 自动扩缩容自定义 RPS 指标配置与生产调优实战 本篇指南讲解如何在 Seldon Core 2 中人工智能大模型MLOpsLLMOps模型推理服务云原生后端Bitcoin Core 0.7.2 升级指南-detachdb、Berkeley DB 日志兼容与优雅停机机制的修复解析Bitcoin Core 0.7.2 升级指南 detachdb、Berkeley DB 日志兼容与优雅停机机制的修复解析 本篇技术文章以 doc/relea区块链金融科技网络密码学Seldon Core 2 基于模型 RPS 的 HPA 自动扩缩容实战Prometheus Adapter 与 HorizontalPodAutoscaler 配置指南Seldon Core 2 基于模型 RPS 的 HPA 自动扩缩容实战Prometheus Adapter 与 HorizontalPodAutoscale人工智能大模型MLOpsLLMOps模型推理服务云原生后端创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询