helmInstall, upgrade and roll back apps with Helm charts
Helm is the package manager for Kubernetes. A chart is a set of templated manifests; helm renders it with your values and installs it as a release that it versions, so you can upgrade, inspect the history and roll back the whole app as one unit.
helm (install | upgrade --install | list | history | rollback | uninstall | template | lint | repo) [RELEASE] [CHART] [-f values.yaml] [--set k=v] [-n NS]kubectl top doesn't work on the new EKS cluster. Install metrics-server from its official chart repository.
helmThe Helm CLI. It talks to the Kubernetes API directly using your kubeconfig; there is no server component.
Helm runs entirely on your machine. It loads the chart (Chart.yaml, values.yaml, templates/), merges values (chart defaults, then each -f file, then --set), and renders every template with Go templates plus Sprig functions into plain Kubernetes YAML. It then reads the release's latest record, stored as a Secret named sh.helm.release.v1.api.vN in the release namespace (gzipped, base64 JSON holding the chart, values and rendered manifest). For an upgrade it compares the old manifest, the new one and the live objects (Helm 3 uses a three-way strategic merge patch; Helm 4 uses server-side apply) and sends creates, patches and deletes to the API server, running any hook Jobs (pre-upgrade migrations) in order. It records the new revision as pending-upgrade, then deployed or failed; with --wait it watches readiness first. rollback re-applies the manifest from an older revision as a new revision. helm template does only the rendering step and needs no cluster.
Helm renders the chart on your machine, applies the difference to the cluster, and records every revision as a Secret so it can roll back.
helm reads Chart.yaml, the default values.yaml and the templates, from a directory, a .tgz, a repository or an OCI registry.
upgrade --installInstall or upgrade in one idempotent command-f FILE / --set k=vValues files and single overrides (--set wins)-n NS --create-namespaceTarget namespace; create it if missing--wait --timeout 10mWait for resources to be ready before success--atomicRoll back automatically on failure (Helm 4: --rollback-on-failure)--dry-run=server / --debugRender and validate against the cluster, change nothinglist -AReleases in all namespaceshistory / rollback REL NShow revisions; return to revision Ntemplate / lintRender locally / check a chart for problems (no cluster)get values|manifest RELShow the values or rendered YAML of a releaserepo add / repo updateRegister a chart repository / refresh its indexuninstall RELDelete the release's objects and its historyhelm install in a pipelineThe second run fails with 'cannot re-use a name that is still in use'.
helm upgrade --install RELEASE CHART (idempotent)Upgrading without --wait (or --atomic) and calling the deploy doneHelm reports deployed as soon as the API accepts the objects, even if the pods never start.
helm upgrade --install ... --wait --timeout 10m --atomicEditing Helm-managed objects with kubectl editHelm doesn't know; the next upgrade overwrites the change or fails on a conflict.
Change the values or chart and run helm upgradePutting passwords in values files committed to Git or in --set on the command lineThey end up in Git history, shell history and the release Secret in plain (base64) form.
Reference existing Secrets (External Secrets, Sealed Secrets, SOPS) from the chartTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command that installs or upgrades the release web from ./charts/web into namespace web-demo, creating the namespace if needed, with replicaCount=3, and rolls back automatically on failure.
Write the commands to see which values the release api in prod is using and the YAML it rendered.
Read this history and say what you'd run: revision 6 deployed (2.4.1), revision 7 failed (2.5.0), revision 8 pending-upgrade (2.5.1).
Add the bitnami repo, install bitnami/nginx as release web into staging, list what it created, then uninstall it.
helmInstall, upgrade and roll back apps with Helm charts
Helm is the package manager for Kubernetes. A chart is a set of templated manifests; helm renders it with your values and installs it as a release that it versions, so you can upgrade, inspect the history and roll back the whole app as one unit.
helm (install | upgrade --install | list | history | rollback | uninstall | template | lint | repo) [RELEASE] [CHART] [-f values.yaml] [--set k=v] [-n NS]kubectl top doesn't work on the new EKS cluster. Install metrics-server from its official chart repository.
helmThe Helm CLI. It talks to the Kubernetes API directly using your kubeconfig; there is no server component.
Helm runs entirely on your machine. It loads the chart (Chart.yaml, values.yaml, templates/), merges values (chart defaults, then each -f file, then --set), and renders every template with Go templates plus Sprig functions into plain Kubernetes YAML. It then reads the release's latest record, stored as a Secret named sh.helm.release.v1.api.vN in the release namespace (gzipped, base64 JSON holding the chart, values and rendered manifest). For an upgrade it compares the old manifest, the new one and the live objects (Helm 3 uses a three-way strategic merge patch; Helm 4 uses server-side apply) and sends creates, patches and deletes to the API server, running any hook Jobs (pre-upgrade migrations) in order. It records the new revision as pending-upgrade, then deployed or failed; with --wait it watches readiness first. rollback re-applies the manifest from an older revision as a new revision. helm template does only the rendering step and needs no cluster.
Helm renders the chart on your machine, applies the difference to the cluster, and records every revision as a Secret so it can roll back.
helm reads Chart.yaml, the default values.yaml and the templates, from a directory, a .tgz, a repository or an OCI registry.
upgrade --installInstall or upgrade in one idempotent command-f FILE / --set k=vValues files and single overrides (--set wins)-n NS --create-namespaceTarget namespace; create it if missing--wait --timeout 10mWait for resources to be ready before success--atomicRoll back automatically on failure (Helm 4: --rollback-on-failure)--dry-run=server / --debugRender and validate against the cluster, change nothinglist -AReleases in all namespaceshistory / rollback REL NShow revisions; return to revision Ntemplate / lintRender locally / check a chart for problems (no cluster)get values|manifest RELShow the values or rendered YAML of a releaserepo add / repo updateRegister a chart repository / refresh its indexuninstall RELDelete the release's objects and its historyhelm install in a pipelineThe second run fails with 'cannot re-use a name that is still in use'.
helm upgrade --install RELEASE CHART (idempotent)Upgrading without --wait (or --atomic) and calling the deploy doneHelm reports deployed as soon as the API accepts the objects, even if the pods never start.
helm upgrade --install ... --wait --timeout 10m --atomicEditing Helm-managed objects with kubectl editHelm doesn't know; the next upgrade overwrites the change or fails on a conflict.
Change the values or chart and run helm upgradePutting passwords in values files committed to Git or in --set on the command lineThey end up in Git history, shell history and the release Secret in plain (base64) form.
Reference existing Secrets (External Secrets, Sealed Secrets, SOPS) from the chartTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command that installs or upgrades the release web from ./charts/web into namespace web-demo, creating the namespace if needed, with replicaCount=3, and rolls back automatically on failure.
Write the commands to see which values the release api in prod is using and the YAML it rendered.
Read this history and say what you'd run: revision 6 deployed (2.4.1), revision 7 failed (2.5.0), revision 8 pending-upgrade (2.5.1).
Add the bitnami repo, install bitnami/nginx as release web into staging, list what it created, then uninstall it.