What are the best practices for structuring large Helm charts for microservices?

Large microservices deployments require careful chart organization to maintain sanity. Here are proven patterns:

1. Umbrella chart pattern (parent with subcharts): myapp/ Chart.yaml # Dependency declarations values.yaml # Global values charts/ service-a/ Chart.yaml values.yaml templates/ service-b/ Chart.yaml values.yaml templates/ common/ # Library chart Chart.yaml templates/_helpers.tpl

2. Shared values structure: # Global values propagate to all subcharts global: imageRegistry: myregistry.com imagePullSecrets: [regcred] monitoring: enabled: true tracing: enabled: true service-a: replicaCount: 2 resources: {...} service-b: replicaCount: 3 resources: {...}

3. Template organization patterns: templates/ _helpers.tpl # Global helpers _deployment.tpl # Reusable deployment template _service.tpl # Reusable service template _configmap.tpl # Reusable configmap template service-a-deployment.yaml # Service-specific (uses templates) service-a-service.yaml service-b-deployment.yaml service-b-service.yaml

4. Values separation by environment: values/ common.yaml # Shared across all dev.yaml staging.yaml prod.yaml region/ us-east.yaml eu-west.yaml

5. Naming conventions for consistency: # _helpers.tpl {{- define "myapp.name" -}} {{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }} {{- end }} {{- define "myapp.labels" -}} helm.sh/chart: {{ include "myapp.chart" . }} {{ include "myapp.selectorLabels" . }} app.kubernetes.io/managed-by: {{ .Release.Service }} {{- end }}

6. Configuration patterns: - ConfigMaps for non-sensitive config - Secrets for sensitive data (never in values.yaml) - External configuration via Helm hooks or init containers

7. Testing strategy: tests/ test-connection.yaml test-database.yaml test-service-mesh.yaml

8. Documentation requirements: - README.md with values table - values.schema.json for validation - Examples directory with sample configurations