Helm Chart Offline Packaging

The packaging process recursively resolves and bundles all subcharts and their transitive dependencies into a single archive. This eliminates the need for the target cluster to reach out to external Helm repositories. The final package is a .tgz file containing the full chart tree, ensuring that a helm install command in a disconnected environment will not fail due to a missing requirements.yaml dependency.

A critical companion step is the relocation of all referenced container images. Tools like helm chart save or skopeo are used to:

• Scan the rendered manifests for every image reference
• Pull images from external registries
• Re-tag them to point to a private registry accessible in the air gap
• Push them to that internal registry This ensures that when a pod is scheduled, the kubelet can pull the image without an internet connection.

The output is a single, versioned, immutable .tgz artifact. This archive becomes the source of truth for that specific release in the disconnected environment. Its immutability guarantees that the exact same set of files and metadata tested in staging is what gets deployed to production, eliminating configuration drift caused by dynamic repository lookups. Verification is done via a sha256 checksum.

Modern Helm packaging leverages Open Container Initiative (OCI) registries as a universal storage layer. Instead of relying solely on legacy chart repositories, a chart and its associated images can be bundled and pushed as OCI artifacts to a single private registry. This unifies the storage and access control model for both application code and its runtime dependencies under one standard API.

The packaged chart is explicitly designed for environments with a physical air gap. It assumes zero external network egress. All hooks, init containers, and custom resource definitions (CRDs) must be pre-cached. The packaging workflow often integrates with a private registry mirroring script to automate the entire bundling process, converting a dynamic Helm chart into a static, air-gap-compliant deployment unit.

A deployment method where raw Kubernetes YAML manifests are pre-rendered and stored as files, eliminating the need for a live connection to a Helm repository or template engine.

• Use helm template to generate static manifests from a chart
• The resulting flat files can be version-controlled in Git and applied with kubectl apply -f
• Removes the runtime dependency on Tiller or Helm in the target cluster

A deployment paradigm where servers and containers are never modified after creation. Instead, a new, updated instance is provisioned from a common image to replace the old one.

• Ensures absolute consistency between the packaged chart and the running state
• Prevents configuration drift in disconnected clusters where manual fixes are tempting
• A core principle behind the reliability of Helm-based rollouts and rollbacks