Azure 44: Helm Universal Charts — api | headless | cron | frontend
easy⏱ 5 mincourseazure
What each chart provides
api — Deployment, Service, Istio VirtualService + DestinationRule, Rollout (canary), HPA, Datadog tags. headless — Deployment + Rollout for consumers/workers that don't expose HTTP (e.g. Service Bus subscribers). cron — CronJob, no Rollout, retry budget, dead-letter alert. frontend — Deployment + Service for the SPA pod, but the bulk of the work is publishing assets to CDN.
# pipelines/prod.yml
services:
- name: cart-api
universalChartType: api
- name: cart-incentives-cron
universalChartType: cron
- name: ecommerce-intent-svc # Service Bus consumer
universalChartType: headless
- name: dealerships-admin-ui
universalChartType: frontend
values.yaml shape is universal too
Each chart accepts the same top-level keys: deployment.{image,replicas}, autoScaling.{enabled,min,max,targetCPUUtilizationPercentage}, mesh.{hosts,gateways,matchPath,corsPolicy} (api/frontend only), secrets.* (set from pipeline), envName, plus optional cron-specific schedule. Consumer service repos drop a values.yaml + per-env overlays into their chart folder and Helm renders the right template set based on chart type.
Why this scales
Add Istio Authorization Policy support to the api chart once → 30+ APIs get it on their next deploy. A custom chart per service would be 30 PRs, 30 review cycles. The trade-off: the universal chart must cover the common shape; truly weird services either argue to extend the chart or live in their own folder with a clear WHY-CUSTOM.md.
Build the picker
Write pickUniversalChart(service) where service = { name, exposesHttp: boolean, hasSchedule: boolean, isFrontend: boolean, isConsumer: boolean }. Return one of 'api' | 'headless' | 'cron' | 'frontend'. Rules: schedule wins → cron. frontend wins next → frontend. http with no schedule → api. consumer/no-http → headless. Throw if a service is both frontend and consumer (ambiguous). Log picks for 5 representative Lythia services.
Don't fork the universal chart for a one-off setting
Almost every customisation that looks like 'we need our own chart' is actually 'we need a new values key'. Add the key to the universal chart with a sensible default and only your service uses it; nobody else pays the cognitive cost. Forks are technical debt with compounding interest.
Quiz: cron has no Rollout — why?
Argo Rollouts orchestrates traffic shifting. A CronJob has no traffic; it has invocations. Canary makes no sense for a one-shot batch. Instead the cron chart uses standard K8s CronJob + history limits + alerts on consecutive failures.