2.3 Installing Cluster Components with Helm & Kustomize

2.3 Installing Cluster Components with Helm & Kustomize

The current CKA blueprint explicitly requires using Helm and Kustomize to install cluster components. Both tools produce Kubernetes objects, but they solve different packaging problems. Helm renders parameterized templates and tracks each installation as a release. Kustomize transforms ordinary YAML using declarative overlays and does not add a release object of its own.

1. Helm's Object Model

A release name and namespace identify the installation. Two releases can use the same chart with different values:

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm repo update
helm search repo metrics-server
helm show values metrics-server/metrics-server > /tmp/default-values.yaml

helm install metrics metrics-server/metrics-server \
  --namespace kube-system \
  --set replicas=2

Use the chart and values supplied by the task. Internet repositories, versions, and flags evolve; do not memorize an unofficial repository URL as an exam guarantee.

2. Render Before You Install

Rendering separates template problems from cluster problems:

# Render locally without contacting the API server
helm template metrics metrics-server/metrics-server \
  --namespace kube-system -f values.yaml > /tmp/rendered.yaml

# Simulate an installation and include Helm diagnostics
helm install metrics metrics-server/metrics-server \
  --namespace kube-system -f values.yaml --dry-run --debug

# Ask the API server to validate the rendered objects without persisting them
kubectl apply --dry-run=server -f /tmp/rendered.yaml

Rendered output can include Secret data. Avoid copying it into notes, logs, or shared terminals. Inspect API versions, namespaces, selectors, RBAC subjects, and image names before applying.

3. Helm Release Lifecycle

helm list -A
helm status metrics -n kube-system
helm get values metrics -n kube-system
helm get manifest metrics -n kube-system
helm history metrics -n kube-system

# Update an existing release, or install it if absent
helm upgrade --install metrics metrics-server/metrics-server \
  -n kube-system -f values.yaml

# Return to a known revision
helm rollback metrics 1 -n kube-system

# Remove the release's managed resources
helm uninstall metrics -n kube-system

A failed release is not diagnosed by repeatedly rerunning install. First check helm status, release history, Kubernetes Events, workload status, and controller logs. Common failures include an existing resource owned by another release, missing CRDs, invalid values, insufficient RBAC, unavailable images, and readiness timeouts.

4. Kustomize Bases and Overlays

Kustomize operates on valid Kubernetes YAML. A base defines reusable objects:

app/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    └── production/
        ├── kustomization.yaml
        └── resources-patch.yaml

A minimal base kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml

The production overlay references the base and changes only what differs:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
namespace: production
namePrefix: prod-
images:
- name: registry.example/app
  newTag: v2.4.1
patches:
- path: resources-patch.yaml
  target:
    kind: Deployment
    name: web

Preview and apply with kubectl's built-in Kustomize support:

kubectl kustomize app/overlays/production
kubectl diff -k app/overlays/production
kubectl apply -k app/overlays/production
kubectl delete -k app/overlays/production

A patch target matches the resource before name transformations are applied. If a patch appears ignored, inspect the rendered output and verify the target group, version, kind, name, namespace, labels, and patch indentation.

5. Choosing and Troubleshooting the Tool

Use a layered diagnostic sequence:

1. Render: Does Helm/Kustomize generate the intended YAML?
2. Validate: Does kubectl apply --dry-run=server accept it?
3. Apply: Are ownership, namespace, or RBAC errors reported?
4. Observe: Do Deployments, DaemonSets, Jobs, and CRDs become healthy?
5. Inspect: Use Events, logs, release status, and the exact rendered manifest to locate the failed layer.

The exam tests the resulting cluster state, so always confirm both the packaging tool's view and Kubernetes' view of the installed component.