使用 litellm-helm 在 Kubernetes 上部署 LiteLLM Proxy参数、数据库、迁移与运维实践【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmLiteLLM Proxy 是一个统一的多模型 AI 网关能以 OpenAI 兼容格式对外提供 100 家 LLM 提供商的接入能力。本文以仓库中的 litellm-helm Helm Chart 为核心讲解如何在 Kubernetes 集群中一键部署 LiteLLM Proxy并围绕主密钥管理、代理配置 ConfigMap、PostgreSQL独立部署或复用外部实例、Prisma 数据库迁移 Job 与管理员 UI 访问这五大主题展开。读完本文你将掌握该 Chart 全部核心参数的用法、生产环境的关键取舍以及如何用 Helm/ArgoCD 驱动一套可持续升级的 LiteLLM Proxy 部署。说明本文面向社区版 litellm-helm ChartChart 版本 1.1.3对应 appVersion v1.85.1见 Chart.yaml。该 Chart 由社区维护如果遇到 Bug 建议向仓库提交 issue生产环境大规模部署更推荐参考 Docker 与 Kubernetes 的官方生产部署建议。前置条件安装本 Chart 需要满足以下版本门槛Kubernetes 1.21Helm 3.8.0另外还需要根据你的数据库选型准备额外前提若使用db.deployStandalone默认开启底层基础设施需要支持PVPersistentVolume供应因为随 Chart 一起部署的独立 PostgreSQL 实例要持久化数据。db.useStackgresOperator目前尚未实现即使将其置为true也不会生效若未来启用需要集群中已预先安装 Stackgres Operator——该 Chart 不会替你安装缺失的 Operator。快速安装默认一套起Chart 默认开启db.deployStandalone即随 Proxy 一起在命名空间内拉起一个单实例 PostgreSQL基于 Bitnami postgresql 子 Chart因此开箱即可完成部署helm repo add litellm oci://ghcr.io/berriai/litellm-helm # 或直接使用仓库内 Chart 源码 helm install litellm ./helm/litellm-helm首次安装时Chart 会生成一个随机的 Master Key 并写入RELEASE-litellm-masterkeySecret后续helm upgrade会复用该 Secret 中的值不会轮换主密钥详见下文“Master Key 机制”一节。安装完成后通过helm status的 NOTES模板见 templates/NOTES.txt可以找到访问方式ClusterIP场景默认使用kubectl port-forward将 4000 端口映射到本地。Proxy 部署参数详解镜像、副本与服务参数说明默认值replicaCountLiteLLM Proxy 的 Pod 副本数1image.repositoryLiteLLM Proxy 镜像仓库ghcr.io/berriai/litellmimage.pullPolicy镜像拉取策略IfNotPresentvalues.yaml 中默认Always两者均以实际 rendered 值为准image.tag覆盖镜像标签留空时使用 Chart 发布时的默认版本imagePullSecrets私有镜像仓库凭据[]serviceAccount.create是否创建专用 ServiceAccount默认关闭是因为 LiteLLM 无需访问 Kubernetes APIfalseservice.typeService 类型ClusterIP/LoadBalancer等ClusterIPservice.portService 监听端口同时也是 Pod 内 Proxy 监听端口4000service.loadBalancerClass可选 LoadBalancer 实现类仅service.typeLoadBalancer时使用例如tailscaleresources.*CPU/内存 requests 与 limits{}不设pdb.*PodDisruptionBudget 开关、minAvailable/maxUnavailable二选一、annotations、labelsenabledfalse其余为空关于replicaCount有一个值得注意的实现细节在 templates/deployment.yaml 中当 KEDA 或 HPA 开启时模板会跳过spec.replicas的渲染交由自动扩缩器接管副本数。这一点与 values.yaml 中autoscaling/keda的配置相互呼应详见后文“自动扩缩容”小节。resources默认刻意留空目的是让 Chart 能装在 Minikube 这类小型集群上、且升级不会让 Pod 一直 Pending但生产环境建议按“每个 worker 约 1 CPU 与 4Gi 内存”设定 requests/limitsvalues.yaml 中注明了该经验值并提示结合--num_workers同步放大。低于该水位流量与数据库连接增多后 Pod 很容易被 OOMKilled。健康检查探针Chart 为网关容器注入了三类探针可在 values.yaml 中分别覆盖path、initialDelaySeconds、periodSeconds、timeoutSeconds、successThreshold、failureThresholdlivenessProbe存活探针默认路径/health/liveliness默认每 15 秒探测、连续 5 次失败重启。readinessProbe就绪探针默认路径/health/readiness默认每 10 秒探测、连续 3 次失败摘除流量。startupProbe启动探针默认路径/health/readiness默认每 10 秒一次、最多容忍 30 次失败最长约 300 秒避免慢启动容器被误杀。这些默认值均来自 values.yaml而渲染后的 httpGet 探针挂到名为http的容器端口上见 templates/deployment.yaml。优雅下线与生命周期钩子values.yaml 提供了一个值得在生产启用的运维细节通过lifecycle.preStop.httpGet指向/health/drain端点实现优雅下线——该端点会把 Pod 标记为 NotReady并只在进行中的请求真正结束后才放行而不是像固定sleep那样总是等待最坏时长。由于/health/drain默认关闭需要先在proxy_config.general_settings里设置enable_drain_endpoint: true同时 kubelet 调用 preStop 钩子时不携带 Proxy 凭据若健康端口可从其他 Pod 访问还应设置drain_endpoint_token或环境变量DRAIN_ENDPOINT_TOKEN并让钩子通过X-Drain-Token请求头发送同一值。缺少或错误的 token 会得到 401 且不产生副作用。terminationGracePeriodSeconds默认 90 秒应略高于GRACEFUL_SHUTDOWN_TIMEOUT默认 30s为 SIGTERM 后的清理留出余量。Master Key 机制从自动生成到外部 SecretLiteLLM Proxy 的 Master Key 是管理员访问的关键凭据Chart 提供了三种取值方式参数说明默认masterkey直接指定 Master Key不指定时首次安装自动生成sk-...格式随机串并在升级时复用N/AmasterkeySecretName指定存放 Master Key 的既有 Kubernetes Secret 名称N/A默认用生成出的 Secret 名masterkeySecretKey上述 Secret 中存放 Master Key 的键名masterkey其底层逻辑可在 templates/secret-masterkey.yaml 中看到只要未显式提供masterkeySecretName模板会先lookup命名空间中已存在的fullname-masterkeySecret若找到则b64dec解码复用其中的masterkey值找不到才用printf sk-%s (randAlphaNum 18)生成新随机密钥。这正是“首次安装生成、之后升级永不轮换”的原因。在 templates/deployment.yaml 中该 Secret 的值会以secretKeyRef方式注入为PROXY_MASTER_KEY环境变量并被默认配置里的os.environ/PROXY_MASTER_KEY引用见下节。若想完全自管密钥可先创建自己的 Secret再通过masterkeySecretName/masterkeySecretKey指向它Chart 便不再生成-masterkeySecret。代理配置proxy_config、ConfigMap 与 os.environ 引用LiteLLM Proxy 通过一份 YAML 配置model_list、router_settings、general_settings 等描述“路由哪些模型、用什么凭据、开什么功能”。从 values 渲染 ConfigMap默认方式Chart 默认把 values 中的proxy_config渲染成 ConfigMap 并挂载进 Pod。相关参数参数说明默认值proxyConfigMap.create为true时由 Chart 渲染并挂载一个 ConfigMaptrueproxyConfigMap.namecreatefalse时指定要挂载的既有 ConfigMap 名称proxyConfigMap.keyConfigMap 中存放配置的键config.yamlproxy_config.*渲染进config.yaml的完整代理配置见 values.yamlN/A默认的proxy_config长这样proxy_config: general_settings: master_key: os.environ/PROXY_MASTER_KEY model_list: - model_name: gpt-3.5-turbo litellm_params: model: gpt-3.5-turbo api_key: eXaMpLeOnLy注意master_key的取值是os.environ/PROXY_MASTER_KEY——这是 LiteLLM 配置中引用环境变量的标准写法Proxy 启动时会从PROXY_MASTER_KEY环境变量即上一节注入的 Secret 值读取真实密钥。生产环境切勿把明文密钥写死在proxy_config的 values 里因为那样密钥会进入 Helm release 与 ConfigMap。渲染逻辑见 templates/configmap-litellm.yaml模板对.Values.proxy_config做deepCopy后toYaml输出为 ConfigMap 的config.yaml键。而 templates/deployment.yaml 会以subPath: config.yaml方式把该键挂载到容器的/etc/litellm/config.yaml同时给容器注入启动参数--config /etc/litellm/config.yaml可用--num_workers声明 worker 数。此外Pod 模板上的注解checksum/config会对 ConfigMap 内容做sha256sum配置一旦变化即触发滚动升级无需手动重启。更丰富的真实配置示例可以参考仓库内 litellm/proxy/example_config_yaml/ 目录下的 20 份 YAML含 simple_config.yaml、azure_config.yaml、load_balancer.yaml 等。复用既有 ConfigMap如果希望配置完全脱离 Helm 生命周期管理可以关闭自动渲染并指向已有对象proxyConfigMap: create: false name: my-litellm-config key: config.yaml # 此模式下 proxy_config 被忽略挂载机制不变——只要 ConfigMap 中存在名为config.yaml的键即可。注入敏感配置environmentSecrets 与 environmentConfigMapsProxy 所需的 API Key、数据库密码等凭据最好以“Secret/ConfigMap → 环境变量”的方式注入而不是写进 proxy_config。Chart 提供两个数组参数参数说明默认environmentSecrets一组 Secret 名称其键值会以环境变量形式注入 Proxy Pod[]environmentConfigMaps一组 ConfigMap 名称其键值会以环境变量形式注入 Proxy Pod[]在 templates/deployment.yaml 中这些对象分别通过envFrom.secretRef与envFrom.configMapRef展开。注入后的变量就可以在proxy_config中用os.environ/Env Var Name引用。官方 README 给出的示例 Secret 结构如下apiVersion: v1 kind: Secret metadata: name: litellm-envsecrets data: AZURE_OPENAI_API_KEY: TXlTZWN1cmVLM3k type: Opaque使用时在 values 里声明environmentSecrets: [litellm-envsecrets]随后配置中写api_key: os.environ/AZURE_OPENAI_API_KEY。同理非机密类配置可用 ConfigMapapiVersion: v1 kind: ConfigMap metadata: name: litellm-env-configmap data: SOME_KEY: someValue ANOTHER_KEY: anotherValueKubernetes Secret 的 value 需要 base64 编码echo -n value | base64如需查看原始值可用base64 --decode。Chart 在 values.yaml 中还建议了与之互补的envVars、extraEnvVars与logLevel注入LITELLM_LOG默认INFO等直接环境变量入口——注意直接env:条目在 Kubernetes 中优先于envFrom:来源从 Secret/ConfigMap 注入同名变量时可能被覆盖。企业版计费计量billingMetrics可选对于持有企业 License 的部署该 Chart 支持“可计费请求计量”billable-request meteringProxy 统计发往推理、MCP 与 A2A 端点的成功请求并通过mTLS把计数器推送到 LiteLLM 的采集端点。参数说明默认值billingMetrics.enabled开启企业版可计费请求计量需企业 LicensefalsebillingMetrics.endpoint接收计数器的采集端点https://telemetry.litellm.aibillingMetrics.secretName存放 mTLS 客户端证书的既有 Secret 名键为tls.crt、tls.keylitellm-billing-metrics-mtlsbillingMetrics.caSecretName存放 CA 证书的既有 Secret 名键为ca.crt仅当采集端为私有/测试环境、其服务端证书不在公共 Web PKI 时才需要billingMetrics.exportIntervalMs推送计数的时间间隔毫秒Proxy 端未设置时默认60000启用步骤先创建存放客户端证书的 SecretChart不会代建证书只负责把已有证书只读挂载进容器私钥不经过环境变量避免泄露kubectl create secret tls litellm-billing-metrics-mtls --certclient.crt --keyclient.key然后在 values 中开启billingMetrics: enabled: true从源码看开启后 templates/_helpers.tpl 会注入LITELLM_BILLING_METRICS_ENDPOINT、LITELLM_BILLING_METRICS_CLIENT_CERT、LITELLM_BILLING_METRICS_CLIENT_KEY以及可选的_CA_CERT、_EXPORT_INTERVAL_MS环境变量并把 Secret 以只读方式挂载到/etc/litellm/billing-mtls和可选的-ca目录。为防止“静默不导出”模板对endpoint与secretName使用了required校验缺失或把 endpoint 置空时helm install阶段会直接渲染失败而不是部署一个永远不推送计数的 Proxy。数据库选型随包部署还是复用外部 PostgreSQLLiteLLM Proxy 需要 PostgreSQL 存储虚拟 API Key、Spend Log、Team/用户等管理数据。Chart 支持三种方式参数说明默认db.useExisting复用外部 PostgreSQL需先提供含连接凭据的 Kubernetes Secretfalsedb.deployStandalone随 Chart 部署单实例 PostgreSQLBitnami postgresql 子 Chart适合快速起步无 HA、默认无备份truedb.useStackgresOperator使用 Stackgres 部署集群未实现false方式一随包部署deployStandalone默认db.deployStandalonetrue会拉取 postgresql 子 Chart版本 14.3.1见 Chart.yaml 的 dependencies并同步创建release-dbcredentialsSecret 供 Proxy 与迁移 Job 使用见 templates/secret-dbcredentials.yaml。涉及参数postgresql.*透传给 Bitnami postgresql 子 Chart 的全部配置默认值见 values.yaml。postgresql.auth.*数据库账号密码。默认值是NoTaGrEaTpAsSwOrD——务必通过命令行覆盖helm install litellm ./helm/litellm-helm \ --set postgresql.auth.postgres-password强密码 \ --set postgresql.auth.password强密码postgresql.image.*随包 Postgres 的镜像。关于镜像有一个重要坑Bitnami 已从docker.io/bitnami下架了带版本号的 tag并把归档构建迁移到docker.io/bitnamilegacy因此子 Chart 自带的镜像默认值已无法拉取。本 Chart 把随包 Postgres 钉死在bitnamilegacy/postgresql:16.2.0-debian-12-r6与子 Chart 发布时使用的构建一致从而保证既有安装的数据目录布局不变。该镜像不再接收更新因此仅适合“快速起步”正式环境应把 Postgres 跑在 Chart 之外用db.useExisting指向它。请务必保持postgresql.image.tag钉死docker.io/bitnami/postgresql仍发布浮动的latest若让随包 Postgres 以不同的主版本启动会直接对着它读不了的旧数据目录启动报错database files are incompatible with server且没有原地回退的办法——跨大版本必须先用旧镜像 dump、再用新镜像 restore。为此Chart 在渲染dbcredentialsSecret 时templates/secret-dbcredentials.yaml 调用的litellm.validateBundledPostgresImageTag定义于 templates/_helpers.tpl会执行校验tag 为空或为latest时直接fail拒绝渲染。方式二复用外部 PostgreSQLuseExisting将db.useExisting置为true后需要先准备一个含凭据的 Secret下方示例中的默认名称为postgresapiVersion: v1 kind: Secret metadata: name: postgres data: # postgres 用户的密码 postgres-password: some secure password, base64 encoded username: litellm password: some secure password, base64 encoded type: Opaque相关参数参数说明默认值db.endpoint外部 PostgreSQL 的 IP/主机名/服务名localhostdb.database数据库名litellmdb.url完整的连接串可覆盖上述单点参数postgresql://$(DATABASE_USERNAME):$(DATABASE_PASSWORD)$(DATABASE_HOST)/$(DATABASE_NAME)db.secret.name存放凭据的 Secret 名称postgresdb.secret.usernameKeySecret 中用户名字段的键usernamedb.secret.passwordKeySecret 中密码字段的键password在 templates/deployment.yaml 中DATABASE_USERNAME、DATABASE_PASSWORD、DATABASE_HOST、DATABASE_NAME都会从该 Secret 经secretKeyRef注入DATABASE_URL则默认通过带$(VAR)占位符的连接串在容器启动时解析。values.yaml 还支持额外的只读副本参数db.readReplicaUrl、db.secret.readReplicaUrlKey与db.secret.readReplicaEndpointKey可将DATABASE_URL_READ_REPLICA/DATABASE_READER_HOST指向只读端点适合 Aurora 风格的读写分离。官方特别提醒若只读连接串内嵌凭据优先用readReplicaUrlKey从 Secret 取值避免明文出现在 rendered Pod spec 与 Helm release Secret 中。内置 Redis跨 Pod 协调可选注Redis 配置细节主要在 values.yaml 中说明README 正文未展开此处作为对生产能力的补充。Redis 是 Proxy 的协调存储负责跨 Pod 的 tpm/rpm 限流、Spend 追踪与 Pod 锁管理器。将redis.enabled置为true会部署随包 Redis 子 Chart版本 18.19.1见 Chart.yaml自动注入REDIS_HOST/REDIS_PORT/REDIS_PASSWORD环境变量并在 templates/configmap-litellm.yaml 中自动往general_settings追加coordination_redis块若你自己已在proxy_config里定义了该块则以你的为准。若redis.sentinel.enabled开启则会改渲染sentinel_nodesservice_name组合。若要接入已有 Redis保持enabled: false并自行注入REDIS_HOST等环境变量即可coordination_redis仅与协调相关与 LLM 响应缓存需在配置中设cache: true相互独立。随包 Redis 的镜像同样被重定向到bitnamilegacy/redis:7.2.4-debian-12-r9。自动扩缩容与稳定性Chart 同时支持基于内置的 HPAautoscaling与基于事件的 KEDAkeda两者互斥同时开启只会以 KEDA 渲染的副本为准。扩展入口位于 templates/hpa.yaml 与 templates/keda.yaml。autoscaling默认关闭minReplicas1、maxReplicas100。文档推荐的targetCPUUtilizationPercentage为 60CPU 目标不宜设得过高因为新副本要先过掉 startupProbe最多约 300 秒才承接流量过高的阈值会在接近饱和时才扩容、滞后数分钟。values.yaml 中刻意不给内存目标设值Prisma 查询引擎的常驻内存是“高水位”型——它会一路涨到 Pod 历史最坏写入量且不回落导致按内存扩容的副本只升不降ratchet 效应。内存应作为resources下的供应下限而非扩缩容信号。pdb开启后为 Deployment 提供自愿中断保护minAvailable与maxUnavailable必须二选一两者都设时minAvailable优先。terminationGracePeriodSeconds默认 90 秒strategy可用于配置 RollingUpdate如maxUnavailable: 0、maxSurge: 1。KEDA 场景还可在keda.triggers里声明 Prometheus 等触发源并配置cooldownPeriod、pollingInterval与scaleDown/scaleUp策略values.yaml 中提供了带注释的完整样例。数据库迁移 Jobschema 谁来做数据库表结构的创建与升级由一个独立的一次性 Job负责而不是让每个副本在启动时竞争执行。相关参数参数说明默认值migrationJob.enabled是否启用 schema 迁移 JobtruemigrationJob.backoffLimitJob 重启的 backoff 上限4migrationJob.ttlSecondsAfterFinished完成后 Job 的自动清理 TTL120migrationJob.annotations迁移 Pod 的附加注解{}migrationJob.extraContainers与迁移 Job 并跑的附加容器[]migrationJob.hooks.argocd.enabled启用 ArgoCD 钩子PreSync 钩子 BeforeHookCreation删除策略truemigrationJob.hooks.helm.enabled启用 Helm 钩子pre-install,pre-upgradebefore-hook-creation删除策略falsemigrationJob.hooks.helm.weightHelm 钩子执行顺序权重越小越先执行可选缺省为1N/A其模板见 templates/migrations-job.yamlJob 的容器以command: [python, litellm/proxy/prisma_migration.py]启动对应源码 litellm/proxy/prisma_migration.py并把DISABLE_SCHEMA_UPDATE显式置为false强制执行迁移。与 Job 配合的两个关键设计源码中均有体现Proxy 副本跳过 schema 自检当migrationJob.enabledtrue时templates/deployment.yaml 会给 Proxy 注入DISABLE_SCHEMA_UPDATEtrue从而关闭 Proxy 启动时的prisma db push避免 N 个副本在每次滚动发布时互相竞争同一数据库。该覆盖项被刻意放在 envVars/extraEnvVars 之后渲染防止用户自定义的同名变量把它顶掉。GitOps 双钩子支持ArgoCD 场景使用argocd.argoproj.io/hook: PreSync在同步应用前先跑迁移纯 Helm 场景可开启migrationJob.hooks.helm.enabled使用pre-install,pre-upgrade钩子。两者都配了BeforeHookCreation/before-hook-creation删除策略保证每次部署前旧的迁移 Job 会被清除。values.yaml 中另外提供了两个安全兜底migrationJob.activeDeadlineSeconds1800整个 Job 的墙钟预算共享给所有重试防止迁移阻塞时helm upgrade/GitOps 控制器无限期卡死可置null恢复不设限、migrationJob.disableSchemaUpdate跳过 schema 迁移并让 Job 以 0 退出。访问 Admin UI 与密钥取回填入端点与主密钥部署就绪后浏览器访问ingress.*发布的 URL页面会要求Admin Configuration配置Proxy Endpoint填入从litellmPod 视角看的内网 Service URL。使用默认 Service 设置时应填http://RELEASE-litellm:4000。Proxy Key填入masterkey参数值若安装时未指定则是 Chart 首次安装时随机生成、存储在RELEASE-litellm-masterkeySecret 中的sk-...字符串。通过 kubectl 取回主密钥忘记主密钥时可用如下命令从 Secret 读取kubectl -n litellm get secret RELEASE-litellm-masterkey -o jsonpath{.data.masterkey}注意该命令输出的仍是 base64 编码需要解码后使用如... | base64 --decode。再次强调该值只在首次安装时生成之后的helm upgrade都会复用 Secret 中已有值升级不会导致主密钥轮换。Admin UI 的已知限制截至本文写作时Admin UI无法通过界面新增模型。原因在于添加模型需要更新config.yaml而该文件来自挂载的 ConfigMap对运行中的 Pod 是只读的。这是当前 Helm Chart 的架构性限制而非 Admin UI 本身的功能缺陷。需要变更模型路由时应回到proxy_config或外部 ConfigMap修改并重新helm upgrade借助上文提到的checksum/config注解自动触发滚动更新。常见生产问题速查现象原因与处理helm install渲染失败报postgresql.image.tag相关 fail随包 Postgres 的镜像 tag 为空或为latest被validateBundledPostgresImageTag校验拦下必须钉死为具体版本docker.io/bitnami/postgresql拉取 404Bitnami 已下架带版本号 tag使用默认的bitnamilegacy/postgresql:16.2.0-debian-12-r6即可升级后 Postgres 拒绝启动提示database files are incompatible with server跨了 PostgreSQL 主版本升级无法原地回退需用旧镜像 dump、新镜像 restoreProxy 启动后多副本同时改库migrationJob.enabledtrue时 Proxy 被注入DISABLE_SCHEMA_UPDATEtrueschema 迁移统一由迁移 Job 执行helm upgrade后 Pod 配置未刷新正常情况下checksum/config注解会触发滚动更新若用proxyConfigMap.createfalse的外部 ConfigMap需自行保证内容变更可被感知Pod 反复 OOMKilledresources未按“每 worker 约 1 CPU / 4Gi”设置或副本未随--num_workers同步放大总结与延伸阅读litellm-helm 的价值在于把“LiteLLM Proxy PostgreSQL 迁移 Job”打包成一套可直接helm install、又能渐进式替换外部依赖的部署单元。要点可归纳为四条主线配置即代码proxy_config渲染进只读 ConfigMap模型/路由变更走helm upgrade滚动生效API Key 一律通过os.environ/...引用注入的环境变量避免明文入库。密钥自动管理Master Key 首次生成、升级复用也可完全交给外部 Secret。数据库两态deployStandalone适合体验与 CI生产建议useExisting指向托管 PostgreSQL并注意镜像 tag 钉死与跨版本迁移策略。迁移与 GitOpsPrisma schema 迁移由独立 Job 承担天然支持 ArgoCD PreSync 与 Helm pre-install/pre-upgrade 两种编排。对某一类配置想深入了解时可对照源码继续钻研values.yaml所有参数与注释、templates/渲染逻辑、helm/litellm-helm/tests/Chart 自测用例、litellm/proxy/example_config_yaml/LiteLLM 侧真实配置样例。若 Chart 版本与 Proxy 镜像需要同步升级直接修改 Chart.yaml 中的appVersion或覆盖image.tag即可。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 litellm-helm 在 Kubernetes 上部署 LiteLLM Proxy：参数、数据库、迁移与运维实践
使用 litellm-helm 在 Kubernetes 上部署 LiteLLM Proxy参数、数据库、迁移与运维实践【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmLiteLLM Proxy 是一个统一的多模型 AI 网关能以 OpenAI 兼容格式对外提供 100 家 LLM 提供商的接入能力。本文以仓库中的 litellm-helm Helm Chart 为核心讲解如何在 Kubernetes 集群中一键部署 LiteLLM Proxy并围绕主密钥管理、代理配置 ConfigMap、PostgreSQL独立部署或复用外部实例、Prisma 数据库迁移 Job 与管理员 UI 访问这五大主题展开。读完本文你将掌握该 Chart 全部核心参数的用法、生产环境的关键取舍以及如何用 Helm/ArgoCD 驱动一套可持续升级的 LiteLLM Proxy 部署。说明本文面向社区版 litellm-helm ChartChart 版本 1.1.3对应 appVersion v1.85.1见 Chart.yaml。该 Chart 由社区维护如果遇到 Bug 建议向仓库提交 issue生产环境大规模部署更推荐参考 Docker 与 Kubernetes 的官方生产部署建议。前置条件安装本 Chart 需要满足以下版本门槛Kubernetes 1.21Helm 3.8.0另外还需要根据你的数据库选型准备额外前提若使用db.deployStandalone默认开启底层基础设施需要支持PVPersistentVolume供应因为随 Chart 一起部署的独立 PostgreSQL 实例要持久化数据。db.useStackgresOperator目前尚未实现即使将其置为true也不会生效若未来启用需要集群中已预先安装 Stackgres Operator——该 Chart 不会替你安装缺失的 Operator。快速安装默认一套起Chart 默认开启db.deployStandalone即随 Proxy 一起在命名空间内拉起一个单实例 PostgreSQL基于 Bitnami postgresql 子 Chart因此开箱即可完成部署helm repo add litellm oci://ghcr.io/berriai/litellm-helm # 或直接使用仓库内 Chart 源码 helm install litellm ./helm/litellm-helm首次安装时Chart 会生成一个随机的 Master Key 并写入RELEASE-litellm-masterkeySecret后续helm upgrade会复用该 Secret 中的值不会轮换主密钥详见下文“Master Key 机制”一节。安装完成后通过helm status的 NOTES模板见 templates/NOTES.txt可以找到访问方式ClusterIP场景默认使用kubectl port-forward将 4000 端口映射到本地。Proxy 部署参数详解镜像、副本与服务参数说明默认值replicaCountLiteLLM Proxy 的 Pod 副本数1image.repositoryLiteLLM Proxy 镜像仓库ghcr.io/berriai/litellmimage.pullPolicy镜像拉取策略IfNotPresentvalues.yaml 中默认Always两者均以实际 rendered 值为准image.tag覆盖镜像标签留空时使用 Chart 发布时的默认版本imagePullSecrets私有镜像仓库凭据[]serviceAccount.create是否创建专用 ServiceAccount默认关闭是因为 LiteLLM 无需访问 Kubernetes APIfalseservice.typeService 类型ClusterIP/LoadBalancer等ClusterIPservice.portService 监听端口同时也是 Pod 内 Proxy 监听端口4000service.loadBalancerClass可选 LoadBalancer 实现类仅service.typeLoadBalancer时使用例如tailscaleresources.*CPU/内存 requests 与 limits{}不设pdb.*PodDisruptionBudget 开关、minAvailable/maxUnavailable二选一、annotations、labelsenabledfalse其余为空关于replicaCount有一个值得注意的实现细节在 templates/deployment.yaml 中当 KEDA 或 HPA 开启时模板会跳过spec.replicas的渲染交由自动扩缩器接管副本数。这一点与 values.yaml 中autoscaling/keda的配置相互呼应详见后文“自动扩缩容”小节。resources默认刻意留空目的是让 Chart 能装在 Minikube 这类小型集群上、且升级不会让 Pod 一直 Pending但生产环境建议按“每个 worker 约 1 CPU 与 4Gi 内存”设定 requests/limitsvalues.yaml 中注明了该经验值并提示结合--num_workers同步放大。低于该水位流量与数据库连接增多后 Pod 很容易被 OOMKilled。健康检查探针Chart 为网关容器注入了三类探针可在 values.yaml 中分别覆盖path、initialDelaySeconds、periodSeconds、timeoutSeconds、successThreshold、failureThresholdlivenessProbe存活探针默认路径/health/liveliness默认每 15 秒探测、连续 5 次失败重启。readinessProbe就绪探针默认路径/health/readiness默认每 10 秒探测、连续 3 次失败摘除流量。startupProbe启动探针默认路径/health/readiness默认每 10 秒一次、最多容忍 30 次失败最长约 300 秒避免慢启动容器被误杀。这些默认值均来自 values.yaml而渲染后的 httpGet 探针挂到名为http的容器端口上见 templates/deployment.yaml。优雅下线与生命周期钩子values.yaml 提供了一个值得在生产启用的运维细节通过lifecycle.preStop.httpGet指向/health/drain端点实现优雅下线——该端点会把 Pod 标记为 NotReady并只在进行中的请求真正结束后才放行而不是像固定sleep那样总是等待最坏时长。由于/health/drain默认关闭需要先在proxy_config.general_settings里设置enable_drain_endpoint: true同时 kubelet 调用 preStop 钩子时不携带 Proxy 凭据若健康端口可从其他 Pod 访问还应设置drain_endpoint_token或环境变量DRAIN_ENDPOINT_TOKEN并让钩子通过X-Drain-Token请求头发送同一值。缺少或错误的 token 会得到 401 且不产生副作用。terminationGracePeriodSeconds默认 90 秒应略高于GRACEFUL_SHUTDOWN_TIMEOUT默认 30s为 SIGTERM 后的清理留出余量。Master Key 机制从自动生成到外部 SecretLiteLLM Proxy 的 Master Key 是管理员访问的关键凭据Chart 提供了三种取值方式参数说明默认masterkey直接指定 Master Key不指定时首次安装自动生成sk-...格式随机串并在升级时复用N/AmasterkeySecretName指定存放 Master Key 的既有 Kubernetes Secret 名称N/A默认用生成出的 Secret 名masterkeySecretKey上述 Secret 中存放 Master Key 的键名masterkey其底层逻辑可在 templates/secret-masterkey.yaml 中看到只要未显式提供masterkeySecretName模板会先lookup命名空间中已存在的fullname-masterkeySecret若找到则b64dec解码复用其中的masterkey值找不到才用printf sk-%s (randAlphaNum 18)生成新随机密钥。这正是“首次安装生成、之后升级永不轮换”的原因。在 templates/deployment.yaml 中该 Secret 的值会以secretKeyRef方式注入为PROXY_MASTER_KEY环境变量并被默认配置里的os.environ/PROXY_MASTER_KEY引用见下节。若想完全自管密钥可先创建自己的 Secret再通过masterkeySecretName/masterkeySecretKey指向它Chart 便不再生成-masterkeySecret。代理配置proxy_config、ConfigMap 与 os.environ 引用LiteLLM Proxy 通过一份 YAML 配置model_list、router_settings、general_settings 等描述“路由哪些模型、用什么凭据、开什么功能”。从 values 渲染 ConfigMap默认方式Chart 默认把 values 中的proxy_config渲染成 ConfigMap 并挂载进 Pod。相关参数参数说明默认值proxyConfigMap.create为true时由 Chart 渲染并挂载一个 ConfigMaptrueproxyConfigMap.namecreatefalse时指定要挂载的既有 ConfigMap 名称proxyConfigMap.keyConfigMap 中存放配置的键config.yamlproxy_config.*渲染进config.yaml的完整代理配置见 values.yamlN/A默认的proxy_config长这样proxy_config: general_settings: master_key: os.environ/PROXY_MASTER_KEY model_list: - model_name: gpt-3.5-turbo litellm_params: model: gpt-3.5-turbo api_key: eXaMpLeOnLy注意master_key的取值是os.environ/PROXY_MASTER_KEY——这是 LiteLLM 配置中引用环境变量的标准写法Proxy 启动时会从PROXY_MASTER_KEY环境变量即上一节注入的 Secret 值读取真实密钥。生产环境切勿把明文密钥写死在proxy_config的 values 里因为那样密钥会进入 Helm release 与 ConfigMap。渲染逻辑见 templates/configmap-litellm.yaml模板对.Values.proxy_config做deepCopy后toYaml输出为 ConfigMap 的config.yaml键。而 templates/deployment.yaml 会以subPath: config.yaml方式把该键挂载到容器的/etc/litellm/config.yaml同时给容器注入启动参数--config /etc/litellm/config.yaml可用--num_workers声明 worker 数。此外Pod 模板上的注解checksum/config会对 ConfigMap 内容做sha256sum配置一旦变化即触发滚动升级无需手动重启。更丰富的真实配置示例可以参考仓库内 litellm/proxy/example_config_yaml/ 目录下的 20 份 YAML含 simple_config.yaml、azure_config.yaml、load_balancer.yaml 等。复用既有 ConfigMap如果希望配置完全脱离 Helm 生命周期管理可以关闭自动渲染并指向已有对象proxyConfigMap: create: false name: my-litellm-config key: config.yaml # 此模式下 proxy_config 被忽略挂载机制不变——只要 ConfigMap 中存在名为config.yaml的键即可。注入敏感配置environmentSecrets 与 environmentConfigMapsProxy 所需的 API Key、数据库密码等凭据最好以“Secret/ConfigMap → 环境变量”的方式注入而不是写进 proxy_config。Chart 提供两个数组参数参数说明默认environmentSecrets一组 Secret 名称其键值会以环境变量形式注入 Proxy Pod[]environmentConfigMaps一组 ConfigMap 名称其键值会以环境变量形式注入 Proxy Pod[]在 templates/deployment.yaml 中这些对象分别通过envFrom.secretRef与envFrom.configMapRef展开。注入后的变量就可以在proxy_config中用os.environ/Env Var Name引用。官方 README 给出的示例 Secret 结构如下apiVersion: v1 kind: Secret metadata: name: litellm-envsecrets data: AZURE_OPENAI_API_KEY: TXlTZWN1cmVLM3k type: Opaque使用时在 values 里声明environmentSecrets: [litellm-envsecrets]随后配置中写api_key: os.environ/AZURE_OPENAI_API_KEY。同理非机密类配置可用 ConfigMapapiVersion: v1 kind: ConfigMap metadata: name: litellm-env-configmap data: SOME_KEY: someValue ANOTHER_KEY: anotherValueKubernetes Secret 的 value 需要 base64 编码echo -n value | base64如需查看原始值可用base64 --decode。Chart 在 values.yaml 中还建议了与之互补的envVars、extraEnvVars与logLevel注入LITELLM_LOG默认INFO等直接环境变量入口——注意直接env:条目在 Kubernetes 中优先于envFrom:来源从 Secret/ConfigMap 注入同名变量时可能被覆盖。企业版计费计量billingMetrics可选对于持有企业 License 的部署该 Chart 支持“可计费请求计量”billable-request meteringProxy 统计发往推理、MCP 与 A2A 端点的成功请求并通过mTLS把计数器推送到 LiteLLM 的采集端点。参数说明默认值billingMetrics.enabled开启企业版可计费请求计量需企业 LicensefalsebillingMetrics.endpoint接收计数器的采集端点https://telemetry.litellm.aibillingMetrics.secretName存放 mTLS 客户端证书的既有 Secret 名键为tls.crt、tls.keylitellm-billing-metrics-mtlsbillingMetrics.caSecretName存放 CA 证书的既有 Secret 名键为ca.crt仅当采集端为私有/测试环境、其服务端证书不在公共 Web PKI 时才需要billingMetrics.exportIntervalMs推送计数的时间间隔毫秒Proxy 端未设置时默认60000启用步骤先创建存放客户端证书的 SecretChart不会代建证书只负责把已有证书只读挂载进容器私钥不经过环境变量避免泄露kubectl create secret tls litellm-billing-metrics-mtls --certclient.crt --keyclient.key然后在 values 中开启billingMetrics: enabled: true从源码看开启后 templates/_helpers.tpl 会注入LITELLM_BILLING_METRICS_ENDPOINT、LITELLM_BILLING_METRICS_CLIENT_CERT、LITELLM_BILLING_METRICS_CLIENT_KEY以及可选的_CA_CERT、_EXPORT_INTERVAL_MS环境变量并把 Secret 以只读方式挂载到/etc/litellm/billing-mtls和可选的-ca目录。为防止“静默不导出”模板对endpoint与secretName使用了required校验缺失或把 endpoint 置空时helm install阶段会直接渲染失败而不是部署一个永远不推送计数的 Proxy。数据库选型随包部署还是复用外部 PostgreSQLLiteLLM Proxy 需要 PostgreSQL 存储虚拟 API Key、Spend Log、Team/用户等管理数据。Chart 支持三种方式参数说明默认db.useExisting复用外部 PostgreSQL需先提供含连接凭据的 Kubernetes Secretfalsedb.deployStandalone随 Chart 部署单实例 PostgreSQLBitnami postgresql 子 Chart适合快速起步无 HA、默认无备份truedb.useStackgresOperator使用 Stackgres 部署集群未实现false方式一随包部署deployStandalone默认db.deployStandalonetrue会拉取 postgresql 子 Chart版本 14.3.1见 Chart.yaml 的 dependencies并同步创建release-dbcredentialsSecret 供 Proxy 与迁移 Job 使用见 templates/secret-dbcredentials.yaml。涉及参数postgresql.*透传给 Bitnami postgresql 子 Chart 的全部配置默认值见 values.yaml。postgresql.auth.*数据库账号密码。默认值是NoTaGrEaTpAsSwOrD——务必通过命令行覆盖helm install litellm ./helm/litellm-helm \ --set postgresql.auth.postgres-password强密码 \ --set postgresql.auth.password强密码postgresql.image.*随包 Postgres 的镜像。关于镜像有一个重要坑Bitnami 已从docker.io/bitnami下架了带版本号的 tag并把归档构建迁移到docker.io/bitnamilegacy因此子 Chart 自带的镜像默认值已无法拉取。本 Chart 把随包 Postgres 钉死在bitnamilegacy/postgresql:16.2.0-debian-12-r6与子 Chart 发布时使用的构建一致从而保证既有安装的数据目录布局不变。该镜像不再接收更新因此仅适合“快速起步”正式环境应把 Postgres 跑在 Chart 之外用db.useExisting指向它。请务必保持postgresql.image.tag钉死docker.io/bitnami/postgresql仍发布浮动的latest若让随包 Postgres 以不同的主版本启动会直接对着它读不了的旧数据目录启动报错database files are incompatible with server且没有原地回退的办法——跨大版本必须先用旧镜像 dump、再用新镜像 restore。为此Chart 在渲染dbcredentialsSecret 时templates/secret-dbcredentials.yaml 调用的litellm.validateBundledPostgresImageTag定义于 templates/_helpers.tpl会执行校验tag 为空或为latest时直接fail拒绝渲染。方式二复用外部 PostgreSQLuseExisting将db.useExisting置为true后需要先准备一个含凭据的 Secret下方示例中的默认名称为postgresapiVersion: v1 kind: Secret metadata: name: postgres data: # postgres 用户的密码 postgres-password: some secure password, base64 encoded username: litellm password: some secure password, base64 encoded type: Opaque相关参数参数说明默认值db.endpoint外部 PostgreSQL 的 IP/主机名/服务名localhostdb.database数据库名litellmdb.url完整的连接串可覆盖上述单点参数postgresql://$(DATABASE_USERNAME):$(DATABASE_PASSWORD)$(DATABASE_HOST)/$(DATABASE_NAME)db.secret.name存放凭据的 Secret 名称postgresdb.secret.usernameKeySecret 中用户名字段的键usernamedb.secret.passwordKeySecret 中密码字段的键password在 templates/deployment.yaml 中DATABASE_USERNAME、DATABASE_PASSWORD、DATABASE_HOST、DATABASE_NAME都会从该 Secret 经secretKeyRef注入DATABASE_URL则默认通过带$(VAR)占位符的连接串在容器启动时解析。values.yaml 还支持额外的只读副本参数db.readReplicaUrl、db.secret.readReplicaUrlKey与db.secret.readReplicaEndpointKey可将DATABASE_URL_READ_REPLICA/DATABASE_READER_HOST指向只读端点适合 Aurora 风格的读写分离。官方特别提醒若只读连接串内嵌凭据优先用readReplicaUrlKey从 Secret 取值避免明文出现在 rendered Pod spec 与 Helm release Secret 中。内置 Redis跨 Pod 协调可选注Redis 配置细节主要在 values.yaml 中说明README 正文未展开此处作为对生产能力的补充。Redis 是 Proxy 的协调存储负责跨 Pod 的 tpm/rpm 限流、Spend 追踪与 Pod 锁管理器。将redis.enabled置为true会部署随包 Redis 子 Chart版本 18.19.1见 Chart.yaml自动注入REDIS_HOST/REDIS_PORT/REDIS_PASSWORD环境变量并在 templates/configmap-litellm.yaml 中自动往general_settings追加coordination_redis块若你自己已在proxy_config里定义了该块则以你的为准。若redis.sentinel.enabled开启则会改渲染sentinel_nodesservice_name组合。若要接入已有 Redis保持enabled: false并自行注入REDIS_HOST等环境变量即可coordination_redis仅与协调相关与 LLM 响应缓存需在配置中设cache: true相互独立。随包 Redis 的镜像同样被重定向到bitnamilegacy/redis:7.2.4-debian-12-r9。自动扩缩容与稳定性Chart 同时支持基于内置的 HPAautoscaling与基于事件的 KEDAkeda两者互斥同时开启只会以 KEDA 渲染的副本为准。扩展入口位于 templates/hpa.yaml 与 templates/keda.yaml。autoscaling默认关闭minReplicas1、maxReplicas100。文档推荐的targetCPUUtilizationPercentage为 60CPU 目标不宜设得过高因为新副本要先过掉 startupProbe最多约 300 秒才承接流量过高的阈值会在接近饱和时才扩容、滞后数分钟。values.yaml 中刻意不给内存目标设值Prisma 查询引擎的常驻内存是“高水位”型——它会一路涨到 Pod 历史最坏写入量且不回落导致按内存扩容的副本只升不降ratchet 效应。内存应作为resources下的供应下限而非扩缩容信号。pdb开启后为 Deployment 提供自愿中断保护minAvailable与maxUnavailable必须二选一两者都设时minAvailable优先。terminationGracePeriodSeconds默认 90 秒strategy可用于配置 RollingUpdate如maxUnavailable: 0、maxSurge: 1。KEDA 场景还可在keda.triggers里声明 Prometheus 等触发源并配置cooldownPeriod、pollingInterval与scaleDown/scaleUp策略values.yaml 中提供了带注释的完整样例。数据库迁移 Jobschema 谁来做数据库表结构的创建与升级由一个独立的一次性 Job负责而不是让每个副本在启动时竞争执行。相关参数参数说明默认值migrationJob.enabled是否启用 schema 迁移 JobtruemigrationJob.backoffLimitJob 重启的 backoff 上限4migrationJob.ttlSecondsAfterFinished完成后 Job 的自动清理 TTL120migrationJob.annotations迁移 Pod 的附加注解{}migrationJob.extraContainers与迁移 Job 并跑的附加容器[]migrationJob.hooks.argocd.enabled启用 ArgoCD 钩子PreSync 钩子 BeforeHookCreation删除策略truemigrationJob.hooks.helm.enabled启用 Helm 钩子pre-install,pre-upgradebefore-hook-creation删除策略falsemigrationJob.hooks.helm.weightHelm 钩子执行顺序权重越小越先执行可选缺省为1N/A其模板见 templates/migrations-job.yamlJob 的容器以command: [python, litellm/proxy/prisma_migration.py]启动对应源码 litellm/proxy/prisma_migration.py并把DISABLE_SCHEMA_UPDATE显式置为false强制执行迁移。与 Job 配合的两个关键设计源码中均有体现Proxy 副本跳过 schema 自检当migrationJob.enabledtrue时templates/deployment.yaml 会给 Proxy 注入DISABLE_SCHEMA_UPDATEtrue从而关闭 Proxy 启动时的prisma db push避免 N 个副本在每次滚动发布时互相竞争同一数据库。该覆盖项被刻意放在 envVars/extraEnvVars 之后渲染防止用户自定义的同名变量把它顶掉。GitOps 双钩子支持ArgoCD 场景使用argocd.argoproj.io/hook: PreSync在同步应用前先跑迁移纯 Helm 场景可开启migrationJob.hooks.helm.enabled使用pre-install,pre-upgrade钩子。两者都配了BeforeHookCreation/before-hook-creation删除策略保证每次部署前旧的迁移 Job 会被清除。values.yaml 中另外提供了两个安全兜底migrationJob.activeDeadlineSeconds1800整个 Job 的墙钟预算共享给所有重试防止迁移阻塞时helm upgrade/GitOps 控制器无限期卡死可置null恢复不设限、migrationJob.disableSchemaUpdate跳过 schema 迁移并让 Job 以 0 退出。访问 Admin UI 与密钥取回填入端点与主密钥部署就绪后浏览器访问ingress.*发布的 URL页面会要求Admin Configuration配置Proxy Endpoint填入从litellmPod 视角看的内网 Service URL。使用默认 Service 设置时应填http://RELEASE-litellm:4000。Proxy Key填入masterkey参数值若安装时未指定则是 Chart 首次安装时随机生成、存储在RELEASE-litellm-masterkeySecret 中的sk-...字符串。通过 kubectl 取回主密钥忘记主密钥时可用如下命令从 Secret 读取kubectl -n litellm get secret RELEASE-litellm-masterkey -o jsonpath{.data.masterkey}注意该命令输出的仍是 base64 编码需要解码后使用如... | base64 --decode。再次强调该值只在首次安装时生成之后的helm upgrade都会复用 Secret 中已有值升级不会导致主密钥轮换。Admin UI 的已知限制截至本文写作时Admin UI无法通过界面新增模型。原因在于添加模型需要更新config.yaml而该文件来自挂载的 ConfigMap对运行中的 Pod 是只读的。这是当前 Helm Chart 的架构性限制而非 Admin UI 本身的功能缺陷。需要变更模型路由时应回到proxy_config或外部 ConfigMap修改并重新helm upgrade借助上文提到的checksum/config注解自动触发滚动更新。常见生产问题速查现象原因与处理helm install渲染失败报postgresql.image.tag相关 fail随包 Postgres 的镜像 tag 为空或为latest被validateBundledPostgresImageTag校验拦下必须钉死为具体版本docker.io/bitnami/postgresql拉取 404Bitnami 已下架带版本号 tag使用默认的bitnamilegacy/postgresql:16.2.0-debian-12-r6即可升级后 Postgres 拒绝启动提示database files are incompatible with server跨了 PostgreSQL 主版本升级无法原地回退需用旧镜像 dump、新镜像 restoreProxy 启动后多副本同时改库migrationJob.enabledtrue时 Proxy 被注入DISABLE_SCHEMA_UPDATEtrueschema 迁移统一由迁移 Job 执行helm upgrade后 Pod 配置未刷新正常情况下checksum/config注解会触发滚动更新若用proxyConfigMap.createfalse的外部 ConfigMap需自行保证内容变更可被感知Pod 反复 OOMKilledresources未按“每 worker 约 1 CPU / 4Gi”设置或副本未随--num_workers同步放大总结与延伸阅读litellm-helm 的价值在于把“LiteLLM Proxy PostgreSQL 迁移 Job”打包成一套可直接helm install、又能渐进式替换外部依赖的部署单元。要点可归纳为四条主线配置即代码proxy_config渲染进只读 ConfigMap模型/路由变更走helm upgrade滚动生效API Key 一律通过os.environ/...引用注入的环境变量避免明文入库。密钥自动管理Master Key 首次生成、升级复用也可完全交给外部 Secret。数据库两态deployStandalone适合体验与 CI生产建议useExisting指向托管 PostgreSQL并注意镜像 tag 钉死与跨版本迁移策略。迁移与 GitOpsPrisma schema 迁移由独立 Job 承担天然支持 ArgoCD PreSync 与 Helm pre-install/pre-upgrade 两种编排。对某一类配置想深入了解时可对照源码继续钻研values.yaml所有参数与注释、templates/渲染逻辑、helm/litellm-helm/tests/Chart 自测用例、litellm/proxy/example_config_yaml/LiteLLM 侧真实配置样例。若 Chart 版本与 Proxy 镜像需要同步升级直接修改 Chart.yaml 中的appVersion或覆盖image.tag即可。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考