Kubernetes Packaging and Customization Scope

Kubernetes Packaging and Customization Scope is the definition of what falls within the discipline of packaging Kubernetes application manifests for distribution and adapting them per environment, covering templating tools such as Helm, overlay-based tools such as Kustomize, the boundary between packaging a workload and extending the cluster's own API, and where packaging concerns end and broader deployment automation begins.

What Packaging and Customization Covers

Templating and Parameterization

At its core, this scope covers taking a set of Kubernetes manifests, Deployment, Service, ConfigMap, and making them reusable across multiple environments or installations by parameterizing the values that legitimately differ, replica counts, image tags, resource limits, ingress hostnames, while keeping the underlying structure of the manifests fixed and version-controlled.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-web
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Environment-Specific Overlays

Distinct from templating, this scope also covers overlay-based customization, where a base set of manifests is patched for a specific environment without any templating language involved, producing fully rendered YAML at each layer rather than substituting values into placeholders.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patches:
  - path: increase-replicas.yaml
    target:
      kind: Deployment
      name: web

The Boundary With Extensibility and Operators

Packaging Consumes Extensions, It Does Not Create Them

Packaging and customization tooling is concerned with how manifests, including manifests for custom resources whose CRDs are installed separately, are templated and distributed; it is not concerned with implementing the CRDs, controllers, or webhooks themselves, which belong to the extensibility and Operators area covered separately.

# a Helm chart can template a custom resource instance,
# but does not itself define the CRD or reconcile it
apiVersion: databases.example.com/v1
kind: PostgresCluster
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.dbReplicas }}

A chart bundling both the CRD manifest and a custom resource instance using that CRD is common in practice, but the packaging tool's role in that scenario remains limited to templating and installation ordering, not to implementing the reconciliation logic that gives the custom resource any effect.

The Boundary With Broader Deployment Automation

Packaging Is Not CI/CD

Packaging and customization scope stops at producing a correct, environment-appropriate set of manifests; it does not extend to the pipeline mechanics of testing, promoting, or triggering deployment of those manifests, which belongs to continuous delivery tooling and GitOps controllers that consume packaged output as their input.

helm template ./chart -f values-production.yaml > rendered.yaml
# what happens to rendered.yaml next (apply, review, promote)
# is a CI/CD or GitOps concern, not a packaging concern

Tool Selection Considerations

Templating vs. Overlay Trade-offs

Helm-style templating excels at parameterizing values across many installations of the same chart (a SaaS product installed for many customers, each with different scale and configuration), while Kustomize-style overlays excel at expressing a small number of environment-specific structural differences (staging versus production) against a shared base, without introducing a templating language's own syntax and control flow into what should otherwise remain plain YAML.

Composability Considerations

Both approaches support composition, Helm through subcharts and dependencies, Kustomize through layered bases and overlays referencing other overlays, and packaging scope includes designing that composition structure so that shared configuration lives in one place and environment- or tenant-specific configuration is isolated to the smallest necessary layer.

Registry and Distribution Concerns

Where Packages Are Published

helm push mychart-1.2.0.tgz oci://registry.example.com/charts

Packaging scope includes how a finished chart or kustomization bundle is published and versioned for reuse, commonly via an OCI-compliant registry, a Helm repository index, or a Git repository directly referenced by Kustomize's remote base support, each with different implications for version pinning, access control, and reproducibility of a given installation.

Relationship to the Broader Packaging and Customization Area

This scope statement establishes the working boundary for every subsequent topic in Kubernetes Packaging and Customization Basics: templating syntax, values management, overlay patching, and chart composition all operate within the space defined here, producing correct manifests for a given environment, explicitly excluding both the extension mechanisms that give custom resources their behavior and the pipeline automation that decides when and how those manifests are actually applied to a cluster.