Advanced Helm Tips and Tricks: Uncommon Commands and Flags for Better Kubernetes Management

Managing Kubernetes resources effectively can sometimes feel overwhelming, but Helm, the Kubernetes package manager, offers several commands and flags that make the process smoother and more intuitive. In this article, we’ll dive into some lesser-known Helm commands and flags, explaining their uses, benefits, and practical examples.

1. helm get values: Retrieving Deployed Chart Values

The helm get values command is essential when you need to see the configuration values of a deployed Helm chart. This is particularly useful when you have a chart deployed but lack access to its original configuration file. With this command, you can achieve an “Infrastructure as Code” approach by capturing the current state of your deployment.

Usage:

helm get values <release-name> \[flags]

• <release-name>: The name of your Helm release.
  

Example:

To get the values of a deployed chart named my-release:

helm get values my-release --namespace my-namespace

This command outputs the current values used for the deployment, which is valuable for documentation, replicating the environment, or modifying deployments.

2. Understanding helm upgrade Flags: --reset-values, --reuse-values, and --reset-then-reuse

The helm upgrade command is typically used to upgrade or modify an existing Helm release. However, the behavior of this command can be finely tuned using several flags: --reset-values, --reuse-values, and --reset-then-reuse.

• --reset-values: Ignores the previous values and uses only the values provided in the current command. Use this flag when you want to override the existing configuration entirely.
  

Example Scenario: You are deploying a new version of your application, and you want to ensure that no old values are retained.

  helm upgrade my-release my-chart --reset-values --set newKey=newValue

• --reuse-values: Reuses the previous release’s values and merges them with any new values provided. This flag is useful when you want to keep most of the old configuration but apply a few tweaks.
  

Example Scenario: You need to add a new environment variable to an existing deployment without affecting the other settings.

  helm upgrade my-release my-chart --reuse-values --set newEnv=production

• --reset-then-reuse: A combination of the two. It resets to the original values and then merges the old values back, allowing you to start with a clean slate while retaining specific configurations.
  

Example Scenario: Useful in complex environments where you want to ensure the chart is using the original default settings but retain some custom values.

  helm upgrade my-release my-chart --reset-then-reuse --set version=2.0

3. helm lint: Ensuring Chart Quality in CI/CD Pipelines

The helm lint command checks Helm charts for syntax errors, best practices, and other potential issues. This is especially useful when integrating Helm into a CI/CD pipeline, as it ensures your charts are reliable and adhere to best practices before deployment.

Usage:

helm lint <chart-path> [flags]

• <chart-path>: Path to the Helm chart you want to validate.
  

Example:

helm lint ./my-chart/

This command scans the my-chart directory for issues like missing fields, incorrect YAML structure, or deprecated usage. If you’re automating deployments, integrating helm lint into your pipeline helps catch problems early.

Integrating helm lint in a CI/CD Pipeline:

In a Jenkins pipeline, for example, you could add the following stage:

pipeline {
  agent any
  stages {
stage('Lint Helm Chart') {
  steps {
    script {
      sh 'helm lint ./my-chart/'
    }
  }
}
// Other stages like build, test, deploy
  }
}

By adding this stage, you ensure that any syntax or structural issues are caught before proceeding to build or deployment stages.

4. helm rollback: Reverting to a Previous Release

The helm rollback command allows you to revert a release to a previous version. This can be incredibly useful in case of a failed upgrade or deployment, as it provides a way to quickly restore a known good state.

Usage:

helm rollback <release-name> [revision] [flags]

• <release-name>: The name of your Helm release.
• [revision]: The revision number to which you want to roll back. If omitted, Helm will roll back to the previous release by default.
  

Example:

To roll back a release named my-release to its previous version:

helm rollback my-release

To roll back to a specific revision, say revision 3:

helm rollback my-release 3

This command can be a lifesaver when a recent change breaks your application, allowing you to quickly restore service continuity while investigating the issue.

5. helm verify: Validating a Chart Before Use

The helm verify command checks the integrity and validity of a chart before it is deployed. This command ensures that the chart’s package file has not been tampered with or corrupted. It’s particularly useful when you are pulling charts from external repositories or using charts shared across multiple teams.

Usage:

helm verify <chart-path>

• <chart-path>: Path to the Helm chart archive (.tgz file).
  

Example:

To verify a downloaded chart named my-chart:

helm verify ./my-chart.tgz

If the chart passes the verification, Helm will output a success message. If it fails, you’ll see details of the issues, which could range from missing files to checksum mismatches.

Conclusion

Leveraging these advanced Helm commands and flags can significantly enhance your Kubernetes management capabilities. Whether you are retrieving existing deployment configurations, fine-tuning your Helm upgrades, or ensuring the quality of your charts in a CI/CD pipeline, these tricks help you maintain a robust and efficient Kubernetes environment.