--- title: "Helm" description: "Helm is the package manager for Kubernetes that simplifies deploying, managing, and upgrading applications through reusable charts. This cheatsheet covers the core 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, which are templated Kubernetes manifests, to build reusable, configurable application packages. ## Benefits - Deploy an entire application stack with a single command. - Share and reuse charts across projects and teams. - Override values without editing templates. - Track revisions and roll back to a previous release. - Include and manage chart dependencies automatically. - Deploy several 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 The sections above cover Helm from basic commands through production deployment practices. ## 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. #### 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**: Check the release name and confirm it 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 ``` Verifies the 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:** - **helm: command not found**: Check that the install location is on your PATH, or reinstall with your platform's package manager. ### 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 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. - Prefer certificate-based auth over stored passwords. **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. - Check this before installation to understand customization options. - helm show values is useful 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**: Add the repository, then run `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 the YAML syntax in the values file, including the 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 avoids 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**: Check that a previous revision exists in the 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...] ``` Retrieves detailed release information. - 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. - Run a dry-run 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 a detailed README.md with the 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 detailed documentation. - Version charts semantically. - Test with multiple values configurations. **Common errors:** - **templates must be in 'templates' directory**: Move the template files into the 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 commonly used 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.