ragleap-app-chart

A generic, reusable Helm chart for deploying arbitrary services to Kubernetes — built by RagLeap, but not specific to RagLeap.

Unlike ragleap-ops (which is hardcoded to RagLeap Core's own 4 services), this chart takes an arbitrary services: list in values.yaml and renders resources for each service via range loops. Point it at your own app; it doesn't know or care what RagLeap is.

Status

v0.2.0 published on PyPI. Generic services: schema and range-loop Helm templates are live-tested end-to-end on a real kind cluster (not just helm lint/helm template) -- see CHANGELOG.md for the real bugs found and fixed via live testing. See GENERIC-K8S-CHART-PROPOSAL.md at the repo root for the full design rationale.

Design principles (from the proposal doc)

• Arbitrary service list via range loops — not hardcoded names
• Secure-by-default: NetworkPolicy, SecurityContext, and resource limits apply automatically unless explicitly overridden
• Proven against a non-RagLeap toy app before calling any feature done — genericity is only real once demonstrated against something that isn't RagLeap itself

Worked example (non-RagLeap app)

See EXAMPLE.md for a full walkthrough deploying a genuinely different stack (Redis + a small HTTP service) end-to-end on a real cluster -- including a real structural bug this chart had (no command/args override support at all) that was found and fixed while building it.

Multi-environment values

values-dev.yaml, values-staging.yaml, and values-prod.yaml are available, ported from the same pattern proven in ragleap-ops:

helm install my-release ./ragleap-app-chart -f values-dev.yaml

This works differently from ragleap-ops's version. ragleap-ops overrides simple scalar fields (app.replicaCount: 3), which Helm deep-merges cleanly. This chart's services: field is a list, and Helm does not merge list entries by key — an environment file that redefines services: replaces the entire list, not just the fields that differ. Each values-{env}.yaml here is therefore a full override of the example services: list, not a partial one. If you add or change services in your own values.yaml, you'll need to keep your own values-{env}.yaml files' services: lists in sync manually — this chart does not (yet) merge list entries automatically.

Autoscaling and disruption budgets

Each service can optionally enable a HorizontalPodAutoscaler and a PodDisruptionBudget. Both are off by default.

services:
  - name: web
    image: myorg/myapp:latest
    port: 3000
    resources:
      requests: { cpu: 100m, memory: 128Mi }   # required for CPU-percentage autoscaling
    autoscaling:
      enabled: true
      minReplicas: 2            # default 1
      maxReplicas: 6            # required
      targetCPUUtilizationPercentage: 70   # default 80
    pdb:
      enabled: true
      minAvailable: 1           # default 1

Notes:

• When autoscaling is enabled the Deployment omits replicas, so helm upgrade does not reset the autoscaler's count.
• Autoscaling needs metrics-server in the cluster.
• A PDB with minAvailable: 1 on a single-replica service blocks voluntary node drains.
• Scale-up was verified on kind. Scale-down and PDB behaviour during a real drain were not tested.