Helm Charts on GKE

Helm is the Kubernetes package manager, analogous to apt for Debian or yum for RHEL, but for Kubernetes resources. It addresses the problem of managing multiple interrelated Kubernetes objects (Deployments, Services, ConfigMaps, Secrets, etc.) that form an application. Without Helm, you would need to write and maintain dozens of YAML files, track versions manually, and replicate configurations across environments. Helm packages these resources into a chart—a collection of files that describe a related set of Kubernetes resources. A chart can be installed, upgraded, rolled back, and deleted as a single unit. Helm also provides dependency management, so you can include other charts (e.g., a database) as subcharts.

Helm operates in two modes: Helm v2 (client-server with Tiller) and Helm v3 (client-only, no Tiller). The ACE exam focuses on Helm v3, which is the current standard. In Helm v3, the helm CLI communicates directly with the Kubernetes API server. When you run helm install, it takes the chart (a directory or packaged .tgz file), reads the values you provide (defaults from values.yaml plus overrides via --set or a custom values file), and renders Go templates in the chart templates into final Kubernetes YAML manifests. These manifests are then sent to the Kubernetes API server via kubectl apply-like functionality. Helm stores release information (the deployed chart, its values, and its status) in Secrets in the same namespace as the release. This allows helm list, helm history, helm rollback, and helm upgrade to work.

A Helm chart has a standard directory structure:

mychart/
  Chart.yaml          # Metadata: name, version, description, dependencies
  values.yaml         # Default configuration values
  charts/             # Subcharts (dependencies)
  templates/          # Go template files that generate Kubernetes manifests
  templates/NOTES.txt # Optional: usage notes printed after install
  crds/               # Custom Resource Definitions (installed first)

Charts are distributed via Helm repositories, which are HTTP servers that host an index.yaml file (the repository index) and the packaged chart files. The index file lists all available chart versions, their URLs, and checksums. Common public repositories include:

To add a repository:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

1. helm install [release-name] [chart] --values custom-values.yaml - Helm reads the chart directory or downloads the packaged chart from a repository. - It merges the default values from values.yaml with the user-provided overrides. - It renders all templates using the merged values. - It creates a release Secret in the target namespace (default: default). - It applies the rendered manifests to the cluster in a specific order: Namespaces, Secrets, ConfigMaps, PersistentVolumeClaims, ServiceAccounts, RoleBindings, Services, Deployments, StatefulSets, etc. (Helm follows the typical Kubernetes resource dependency order). - It prints the NOTES.txt content if present.

2. helm upgrade [release-name] [chart] --values custom-values.yaml - Helm compares the new chart's rendered manifests with the previous release's manifests (stored in the release Secret). - It computes a three-way strategic merge patch: the old configuration, the new configuration, and the live state in the cluster. - It applies only the changes needed (additions, updates, deletions). - It increments the release revision number. - If the upgrade fails, you can roll back with helm rollback [release-name] [revision].

Helm uses a clear precedence order for values (from highest to lowest):

| Command | Purpose | |---------|---------| | helm create <name> | Scaffold a new chart directory | | helm package <chart-dir> | Package a chart into a .tgz file | | helm install <release> <chart> | Install a chart | | helm upgrade <release> <chart> | Upgrade a release | | helm rollback <release> <revision> | Roll back to a previous revision | | helm list | List releases (add -A for all namespaces) | | helm history <release> | Show revision history | | helm uninstall <release> | Delete a release (and its resources) | | helm repo add/update/list | Manage repositories | | helm dependency update | Download chart dependencies | | helm template <release> <chart> | Render templates locally without installing | | helm get values <release> | View the values used for a release | | helm get manifest <release> | View the rendered YAML manifests |

GKE does not require any special setup for Helm. You can use Helm v3 with any GKE cluster (standard or Autopilot) as long as you have kubectl configured with appropriate credentials. However, there are GKE-specific considerations:

Charts can depend on other charts. Dependencies are declared in Chart.yaml:

dependencies:
  - name: postgresql
    version: "10.x.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

After editing Chart.yaml, run:

helm dependency update

This downloads the dependency into the charts/ directory and updates Chart.lock (a lock file for reproducible builds). Subchart values are accessed in templates via .Values.subchartname.key. Values for subcharts can be overridden in the parent chart's values.yaml under a key matching the subchart name:

postgresql:
  enabled: true
  postgresqlPassword: "mysecret"

A large e-commerce company runs 200+ microservices on a multi-tenant GKE cluster. Each microservice has its own Helm chart with common templates for Deployment, Service, HorizontalPodAutoscaler, and ServiceMonitor (for Prometheus). They maintain a central values repository (a Git repo) with environment-specific values files: dev-values.yaml, staging-values.yaml, and prod-values.yaml. The CI/CD pipeline (Cloud Build) runs helm template to validate changes, then helm upgrade --install to deploy to the appropriate namespace. They use Helm's dependency management to include a shared logging sidecar chart. Common problems: forgetting to run helm dependency update after changing dependencies, leading to stale subcharts. They mitigate this by running helm dependency build (which updates and packages) in the pipeline. Performance: with 200 releases, helm list can be slow; they use --max-col-width=0 for scriptable output and filter by namespace.

A healthcare startup uses GKE Marketplace to deploy a commercial PACS (Picture Archiving and Communication System) that comes as a Helm chart. The chart includes a PostgreSQL subchart (Bitnami), a custom application Deployment, and a ConfigMap for configuration. They override the PostgreSQL values to use a Cloud SQL proxy sidecar instead of a direct database connection. They store the chart in Artifact Registry as an OCI artifact for version control. During upgrades, they use helm get values to capture the current configuration before applying changes. A common issue: the Marketplace chart expects certain annotations for Workload Identity, which they must add via a custom values file. Misconfiguring the database connection string in values.yaml causes the application to fail to start. They use helm template with --debug to verify the rendered ConfigMap before applying.

A financial services firm uses Config Sync (a Google Cloud service) to manage GKE clusters in a GitOps workflow. They store Helm charts in a Git repository and use Config Sync's Helm support (via source of truth) to sync the cluster state. Config Sync renders the Helm charts and applies them, ensuring the cluster matches the Git repo. They use Helm's --set parameters in the Config Sync configuration to inject environment-specific values. A common pitfall: Config Sync's Helm renderer does not support all Helm features (e.g., post-render hooks). They must test charts with helm template before committing. When misconfigured, Config Sync may delete resources that were created outside the chart (e.g., manually created Secrets). They mitigate this by using Helm's three-way merge and ensuring all resources are managed by Helm.