--- title: "Helm" description: "Helm is the package manager for Kubernetes that simplifies deploying, managing, and upgrading applications through reusable charts. This cheatsheet covers essential Helm CLI commands and workflows." author: "Mohammad Abu Mattar" canonical: https://mkabumattar.com/cheatsheets/helm --- # Helm Helm is the package manager for Kubernetes that simplifies the deployment, management, and upgrade of applications. It uses charts templated Kubernetes manifests to enable reusable, configurable application packages. ## Key Benefits - **Simplified Deployment**: Deploy entire application stacks with a single command - **Reusability**: Share and reuse charts across projects and teams - **Configuration Management**: Override values without editing templates - **Version Control**: Track and rollback to previous releases easily - **Dependency Management**: Include and manage chart dependencies automatically - **Scalability**: Quickly deploy multiple instances with different configurations ## Quick Start **Install Helm**: Follow the Installation Setup section. **Add a repository**: `helm repo add bitnami https://charts.bitnami.com/bitnami` **Search for charts**: `helm search repo nginx` **Install a chart**: `helm install my-web bitnami/nginx --create-namespace` **Check status**: `helm status my-web` ## Common Workflows 1. **First Deploy**: Add repository, search chart, install with values 2. **Configuration**: Customize with values files and flag overrides 3. **Upgrades**: Update releases with new chart versions and configuration changes 4. **Rollback**: Revert to previous versions if issues occur 5. **Chart Development**: Create custom charts for your applications 6. **Production**: Manage multiple environments with versioned, auditable deployments Browse the sections above to master Helm from basics to advanced production scenarios. ## Getting Started Fundamental Helm concepts and basic setup for beginners. ### What is Helm Introduction to Helm and its role in Kubernetes package management. **Keywords:** helm, package-manager, kubernetes, charts, application-deployment #### Helm overview and key concepts ```bash # Helm is a package manager for Kubernetes that simplifies app deployment # Key concepts: # - Chart: A Helm package containing all resources needed (templates, values, metadata) # - Release: A running instance of a chart in a Kubernetes cluster # - Repository: Storage for charts (similar to package registries) # - Values: Configuration files that customize chart behavior # Chart structure is similar to application packages in Linux: # Helm Chart ≈ .deb or .rpm package # Release ≈ Installed package in system # Repository ≈ Package repository (apt, yum) ``` _exec_ ```bash helm version ``` _output_ ```bash version.BuildInfo{Version:"v3.13.0", GitCommit:"efc1de...", GitTreeState:"clean", GoVersion:"go1.21"} ``` Helm organizes Kubernetes manifests into reusable, configurable packages called charts. - Charts are collections of templated Kubernetes YAML files. - Releases are instances of charts deployed in clusters. - Values allow parameterization without editing templates. #### Helm vs kubectl comparison ```bash # kubectl approach: Deploy individual YAML files kubectl apply -f deployment.yaml kubectl apply -f service.yaml kubectl apply -f configmap.yaml # Helm approach: Deploy packaged chart helm install my-app stable/nginx # Helm benefits: # - Single command deploys entire application stack # - Reusable across projects # - Easy configuration through values # - Built-in upgrade and rollback capabilities ``` _exec_ ```bash helm list ``` _output_ ```bash NAME NAMESPACE REVISION UPDATED STATUS CHART my-app default 2 2025-02-27 10:30:00 deployed nginx-1.0.0 ``` Shows advantages of using Helm for application deployment versus manual kubectl management. - Helm wraps multiple kubectl operations. - Provides templating, versioning, and rollback features. #### Understanding the Helm ecosystem ```bash # Helm ecosystem components: # 1. Helm CLI: Command-line tool for managing charts and releases # 2. Helm Hub: Central repository for discovering public charts # 3. Repositories: Helm chart repositories (Bitnami, Jetstack, etc.) # 4. Charts: Packaged Kubernetes applications # 5. Kubeconfig: Determines which cluster Helm deploys to # Example workflow: helm repo add bitnami https://charts.bitnami.com/bitnami # Add repo helm search repo nginx # Find chart helm install web bitnami/nginx # Deploy chart helm upgrade web bitnami/nginx # Update release ``` _exec_ ```bash helm repo list ``` _output_ ```bash NAME URL bitnami https://charts.bitnami.com/bitnami stable https://charts.helm.sh/stable ``` Describes the complete Helm ecosystem and typical workflow. - Multiple repositories can be added and searched simultaneously. - Helm respects the KUBECONFIG environment variable for cluster selection. **Best practices:** - Understand charts and releases before deploying to production. - Always review chart values before deployment. **Common errors:** - **Release not found**: Ensure the release name is correct and exists in the cluster. ### Installation Setup Installing Helm and verifying the installation. **Keywords:** install, setup, verify, version, environment #### Install Helm on Linux ```bash # Download and install Helm binary curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash # Or using package manager (Ubuntu/Debian) curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [arch=amd64 signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm # Verify installation helm version ``` _exec_ ```bash helm version ``` _output_ ```bash version.BuildInfo{Version:"v3.13.0", GitCommit:"efc1de...", GoVersion:"go1.21"} ``` Installation steps for Helm on Linux systems (Ubuntu/Debian). - The install script is the recommended method for latest versions. - Requires curl and basic Linux tools. #### Install Helm on macOS and Windows ```bash # macOS: Install using Homebrew brew install helm # macOS: Install from source tar -zxvf helm-v3.13.0-darwin-amd64.tar.gz sudo mv darwin-amd64/helm /usr/local/bin/helm # Windows: Using Chocolatey choco install kubernetes-helm # Windows: Using Scoop scoop install helm # Verify across platforms helm version ``` _exec_ ```bash helm version && helm env ``` _output_ ```bash version.BuildInfo{Version:"v3.13.0", GitCommit:"efc1de..."} HELM_HOME=/Users/username/.helm ``` Installation instructions for macOS and Windows systems. - Homebrew is the easiest method on macOS. - Chocolatey and Scoop are popular on Windows. #### Verify Helm setup and cluster connection ```bash # Check Helm version and build info helm version # Check Helm environment helm env # Verify Kubernetes cluster connection helm version --short kubectl cluster-info # List any existing releases helm list --all-namespaces ``` _exec_ ```bash helm version --short && helm list -A ``` _output_ ```bash v3.13.0+gca8fb9e7 NAME NAMESPACE REVISION STATUS CHART ``` Comprehensive verification of Helm installation and Kubernetes connectivity. - Requires valid kubeconfig and Kubernetes cluster access. - helm list -A shows releases across all namespaces. **Best practices:** - Keep Helm updated to the latest stable version. - Verify cluster connection before attempting deployments. **Common errors:** - ****: Verify installation location is in PATH or reinstall using appropriate method. ### Version and Health Check Checking Helm version and cluster readiness. **Keywords:** version, health-check, status, cluster, diagnostics #### Check Helm and Kubernetes versions ```bash # Get detailed Helm version information helm version # Get short version format helm version --short # Check Kubernetes server version kubectl version --short # Check both in one go helm version --short && echo "---" && kubectl version --short ``` _exec_ ```bash helm version && kubectl version --short ``` _output_ ```bash version.BuildInfo{Version:"v3.13.0", GitCommit:"ca8fb9e7", GitTreeState:"clean", GoVersion:"go1.21.3"} Client Version: v1.28.0 Server Version: v1.28.0 ``` Retrieves detailed version information for both Helm and Kubernetes. - Client and server must be within one minor version. - Version mismatch can cause compatibility issues. #### Get Helm environment information ```bash # Display all Helm environment variables helm env # Get specific environment value helm env HELM_HOME helm env HELM_CONFIG_HOME # Common important paths: # HELM_HOME: Helm data directory # HELM_CONFIG_HOME: Helm configuration directory # HELM_CACHE_HOME: Chart cache location ``` _exec_ ```bash helm env HELM_HOME HELM_CACHE_HOME ``` _output_ ```bash /home/user/.helm /home/user/.cache/helm ``` Shows important Helm environment paths and configuration locations. - Environment variables can be set to override defaults. - Cache directory stores downloaded charts. **Best practices:** - Check compatibility before major version upgrades. - Keep environment paths organized and backed up. **Common errors:** - **connection refused**: Verify kubectl access and cluster availability with `kubectl cluster-info`. ## Repository Management Managing Helm chart repositories and discovering available charts. ### Add and Search Repositories Adding chart repositories and searching for available charts. **Keywords:** repository, add, search, discover, charts #### Add popular Helm repositories ```bash # Add Bitnami repository (popular for production charts) helm repo add bitnami https://charts.bitnami.com/bitnami # Add Jetstack repository (for cert-manager) helm repo add jetstack https://charts.jetstack.io # Add stable repository helm repo add stable https://charts.helm.sh/stable # Add custom private repository helm repo add myrepo https://private.example.com/charts --username user --password pass # Verify repository addition helm repo list ``` _exec_ ```bash helm repo add bitnami https://charts.bitnami.com/bitnami && helm repo list ``` _output_ ```bash "bitnami" has been added to your repositories NAME URL bitnami https://charts.bitnami.com/bitnami ``` Demonstrates adding various Helm repositories for chart discovery. - Bitnami maintains high-quality production-grade charts. - Username/password for private repos are optional. #### Search for charts in repositories ```bash # Search for a specific chart helm search repo nginx # Search with version information helm search repo wordpress --versions # Search across all added repositories helm search repo mysql # Show detailed chart information helm search repo postgres -o yaml # Get chart with specific version helm search repo bitnami/wordpress --version 18.0.0 ``` _exec_ ```bash helm search repo nginx ``` _output_ ```bash NAME CHART VERSION APP VERSION DESCRIPTION bitnami/nginx 15.1.2 1.25.3 NGINX Open Source is a web server... bitnami/nginx-ingress 9.8.1 1.8.1 NGINX Ingress Controller... ``` Shows how to search and discover charts across repositories. - helm search finds charts in local cache. - Update repos first with helm repo update. - Version flag shows all available versions of a chart. #### Search Helm Hub (ArtifactHub) ```bash # Search public charts on Artifact Hub helm search hub nginx # Search with max results helm search hub wordpress --max-col-width 80 # Get chart from ArtifactHub directly helm search hub mysql --output table # Note: hub search requires internet and searches external registry # For faster searches, add repos locally and use: helm search repo ``` _exec_ ```bash helm search hub nginx ``` _output_ ```bash URL CHART VERSION APP VERSION DESCRIPTION https://artifacthub.io/packages/helm/bitnami/... 15.1.2 1.25.3 NGINX web server... ``` Searches the Artifact Hub for publicly available charts. - Artifact Hub is the new central registry (replaces Helm Hub). - Requires internet connection for hub search. **Best practices:** - Add trusted repositories (Bitnami, official) first. - Update repositories regularly with helm repo update. - Always search local cache before using hub search. **Common errors:** - **no matching release found**: Add repository first with helm repo add and run helm repo update. ### Update and Remove Repositories Keeping repositories current and managing repository lifecycle. **Keywords:** update, remove, delete, refresh, maintenance #### Update and refresh repository cache ```bash # Update index for a specific repository helm repo update bitnami # Update all repository caches helm repo update # Update and show what changed helm repo update --verbose # Update at regular intervals (daily is common) # Added to crontab: 0 8 * * * /usr/local/bin/helm repo update ``` _exec_ ```bash helm repo update ``` _output_ ```bash Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "bitnami" chart repository ...Successfully got an update from the "stable" chart repository ``` Updates the local cache of charts from remote repositories. - Local cache is stored in HELM_CACHE_HOME. - Update before searching to find latest charts. - Useful in CI/CD pipelines before deployments. #### Remove and replace repositories ```bash # Remove a repository helm repo remove bitnami # Remove multiple repositories helm repo remove bitnami stable jetstack # Replace/update a repository URL helm repo remove old-repo helm repo add new-repo https://charts.example.com # Verify removal helm repo list ``` _exec_ ```bash helm repo remove bitnami && helm repo list ``` _output_ ```bash "bitnami" has been removed from your repositories NAME URL stable https://charts.helm.sh/stable ``` Demonstrates removing and replacing repositories. - Removing a repo only removes local cache, not actual charts. - Does not affect existing releases from that repo. #### Manage private repository authentication ```bash # Add private repo with credentials helm repo add myrepo https://charts.mycompany.com \ --username myuser --password mypass # Add with username only (will prompt for password) helm repo add myrepo https://charts.mycompany.com \ --username myuser # Add with certificate authentication helm repo add secure https://charts.secure.com \ --ca-file ./ca.crt \ --cert-file ./client.crt \ --key-file ./client.key # Update private repo helm repo update myrepo ``` _exec_ ```bash helm repo add myrepo https://private.example.com --username user ``` _input_ ```bash password ``` _output_ ```bash "myrepo" has been added to your repositories ``` Shows how to configure repositories with authentication. - Credentials stored in ~/.helm/repositories.yaml. - For security, use environment variables instead of CLI args. **Best practices:** - Update repos before searching or installing. - Remove unused repositories to reduce clutter. - Use certificate-based auth for enhanced security. **Common errors:** - **failed to fetch repository**: Check URL, network connectivity, and authentication credentials. ### Repository Index and Information Getting information about repositories and their contents. **Keywords:** index, information, metadata, chart-details, repo-info #### Get chart information and default values ```bash # Show chart information (metadata, description) helm show chart bitnami/wordpress # Show default values for a chart helm show values bitnami/wordpress # Show all information (chart + values + readme) helm show all bitnami/wordpress # Show README for chart helm show readme bitnami/wordpress ``` _exec_ ```bash helm show chart bitnami/wordpress ``` _output_ ```bash apiVersion: v2 appVersion: 6.3.1 description: WordPress is a free and open source blogging and website creation tool... name: wordpress type: application version: 18.0.0 ``` Retrieves metadata and documentation for a specific chart. - Essential before installation to understand customization options. - helm show values is crucial for learning chart configuration. #### List and inspect chart versions ```bash # List available versions of a chart helm search repo wordpress --versions # Show specific version information helm show chart bitnami/wordpress --version 17.0.0 # Compare values between versions helm show values bitnami/wordpress --version 18.0.0 # Get chart from specific version helm pull bitnami/wordpress --version 18.0.0 --untar ``` _exec_ ```bash helm search repo wordpress --versions | head -10 ``` _output_ ```bash NAME CHART VERSION APP VERSION DESCRIPTION bitnami/wordpress 18.0.0 6.3.1 WordPress is a free and... bitnami/wordpress 17.5.1 6.2.2 WordPress is a free and... bitnami/wordpress 17.0.0 6.2.0 WordPress is a free and... ``` Shows how to discover and inspect different versions of charts. - Different versions may have breaking changes in default values. - Always review release notes before upgrading. **Best practices:** - Review chart values before any deployment. - Check chart README for installation prerequisites. - Compare values across versions when upgrading. **Common errors:** - **chart not found**: Ensure repository is added and updated with `helm repo update`. ## Installing Charts Deploying applications using Helm charts. ### Basic Chart Installation Installing charts with minimal and standard configurations. **Keywords:** install, deploy, release, basic, first-release #### Basic chart installation ```bash # Install chart with default values helm install my-nginx bitnami/nginx # Install with custom release name helm install web-server bitnami/nginx # Install in specific namespace helm install my-nginx bitnami/nginx --namespace webapps # Install and create namespace if it doesn't exist helm install my-nginx bitnami/nginx --namespace webapps --create-namespace # Verify installation helm list -n webapps ``` _exec_ ```bash helm install my-nginx bitnami/nginx --create-namespace ``` _output_ ```bash NAME: my-nginx LAST DEPLOYED: Wed Feb 27 14:30:00 UTC 2025 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Demonstrates basic chart installation and namespace management. - Helm auto-generates release name if not provided. - --create-namespace creates namespace if missing. - Release name must be unique per namespace. #### Install WordPress with persistent storage ```bash # Install WordPress chart helm install my-blog bitnami/wordpress \ --set wordpressUsername=admin \ --set wordpressPassword='MySecurePass123' \ --set wordpressEmail=admin@example.com \ --set mariadb.auth.rootPassword='RootPass123' # Install with persistent volume helm install my-blog bitnami/wordpress \ --set persistence.enabled=true \ --set persistence.size=10Gi # Check release status helm status my-blog ``` _exec_ ```bash helm install my-blog bitnami/wordpress --set wordpressUsername=admin ``` _output_ ```bash NAME: my-blog STATUS: deployed CHART: wordpress-18.0.0 APP VERSION: 6.3.1 ``` Shows installing WordPress with custom configuration. - Set values override defaults without editing templates. - Multiple --set flags can be chained. - Sensitive values should use secrets file instead. #### Install MySQL database with credentials ```bash # Install MySQL with custom root password helm install mysql-db bitnami/mysql \ --set auth.rootPassword='RootPassword123' \ --set auth.database=myapp \ --set auth.username=appuser \ --set auth.password='AppPassword123' # Install with specific MySQL version helm install mysql-db bitnami/mysql \ --set image.tag=8.0 \ --set primary.persistence.size=20Gi # Verify deployment helm get values mysql-db ``` _exec_ ```bash helm install mysql-db bitnami/mysql --set auth.rootPassword='Root123' ``` _output_ ```bash NAME: mysql-db STATUS: deployed CHART: mysql-11.0.0 APP VERSION: 8.0.35 ``` Demonstrates installing a production-grade MySQL database. - Always use strong passwords for production. - Consider using --values flag with secret files. **Best practices:** - Always specify resource requests and limits. - Use --dry-run --debug to preview deployment. - Review chart README for required values. **Common errors:** - **release already exists**: Use unique release names or delete previous release first. ### Values Configuration Customizing chart installations with values files and flags. **Keywords:** values, configuration, customize, flags, override #### Using values files for configuration ```bash # Create custom values file cat > my-values.yaml << 'EOF' nginx: replicaCount: 3 image: tag: "1.25" resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi service: type: LoadBalancer port: 8080 EOF # Install using values file helm install my-nginx bitnami/nginx -f my-values.yaml # Use multiple values files (later ones override earlier) helm install my-app bitnami/nginx \ -f base-values.yaml \ -f production-values.yaml ``` _exec_ ```bash helm install my-nginx bitnami/nginx -f my-values.yaml --dry-run ``` _output_ ```bash NAME: my-nginx NAMESPACE: default STATUS: pending-install ``` Shows how to manage complex configurations with values files. - Values files allow version control of configurations. - Multiple -f flags merge values (later overrides earlier). - --dry-run previews changes without applying. #### Override values with command-line flags ```bash # Override single value helm install my-app bitnami/nginx --set replicaCount=5 # Override nested values using dot notation helm install my-app bitnami/nginx --set image.tag=latest # Set array values helm install my-app bitnami/nginx \ --set 'image.pullPolicy={IfNotPresent,Always}' # Combine values file and command-line overrides helm install my-app bitnami/nginx \ -f values.yaml \ --set replicaCount=3 \ --set image.tag=1.25.3 ``` _exec_ ```bash helm install my-app bitnami/nginx --set replicaCount=2 --dry-run ``` _output_ ```bash NAME: my-app STATUS: pending-install ``` Demonstrates command-line overrides for quick customization. - Dot notation for nested values (e.g., image.tag). - --set values override -f file values unless order matters. #### Use secrets and environment variables in values ```bash # Create secret values file (don't commit to git) cat > secrets.yaml << 'EOF' database: user: admin password: MySecurePass123! apiKey: sk_live_abc123def456 EOF # Install with secret values helm install my-app myrepo/app -f secrets.yaml # Use environment variables export DB_PASSWORD=MySecurePass123 helm install my-app myrepo/app \ --set database.password=$DB_PASSWORD # Better: Use Kubernetes secrets kubectl create secret generic app-secrets \ --from-literal=password=mypass helm install my-app myrepo/app \ --set database.existingSecret=app-secrets ``` _exec_ ```bash helm install my-app myrepo/app -f secrets.yaml --dry-run ``` _output_ ```bash NAME: my-app STATUS: pending-install ``` Shows secure practices for handling sensitive configuration. - Never commit secret values to version control. - Kubernetes secrets are more secure than ConfigMaps. - Use existingSecret when available in chart. **Best practices:** - Keep base values file in git, secrets separate. - Use --dry-run to validate templates before deployment. - Document custom values and their purposes. **Common errors:** - **failed to parse values**: Check YAML syntax in values file, ensure proper indentation. ### Namespace Management Managing releases across namespaces and namespace organization. **Keywords:** namespace, isolation, multi-tenant, organization, rbac #### Install releases in different namespaces ```bash # Create namespaces kubectl create namespace production kubectl create namespace staging kubectl create namespace development # Install same chart in different namespaces helm install my-app bitnami/nginx --namespace production --create-namespace helm install my-app bitnami/nginx --namespace staging --create-namespace helm install my-app bitnami/nginx --namespace development --create-namespace # List releases across all namespaces helm list --all-namespaces # List releases in specific namespace helm list --namespace production ``` _exec_ ```bash helm list --all-namespaces ``` _output_ ```bash NAME NAMESPACE STATUS REVISION CHART my-app production deployed 1 nginx-15.1.2 my-app staging deployed 1 nginx-15.1.2 my-app development deployed 1 nginx-15.1.2 ``` Demonstrates namespace isolation for different environments. - Same release name can exist in different namespaces. - --create-namespace creates namespace if missing. - Namespace isolation respects Kubernetes RBAC. #### Organize applications by namespace ```bash # Create namespace hierarchy kubectl create namespace databases kubectl create namespace monitoring kubectl create namespace ingress-system # Install applications in logical namespaces helm install postgres bitnami/postgresql --namespace databases helm install mysql bitnami/mysql --namespace databases helm install prometheus bitnami/kube-prometheus --namespace monitoring helm install grafana bitnami/grafana --namespace monitoring helm install nginx-ingress bitnami/nginx-ingress-controller \ --namespace ingress-system # View resources by namespace kubectl get all -n databases kubectl get all -n monitoring ``` _exec_ ```bash helm list --all-namespaces ``` _output_ ```bash NAMESPACE NAME STATUS CHART databases postgres deployed postgresql-12.0.0 databases mysql deployed mysql-11.0.0 monitoring prometheus deployed kube-prometheus-40.0.0 ``` Shows logical organization of applications using namespaces. - Organize by function (databases, monitoring, network). - Can apply RBAC policies per namespace. **Best practices:** - Use separate namespaces for different environments. - Apply resource quotas per namespace. - Use namespace labels for organization. **Common errors:** - **namespace not found**: Create namespace first or use --create-namespace flag. ## Upgrading & Rollback Managing release updates and rolling back to previous versions. ### Upgrading Releases Updating releases to newer versions with zero downtime. **Keywords:** upgrade, update, new-version, change-settings, rolling-update #### Basic release upgrade ```bash # Upgrade release to newer chart version helm upgrade my-nginx bitnami/nginx # Upgrade with new values helm upgrade my-nginx bitnami/nginx --set replicaCount=5 # Upgrade from values file helm upgrade my-nginx bitnami/nginx -f new-values.yaml # Preview upgrade without applying helm upgrade my-nginx bitnami/nginx --dry-run --debug # Check upgrade history helm history my-nginx ``` _exec_ ```bash helm upgrade my-nginx bitnami/nginx --set replicaCount=3 --dry-run ``` _output_ ```bash Release "my-nginx" has been upgraded. Happy Helming! REVISION: 2 RELEASED: Wed Feb 27 15:00:00 UTC 2025 ``` Shows basic upgrade workflow and preview options. - Upgrade applies changes to existing release. - New revision is created, previous kept for rollback. #### Upgrade with strategy and rollout management ```bash # Upgrade with custom strategy helm upgrade my-app bitnami/nginx \ --set image.tag=1.25.3 \ --set strategy.type=RollingUpdate \ --set strategy.rollingUpdate.maxUnavailable=1 # Upgrade without blocking (useful for CI/CD) helm upgrade my-app bitnami/nginx \ --set replicaCount=3 \ --wait=false # Upgrade and wait for ready pods helm upgrade my-app bitnami/nginx \ --set replicaCount=3 \ --wait=true \ --timeout 5m ``` _exec_ ```bash helm upgrade my-app bitnami/nginx --wait --timeout 5m --dry-run ``` _output_ ```bash Release "my-app" has been upgraded. Happy Helming! ``` Shows advanced upgrade options for production deployments. - RollingUpdate ensures zero downtime for stateless apps. - --wait blocks until all pods are ready. - --timeout specifies max wait time. #### Upgrade WordPress and dependencies ```bash # Upgrade WordPress with database migration helm upgrade my-blog bitnami/wordpress \ --set image.tag=6.3.1 \ --set mariadb.image.tag=10.5 # Check current values before upgrade helm get values my-blog # Upgrade and automatically install dependencies helm upgrade my-blog bitnami/wordpress \ --dependency-update # View upgrade status helm status my-blog ``` _exec_ ```bash helm upgrade my-blog bitnami/wordpress --dry-run ``` _output_ ```bash Release "my-blog" has been upgraded. Happy Helming! ``` Demonstrates upgrading complex applications with dependencies. - Dependencies are separate sub-charts. - Always backup data before major upgrades. **Best practices:** - Always use --dry-run to preview changes. - Maintain release history for rollback capability. - Test upgrades in staging environment first. **Common errors:** - **release not found**: Verify release name exists with `helm list`. ### Rollback and Revision Management Rolling back to previous release versions and managing history. **Keywords:** rollback, revert, history, revision, undo #### Rollback to previous release version ```bash # View release history helm history my-nginx # Rollback to previous revision (immediately before current) helm rollback my-nginx # Rollback to specific revision number helm rollback my-nginx 1 # Rollback and verify helm history my-nginx # Check status after rollback helm status my-nginx ``` _exec_ ```bash helm history my-nginx && helm rollback my-nginx ``` _output_ ```bash REVISION UPDATED STATUS CHART DESCRIPTION 1 Wed Feb 27 14:30:00 superseded nginx-15.1.2 Install complete 2 Wed Feb 27 15:00:00 superseded nginx-15.2.0 Upgrade complete 3 Wed Feb 27 15:15:00 deployed nginx-15.1.5 Upgrade complete Rollback was a success! Happy Helming! ``` Demonstrates viewing history and performing rollbacks. - New rollback creates another revision. - All revisions are kept for audit trail. #### Rollback with cleanup and force ```bash # Rollback with cleanup of the rollback revision helm rollback my-app --cleanup-on-fail # Force rollback even if current deployment has issues helm rollback my-app --force # Rollback with custom timeout helm rollback my-app --wait --timeout 5m # Get detailed history with descriptions helm history my-app --output json ``` _exec_ ```bash helm rollback my-app --wait ``` _output_ ```bash Rollback was a success! Happy Helming! ``` Shows advanced rollback options for production scenarios. - Force flag overrides safety checks. - cleanup-on-fail prevents orphaned resources. #### Automated rollback strategy for CI/CD ```bash # In CI/CD pipeline, record old revision before upgrade OLD_REVISION=$(helm history my-app --output json | \ jq '.[-1].revision') # Perform upgrade helm upgrade my-app bitnami/nginx --wait # If upgrade fails or validation fails, rollback if [ $? -ne 0 ]; then echo "Upgrade failed, rolling back..." helm rollback my-app $OLD_REVISION fi # Monitor after deployment for issues helm status my-app ``` _exec_ ```bash helm history my-app --max 5 ``` _output_ ```bash REVISION UPDATED STATUS CHART 1 Feb 27 14:30:00 superseded app-1.0 2 Feb 27 15:00:00 superseded app-2.0 ``` Shows how to implement automated rollback in CI/CD pipelines. - Store revision numbers before upgrades for safety. - Combine with smoke tests and health checks. **Best practices:** - Keep full release history for audit and rollback. - Test rollback manually in staging environment first. - Implement health checks after deployment. **Common errors:** - **no revision to rollback to**: Ensure previous revision exists in history. ### Version and Release Control Managing chart versions and maintaining release consistency. **Keywords:** version, release-control, chart-version, consistency, pinning #### Pin chart versions for consistency ```bash # Install specific chart version helm install my-app bitnami/nginx --version 15.1.2 # Check installed chart version helm list # Show chart version information helm show chart bitnami/nginx --version 15.1.2 # Lock version in values file cat > my-values.yaml << 'EOF' # Chart version 15.1.2 replicaCount: 3 image: tag: "1.25" EOF helm install my-app bitnami/nginx --version 15.1.2 -f my-values.yaml ``` _exec_ ```bash helm install my-app bitnami/nginx --version 15.1.2 --dry-run ``` _output_ ```bash NAME: my-app CHART: nginx-15.1.2 ``` Shows how to pin chart versions for reproducible deployments. - Always specify chart version for production. - Prevents unexpected breaking changes. #### Review breaking changes between versions ```bash # Compare values between two versions helm show values bitnami/nginx --version 15.0.0 > values-15-0.yaml helm show values bitnami/nginx --version 15.1.2 > values-15-1.yaml diff values-15-0.yaml values-15-1.yaml # Check chart API version compatibility helm show chart bitnami/nginx --version 15.0.0 helm show chart bitnami/nginx --version 15.1.2 # Review release notes helm show readme bitnami/nginx --version 15.1.2 ``` _exec_ ```bash helm show values bitnami/nginx --version 15.1.2 | head -20 ``` _output_ ```bash replicaCount: 1 image: registry: docker.io repository: bitnami/nginx tag: 1.25.3 ``` Demonstrates checking for breaking changes before upgrades. - Always review diffs in values files. - Check chart README for migration guides. **Best practices:** - Use semantic versioning for chart selection. - Document chart version choices in your repo. - Test version upgrades in non-production first. **Common errors:** - **chart version not found**: Use `helm search repo --versions` to list available versions. ## Release Management Managing, monitoring, and maintaining Helm releases. ### List and Find Releases Discovering and listing deployed releases across the cluster. **Keywords:** list, releases, find, filter, search #### List releases in different ways ```bash # List all releases in current namespace helm list # List releases in specific namespace helm list --namespace production # List all releases across all namespaces helm list --all-namespaces # List with additional columns helm list --all-namespaces --output wide # Export as JSON for parsing helm list --output json | jq '.[] | {name, namespace, status}' ``` _exec_ ```bash helm list --all-namespaces ``` _output_ ```bash NAME NAMESPACE STATUS CHART VERSION my-nginx default deployed nginx-15.1.2 1.25.3 my-wordpress production deployed wordpress-18.0.0 6.3.1 mysql-db databases deployed mysql-11.0.0 8.0.35 ``` Shows various ways to list and filter releases. - --all-namespaces searches all namespaces. - JSON output useful for automation and scripting. #### Filter releases by status and properties ```bash # List only deployed releases helm list --deployed # List failed or superseded releases helm list --failed helm list --superseded # List releases updated after specific date helm list --date --max 10 # Search for specific release helm list | grep nginx # Get releases by label helm list --all-namespaces -o json | \ jq '.[] | select(.status=="deployed")' ``` _exec_ ```bash helm list --deployed --all-namespaces ``` _output_ ```bash NAME NAMESPACE STATUS CHART my-nginx default deployed nginx-15.1.2 my-wordpress production deployed wordpress-18.0.0 ``` Shows filtering releases by status and properties. - STATUS shows: deployed, superseded, failed, pending-install. - Useful for tracking deployment health. #### Monitor releases with watch and get ```bash # Watch releases in real-time watch helm list --all-namespaces # Get detailed release information helm get all my-nginx # Get only manifest helm get manifest my-nginx # Get release values helm get values my-nginx # Get release hooks helm get hooks my-nginx ``` _exec_ ```bash helm get all my-nginx ``` _output_ ```bash NAME: my-nginx LAST DEPLOYED: Wed Feb 27 14:30:00 UTC 2025 NAMESPACE: default STATUS: deployed REVISION: 1 ``` Shows how to get detailed release information. - helm get all combines chart, values, manifest. **Best practices:** - Monitor releases regularly for drift. - Use labels and namespaces for organization. - Implement alerts on release status changes. **Common errors:** - **release not found**: Check namespace with --all-namespaces flag. ### Release Status and History Checking release status, history, and viewing release details. **Keywords:** status, history, revision, tracking, details #### Check release status and health ```bash # Check release status helm status my-nginx # Get release manifest helm get manifest my-nginx # Get release notes helm get notes my-nginx # Check status with JSON output helm status my-nginx --output json # Verify Kubernetes resources are running kubectl get pods -l app.kubernetes.io/instance=my-nginx ``` _exec_ ```bash helm status my-nginx ``` _output_ ```bash NAME: my-nginx LAST DEPLOYED: Wed Feb 27 14:30:00 UTC 2025 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Shows how to check release deployment status. - Status shows: deployed, superseded, failed, pending-install. - Always verify pods are running with kubectl. #### View release history and revisions ```bash # View release revision history helm history my-nginx # Show specific revision details helm get manifest my-nginx --revision 1 # Get values for specific revision helm get values my-nginx --revision 2 # Compare values between revisions diff <(helm get values my-nginx --revision 1) \ <(helm get values my-nginx --revision 2) # Export revision history helm history my-nginx --output json ``` _exec_ ```bash helm history my-nginx ``` _output_ ```bash REVISION UPDATED STATUS CHART DESCRIPTION 1 Wed Feb 27 14:30:00 superseded nginx-15.1.2 Install complete 2 Wed Feb 27 15:00:00 deployed nginx-15.1.5 Upgrade complete ``` Shows release revision history and change tracking. - Each revision represents a deployment action. - History useful for auditing and rollback. #### Get detailed release information ```bash # Get all release information (chart, values, manifest) helm get all my-nginx # Export release for backup helm get all my-nginx > release-backup.yaml # Get values in different formats helm get values my-nginx --output json helm get values my-nginx --output yaml # Get release chart metadata helm get manifest my-nginx | kubectl apply -f - --dry-run=client # Get release size and resources helm get manifest my-nginx | wc -l ``` _exec_ ```bash helm get all my-nginx ``` _output_ ```bash NAME: my-nginx REVISION: 1 RELEASED: Wed Feb 27 14:30:00 UTC 2025 STATUS: deployed MANIFEST: [kubernetes resources...] ``` Shows comprehensive release information retrieval. - helm get all is combination of multiple subcommands. - Useful for debugging and documentation. **Best practices:** - Regularly check release status for drift. - Keep release history for audit trail. - Monitor revision count to clean up old revisions. **Common errors:** - **no deployed release**: Verify release exists and is deployed with `helm list`. ### Get Release Information and Testing Extracting and analyzing detailed release information. **Keywords:** information, details, testing, validation, debugging #### Extract and analyze release information ```bash # Get release notes/instructions helm get notes my-wordpress # Get release configuration helm get values my-wordpress > current-values.yaml # Get generated Kubernetes manifests helm get manifest my-wordpress > release-manifests.yaml # Get rendered templates helm template my-release bitnami/wordpress # Validate release against schema helm lint path/to/chart/ ``` _exec_ ```bash helm get notes my-wordpress ``` _output_ ```bash WORDPRESS INSTALLATION NOTES... 1. Access credentials... 2. Get administrator password... 3. Access WordPress at... ``` Shows how to extract release notes and configuration. - Release notes contain deployment instructions. - Manifests show actual Kubernetes resources deployed. #### Test and validate release functionality ```bash # List test suites defined in chart helm get hooks my-wordpress # Run release tests helm test my-wordpress # Test with cleanup after failure helm test my-wordpress --cleanup # List test pods kubectl get pods -n default -l app.kubernetes.io/instance=my-wordpress # View test logs kubectl logs -n default -l helm.sh/hook=test ``` _exec_ ```bash helm test my-wordpress ``` _output_ ```bash Pod my-wordpress-test-connection succeeded ``` Shows how to run built-in chart tests. - Not all charts include test suites. - Tests validate basic functionality after deployment. #### Compare current and desired release states ```bash # Get current deployed manifest helm get manifest my-app > current.yaml # Generate what would be deployed with new values helm template my-app bitnami/nginx -f new-values.yaml > desired.yaml # Compare differences diff current.yaml desired.yaml # Dry-run to see exact changes helm upgrade my-app bitnami/nginx -f new-values.yaml --dry-run # Show files that would be created/modified helm upgrade my-app bitnami/nginx -f new-values.yaml --dry-run --debug ``` _exec_ ```bash helm get manifest my-app > current.yaml ``` _output_ ```bash apiVersion: v1 kind: Service metadata: name: my-app-nginx spec: ports: - port: 80 ``` Shows how to compare current and desired states. - Dry-run is essential before production upgrades. **Best practices:** - Always use helm test for validation. - Compare manifests before upgrades. - Save release information for audit trail. **Common errors:** - **release has no hooks or tests**: Not all charts include tests; this is normal. ## Chart Development Creating and publishing custom Helm charts. ### Create and Structure Charts Scaffolding and structuring new Helm charts. **Keywords:** create, scaffold, structure, template, chart-layout #### Create new chart scaffold ```bash # Create new chart with helm helm create my-app # View chart structure tree my-app # Chart directory structure created: # my-app/ # ├── Chart.yaml # Chart metadata # ├── values.yaml # Default values # ├── templates/ # Template files # │ ├── deployment.yaml # │ ├── service.yaml # │ └── configmap.yaml # └── charts/ # Dependencies # Verify chart structure helm lint my-app ``` _exec_ ```bash helm create my-app && helm lint my-app ``` _output_ ```bash [OK] my-app: Chart is well-formed ``` Creates a new chart with standard structure and validates it. - helm create generates basic templates. - Chart.yaml contains metadata. - Values provide default configuration. #### Customize chart for your application ```bash cd my-app # Edit Chart.yaml with app information cat > Chart.yaml << 'EOF' apiVersion: v2 name: my-app description: Custom application chart type: application version: 1.0.0 appVersion: 1.0.0 maintainers: - name: Your Name email: you@example.com EOF # Create custom values cat > values.yaml << 'EOF' replicaCount: 2 image: repository: myrepo/my-app tag: "1.0.0" service: type: ClusterIP port: 8080 EOF # Validate helm lint ``` _exec_ ```bash helm create my-app && cd my-app && helm lint ``` _output_ ```bash [OK] my-app: Chart is well-formed ``` Customizes chart metadata and default values. - Chart.yaml must have apiVersion: v2 for Helm 3. - Version numbers follow semantic versioning. #### Create chart with dependencies ```bash # Create Chart.yaml with dependencies cat > Chart.yaml << 'EOF' apiVersion: v2 name: my-full-app version: 1.0.0 dependencies: - name: postgresql version: "12.0" repository: "https://charts.bitnami.com/bitnami" - name: redis version: "17.0" repository: "https://charts.bitnami.com/bitnami" condition: redis.enabled EOF # Download dependencies helm dependency update # View dependencies ls -la charts/ # Package with dependencies helm package my-full-app ``` _exec_ ```bash helm dependency update my-full-app ``` _output_ ```bash Saving 2 charts Deleting outdated charts ``` Shows how to add and manage chart dependencies. - Dependencies automatically included in package. - Condition allows optional dependencies. **Best practices:** - Use semantic versioning for charts. - Include comprehensive README.md with chart. - Test charts before publishing. **Common errors:** - **apiVersion not recognized**: Use apiVersion: v2 for Helm 3 charts. ### Chart Templating and Variables Creating flexible templates with variables and conditionals. **Keywords:** templating, variables, conditionals, loops, functions #### Use template variables and values ```bash # Create deployment template with variables cat > templates/deployment.yaml << 'EOF' apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Release.Name }}-{{ .Chart.Name }} namespace: {{ .Release.Namespace }} spec: replicas: {{ .Values.replicaCount }} template: metadata: labels: app: {{ .Chart.Name }} spec: containers: - name: {{ .Chart.Name }} image: {{ .Values.image.repository }}:{{ .Values.image.tag }} ports: - containerPort: {{ .Values.service.port }} EOF # Render template with values helm template my-release . -f values.yaml # Test with different values helm template my-release . --set replicaCount=3 ``` _exec_ ```bash helm template my-app ./my-app --set replicaCount=2 ``` _output_ ```bash apiVersion: apps/v1 kind: Deployment metadata: name: my-app-my-app namespace: default spec: replicas: 2 ``` Shows template variable substitution in Kubernetes manifests. - {{ .Release.Name }} renders release name. - {{ .Values.* }} accesses values.yaml entries. #### Conditionals and loops in templates ```bash # Create template with conditionals cat > templates/service.yaml << 'EOF' apiVersion: v1 kind: Service metadata: name: {{ .Release.Name }} spec: type: {{ .Values.service.type }} {{- if eq .Values.service.type "LoadBalancer" }} loadBalancerIP: {{ .Values.service.loadBalancerIP }} {{- end }} ports: - port: {{ .Values.service.port }} EOF # Loop through environment variables cat > templates/configmap.yaml << 'EOF' apiVersion: v1 kind: ConfigMap data: {{- range $key, $val := .Values.env }} {{ $key }}: {{ $val | quote }} {{- end }} EOF # Render and verify helm template my-app . -f values-prod.yaml ``` _exec_ ```bash helm template my-app ./my-app ``` _output_ ```bash apiVersion: v1 kind: Service metadata: name: my-app spec: type: ClusterIP ports: - port: 8080 ``` Shows conditional and loop logic in templates. - {{- removes whitespace before. - {{- end }} closes conditional/loop blocks. #### Built-in functions and filters ```bash # Use built-in template functions cat > templates/deployment.yaml << 'EOF' metadata: name: {{ include "mychart.fullname" . }} labels: {{- include "mychart.labels" . | nindent 4 }} spec: template: metadata: labels: {{- include "mychart.selectorLabels" . | nindent 6 }} spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}" env: - name: APP_NAME value: {{ .Values.appName | upper | quote }} EOF # Create helper template file cat > templates/_helpers.tpl << 'EOF' {{- define "mychart.fullname" -}} {{- .Release.Name }}-{{ .Chart.Name }} {{- end }} {{- define "mychart.labels" -}} app.kubernetes.io/name: {{ include "mychart.fullname" . }} app.kubernetes.io/version: {{ .Chart.AppVersion }} {{- end }} EOF # Render with functions helm template my-app . ``` _exec_ ```bash helm template my-app ./my-app ``` _output_ ```bash metadata: name: my-app-my-app labels: app.kubernetes.io/name: my-app-my-app app.kubernetes.io/version: 1.0 ``` Shows advanced templating with functions and helpers. - _helpers.tpl contains reusable template definitions. - include includes other templates. - Filters like upper, quote transform values. **Best practices:** - Use helper templates to reduce duplication. - Document template variables in values.yaml comments. - Validate templates with helm template before use. **Common errors:** - **execution error at (deployment.yaml:5)**: Check template syntax for proper {{ }} and conditionals. ### Chart Structure and Best Practices Organizing chart files and following best practices. **Keywords:** structure, organization, best-practices, testing, lint #### Complete chart directory structure ```bash my-app/ ├── Chart.yaml # Chart metadata ├── README.md # Chart documentation ├── values.yaml # Default values ├── values-prod.yaml # Production values (optional) ├── charts/ # Dependencies │ ├── postgresql/ │ └── redis/ ├── templates/ # Kubernetes manifests │ ├── NOTES.txt # Post-install notes │ ├── _helpers.tpl # Helper definitions │ ├── deployment.yaml │ ├── service.yaml │ ├── configmap.yaml │ ├── secret.yaml │ ├── ingress.yaml │ └── tests/ ├── crds/ # Custom Resource Definitions │ └── mycrd.yaml └── .helmignore # Files to exclude from chart # Create complete structure helm create my-complete-app ``` _exec_ ```bash find my-app -type f | head -15 ``` _output_ ```bash my-app/Chart.yaml my-app/values.yaml my-app/README.md my-app/templates/... ``` Shows recommended chart directory structure. - NOTES.txt provides post-install instructions. - _helpers.tpl contains reusable helper templates. - .helmignore excludes files from packaging. #### Lint and validate chart quality ```bash # Lint chart for errors and best practices helm lint my-app # Strict linting helm lint my-app --strict # Lint with values helm lint my-app -f values-prod.yaml # Lint multiple charts helm lint ./charts/* # Check chart with template rendering helm template my-app . | kubectl apply -f - --dry-run=client ``` _exec_ ```bash helm lint my-app --strict ``` _output_ ```bash [OK] my-app: Chart is well-formed [WARNING] Chart appVersion not updated in Chart.yaml ``` Validates chart structure and follows best practices. - helm lint checks for common issues. - Always lint before packaging for public release. #### Package and publish chart ```bash # Package chart for distribution helm package my-app # Creates: my-app-1.0.0.tgz # Package into specific directory helm package my-app --destination ./releases # Create index for chart repository helm repo index ./releases --url https://charts.example.com # Generates index.yaml for hosting as chart repo # Install from packaged chart helm install my-release ./my-app-1.0.0.tgz # Install from remote repository helm install my-release myrepo/my-app ``` _exec_ ```bash helm package my-app ``` _output_ ```bash Successfully packaged chart and saved it to: /path/to/my-app-1.0.0.tgz ``` Shows how to package and distribute charts. - Packages are tarballs with chart code. - index.yaml required for chart repositories. **Best practices:** - Always lint before distributing charts. - Include comprehensive documentation. - Version charts semantically. - Test with multiple values configurations. **Common errors:** - **templates must be in 'templates' directory**: Ensure template files are in templates/ subdirectory. ## Advanced Features Advanced Helm capabilities and integrations. ### Plugins and Extensions Extending Helm with plugins and custom functionality. **Keywords:** plugins, extensions, custom-commands, integration, third-party #### Install and use Helm plugins ```bash # List available plugins helm plugin list # Install Helm plugin for secrets management helm plugin install https://github.com/jkroepke/helm-secrets.git # Install Helm diff plugin (shows release changes) helm plugin install https://github.com/databus23/helm-diff.git # Use plugin to show differences helm diff upgrade my-app bitnami/nginx --values new-values.yaml # Uninstall plugin helm plugin uninstall diff # Update plugins helm plugin update ``` _exec_ ```bash helm plugin list ``` _output_ ```bash NAME VERSION DESCRIPTION diff 3.8.1 A Helm plugin to show diffs secrets 4.2.2 Secrets plugin for Helm ``` Shows how to extend Helm with plugins. - Plugins add custom commands to Helm. - Popular: diff, secrets, chartmuseum, s3. #### Popular Helm plugins for DevOps ```bash # Install Helm Diff for preview upgrades helm plugin install https://github.com/databus23/helm-diff.git helm diff upgrade my-app bitnami/nginx # Install Helm Secrets for encrypted values helm plugin install https://github.com/jkroepke/helm-secrets.git helm secrets enc secrets.yaml # Install ChartMuseum plugin to manage chart repos helm plugin install https://github.com/chartmuseum/helm-push.git helm push my-app-1.0.0.tgz chartmuseum # Install S3 plugin for AWS S3 chart repos helm plugin install https://github.com/hypnoglow/helm-s3.git helm s3 init s3-repo --bucket my-charts-bucket ``` _exec_ ```bash helm plugin list ``` _output_ ```bash NAME VERSION DESCRIPTION diff 3.8.1 Show differences in upgrades secrets 4.2.2 Manage secrets in charts ``` Shows essential Helm plugins for DevOps workflows. - Plugins extend Helm functionality. - Install from GitHub repositories. **Best practices:** - Use diff plugin to preview changes. - Use secrets plugin for encrypted values. - Keep plugins updated regularly. **Common errors:** - **plugin not found**: Install plugin with helm plugin install followed by repo URL. ### Hooks and Dependencies Using hooks for deployment lifecycle events and managing chart dependencies. **Keywords:** hooks, dependencies, lifecycle, pre-install, post-install #### Add lifecycle hooks to templates ```bash # Create pre-install hook to setup cat > templates/pre-install-job.yaml << 'EOF' apiVersion: batch/v1 kind: Job metadata: name: {{ .Release.Name }}-pre-install annotations: "helm.sh/hook": pre-install "helm.sh/hook-weight": "-5" spec: template: spec: containers: - name: setup image: busybox command: ["sh", "-c", "echo 'Setting up..."] restartPolicy: Never EOF # Create post-install hook for validation cat > templates/post-install-job.yaml << 'EOF' apiVersion: batch/v1 kind: Job metadata: name: {{ .Release.Name }}-post-install annotations: "helm.sh/hook": post-install "helm.sh/hook-delete-policy": before-hook-creation spec: template: spec: containers: - name: validate image: busybox command: ["sh", "-c", "echo 'Validation complete'"] restartPolicy: Never EOF # Available hooks: pre-install, post-install, pre-upgrade, post-upgrade # pre-delete, post-delete, pre-rollback, post-rollback, test ``` _exec_ ```bash helm install my-app . --dry-run ``` _output_ ```bash apiVersion: batch/v1 kind: Job metadata: name: my-app-pre-install annotations: helm.sh/hook: pre-install ``` Shows how to add lifecycle hooks for setup and validation. - Hooks execute at specific lifecycle events. - hook-weight controls execution order. - hook-delete-policy determines cleanup behavior. #### Manage chart dependencies ```bash # Define dependencies in Chart.yaml cat > Chart.yaml << 'EOF' apiVersion: v2 name: my-full-app dependencies: - name: postgresql version: "12.x.x" repository: "@bitnami" condition: postgresql.enabled - name: redis version: "17.x.x" repository: "@bitnami" tags: - cache alias: redis-cache EOF # Download dependencies helm dependency update # View dependency tree helm dependency list # Build dependency requirements helm dependency build # Remove dependencies helm dependency update --skip-refresh ``` _exec_ ```bash helm dependency list my-app ``` _output_ ```bash NAME VERSION REPOSITORY STATUS postgresql 12.1.6 @bitnami ok redis 17.3.0 @bitnami ok ``` Shows how to manage chart dependencies. - Dependencies are sub-charts included in main chart. - Condition allows optional dependencies. - Alias creates multiple instances of same chart. **Best practices:** - Use hooks for setup and cleanup tasks. - Keep dependency versions flexible with ranges. - Always test hooks before production use. **Common errors:** - **hook not executing**: Verify annotation syntax as hooks rely on annotations. ## Best Practices Production-ready Helm practices and patterns. ### Configuration Management Managing configurations securely and consistently. **Keywords:** configuration, secrets, configmap, security, best-practice #### Secure secret management with Helm ```bash # Store secrets in Kubernetes Secret kubectl create secret generic app-secrets \ --from-literal=db-password=secure123 \ --from-literal=api-key=sk_live_abc123 # Reference secret in values cat > values.yaml << 'EOF' database: existingSecret: app-secrets existingSecretPasswordKey: db-password EOF # Install using secret reference helm install my-app myrepo/app -f values.yaml # Never commit secrets to git echo "secrets.yaml" >> .gitignore # Use encrypted values files helm plugin install https://github.com/jkroepke/helm-secrets.git helm secrets enc secrets.yaml ``` _exec_ ```bash kubectl create secret generic app-secrets --from-literal=password=secure ``` _output_ ```bash secret/app-secrets created ``` Shows secure secret management in Helm deployments. - Use Kubernetes secrets instead of plain values. - Encrypt secret files before committing. - Reference existing secrets in charts. #### Environment-specific configurations ```bash # Create base values cat > values.yaml << 'EOF' env: development replicaCount: 1 image: tag: latest resources: requests: memory: "128Mi" EOF # Create production overrides cat > values-prod.yaml << 'EOF' env: production replicaCount: 3 image: tag: v1.2.3 resources: requests: memory: "512Mi" limits: memory: "1Gi" EOF # Install with environment-specific values helm install my-app myrepo/app -f values.yaml -f values-prod.yaml # For staging helm install my-app myrepo/app -f values.yaml -f values-staging.yaml ``` _exec_ ```bash helm template my-app myrepo/app -f values.yaml -f values-prod.yaml ``` _output_ ```bash spec: replicas: 3 template: spec: containers: - name: app image: app:v1.2.3 ``` Shows managing environment-specific configurations. - Later files override earlier ones. - Keep production values separate and secure. **Best practices:** - Use Kubernetes secrets for sensitive data. - Version control only non-sensitive values. - Use separate values files per environment. - Encrypt secret files with helm-secrets. **Common errors:** - **secret not found**: Create secret before deploying with kubectl create secret. ### Production Guidelines and Monitoring Best practices for production Helm deployments. **Keywords:** production, monitoring, high-availability, disaster-recovery, reliability #### Production-ready Helm checklist ```bash # 1. Use specific chart versions helm install my-app myrepo/app --version 1.2.3 # 2. Pin all image tags (no 'latest') cat > values.yaml << 'EOF' image: repository: myrepo/my-app tag: "v1.2.3" pullPolicy: IfNotPresent replicaCount: 3 resources: requests: cpu: 250m memory: 256Mi limits: cpu: 500m memory: 512Mi livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 EOF # 3. Enable high availability helm install my-app myrepo/app \ --set replicaCount=3 \ --set podDisruptionBudget.minAvailable=1 # 4. Test deployment helm test my-app # 5. Monitor release helm status my-app kubectl get pods -l app=my-app ``` _exec_ ```bash helm status my-app && kubectl get pods ``` _output_ ```bash NAME: my-app STATUS: deployed NAME READY STATUS my-app-xxx 1/1 Running my-app-yyy 1/1 Running ``` Shows production-ready deployment configuration. - Pin versions for reproducibility. - Set resource requests/limits. - Enable health probes for automatic healing. #### Backup and disaster recovery ```bash # Backup release configuration helm get all my-app > backup-my-app.yaml # Backup all releases for release in $(helm list -q); do helm get all $release > backup-$release.yaml done # Backup using Velero plugin # velero backup create my-app-backup # Test restoration helm delete my-app helm install my-app -f backup-my-app.yaml # Implement disaster recovery tests regularly # Schedule backups: kubectl apply -f schedule.yaml ``` _exec_ ```bash helm get all my-app > release-backup.yaml ``` _output_ ```bash NAME: my-app LAST DEPLOYED: Wed Feb 27 14:30:00 UTC 2025 [Full release information backed up] ``` Shows backup and recovery procedures. - Back up critical releases regularly. - Test recovery procedures before disaster. - Use solutions like Velero for cluster-wide backup. **Best practices:** - Always test deployments before production. - Implement monitoring and alerting. - Backup releases regularly and test recovery. - Use GitOps for release management. - Implement gradual rollout strategies. - Monitor resource usage and metrics. **Common errors:** - **pod not ready after deployment**: Check logs with kubectl logs and verify image availability.