Kubernetes Packaging and Customization Areas

Kubernetes Packaging and Customization Areas are the distinct tool families and techniques available for turning a set of Kubernetes manifests into a distributable, environment-adaptable artifact, spanning templating engines, overlay-based patching, configuration-as-code languages, image-level customization, and the registries used to distribute the resulting packages.

Templating Engines

Helm Charts

Helm packages manifests as a chart, a directory of Go-template files rendered against a values.yaml file, distributed as a single versioned artifact and installed as a named Release that Helm itself tracks in-cluster.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-web
spec:
  replicas: {{ .Values.replicaCount | default 2 }}

helm install my-app ./chart -f values-production.yaml

Jsonnet and CUE

Jsonnet and CUE express Kubernetes manifests as data computed by a general-purpose configuration language rather than text templates, allowing functions, imports, and type-checked schemas to generate YAML programmatically, which scales better than string templating for very large, highly parameterized manifest sets at the cost of a steeper learning curve.

local deployment(name, replicas) = {
  apiVersion: "apps/v1",
  kind: "Deployment",
  metadata: { name: name },
  spec: { replicas: replicas },
};
deployment("web", 3)

Overlay-Based Patching

Kustomize Bases and Overlays

Kustomize takes a different approach entirely, treating manifests as plain YAML with no template syntax, and expressing environment differences as structural patches applied to a shared base.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
namePrefix: prod-
commonLabels:
  environment: production

kubectl apply -k overlays/production

Generators and Transformers

configMapGenerator:
  - name: app-config
    literals:
      - LOG_LEVEL=info

Kustomize's built-in generators produce ConfigMap and Secret objects with content-hash suffixes appended to their names automatically, which forces a rolling update of any Deployment referencing them whenever the generated content changes, a mechanism distinct from Helm's manual versioning of such objects.

Lifecycle Hooks and Ordered Actions

Helm Hooks

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
  annotations:
    helm.sh/hook: pre-install,pre-upgrade

Helm hooks let a chart declare Jobs or other resources that run at specific points in a release's lifecycle, before installation, after upgrade, on rollback, encoding imperative sequencing (a database migration that must run before new application pods start) that pure declarative manifests cannot express on their own.

Composition and Reuse

Helm Subcharts

dependencies:
  - name: postgresql
    version: "12.x"
    repository: "https://charts.bitnami.com/bitnami"

A chart can declare dependencies on other charts, composing a complex application (a web tier plus a database plus a cache) from independently maintained, independently versioned building blocks, with values passed down into subcharts through a defined namespacing convention.

Kustomize Remote Bases

resources:
  - github.com/example-org/base-manifests//app?ref=v1.2.0

Kustomize supports referencing a base directly from a remote Git repository at a pinned ref, letting an overlay build on a shared, centrally maintained base without vendoring a local copy, though this introduces a network dependency at render time that a locally vendored base avoids.

Distribution and Registries

OCI-Compliant Chart Registries

helm push mychart-1.2.0.tgz oci://registry.example.com/charts
helm install my-app oci://registry.example.com/charts/mychart --version 1.2.0

Modern Helm distribution increasingly uses standard OCI registries (the same infrastructure used for container images) rather than a dedicated chart repository index, unifying image and chart artifact storage, versioning, and access control under one system.

Image-Level Customization

Build-Time vs. Runtime Customization

Distinct from manifest-level customization, packaging concerns also include how a container image itself is parameterized, via build arguments baked in at image-build time versus environment variables and mounted configuration injected at runtime, a choice that determines whether a configuration change requires rebuilding an image or only re-applying a manifest.

ARG APP_ENV=production
ENV APP_ENV=${APP_ENV}

Relationship to Packaging and Customization Scope

These areas are the concrete tool families operating within the boundary already established by packaging and customization scope: templating engines, overlay tools, configuration languages, and image customization each solve a different facet of "produce the right manifests, with the right parameters, for a given environment," and most real deployments combine several of these areas together, a Kustomize overlay generating environment-specific patches over a Helm-rendered base, for instance, rather than relying on any single tool in isolation.