litellm/helm/litellm
yuneng-jiang 85af2f65c9
refactor(helm)!: connect both charts to a separately deployed Lens (#49169)
Neither chart bundles Lens anymore. The Lens subchart, its lock entry,
the vendored chart archive, the templates/lens resources and the
bundled-Lens install smoke are gone. A connection-only lens block wires
the gateway and backend to a Lens deployed from its own chart, and an
enabled lensWorker value fails the render instead of being ignored.

Supersedes #47869, which made the same change for helm/litellm only.
2026-10-30 02:29:44 +00:00
..
templates refactor(helm)!: connect both charts to a separately deployed Lens (#49169) 2026-10-30 02:29:44 +00:00
tests refactor(helm)!: connect both charts to a separately deployed Lens (#49169) 2026-10-30 02:29:44 +00:00
Chart.yaml refactor(helm)!: connect both charts to a separately deployed Lens (#49169) 2026-10-30 02:29:44 +00:00
README.md refactor(helm)!: connect both charts to a separately deployed Lens (#49169) 2026-10-30 02:29:44 +00:00
values.yaml refactor(helm)!: connect both charts to a separately deployed Lens (#49169) 2026-10-30 02:29:44 +00:00

LiteLLM componentized chart

This chart deploys separate gateway, backend and UI services

This chart does not deploy Lens. Deploy Lens from its own chart, then set lens.enabled: true, lens.url, lens.publicUrl, lens.gatewaySecret.name and lens.serviceTokenSecret.name. The secret keys default to gateway-secret and service-token. Set lens.service.name when that Lens runs in this release's namespace and the chart ingress should route /lens-ingest to it. The old lensWorker values are no longer read, and enabling them fails the render

For an ingress with separate component hostnames, set all three ingress.componentHosts values, leave ingress.host and ingress.extraPaths empty, configure ui.backendUrl as the backend's public origin and backend.gatewayUrl as the gateway's public origin, and set ui.publicUrl to the browser-facing UI origin. The UI Deployment receives LITELLM_BACKEND_URL from ui.backendUrl only when ingress.componentHosts is configured.

ingress:
  enabled: true
  host: ""
  componentHosts:
    ui: ui.example.com
    backend: backend.example.com
    gateway: gateway.example.com
  extraPaths: []
ui:
  publicUrl: https://ui.example.com
  backendUrl: https://backend.example.com
backend:
  gatewayUrl: https://gateway.example.com

Routes to another Service

For a shared hostname, ingress.extraPaths can route to a Service in the same namespace using serviceName and servicePort. The port can be a number or a named Service port. Omit service when using these fields

ingress:
  enabled: true
  className: alb
  host: gateway.example.com
  extraPaths:
    - path: /moyai
      pathType: Prefix
      serviceName: moyai-ingress
      servicePort: 8080

The Service and application must already support the path prefix. The chart adds the path to the existing Ingress and leaves its built-in routes in place. It does not create the target Service or rewrite requests

For AWS ALB, configure the target Service's alb.ingress.kubernetes.io/healthcheck-path annotation when the application needs a different health check from LiteLLM. Existing service aliases (gateway, backend, ui) remain supported