Study guide
2.3 Installing Cluster Components with Helm & Kustomize
Certified Kubernetes Administrator CKA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CKA Exam Environment & Cluster Architecture
1.1 CKA Exam Mechanics, Scoring & Remote Terminal Environment 1.2 Kubernetes Control Plane & Worker Node Components 1.3 etcd Architecture, Clustering & Raft Consensus 1.4 Initializing Clusters with Kubeadm 1.5 Highly Available (HA) Control Plane Topologies 1.6 Cluster Lifecycle & Step-by-Step Upgrades 1.7 etcd Snapshot Backup and Restore Procedures
2 Chapter 2: Cluster Extensions, Packaging & RBAC
2.1 Kubernetes TLS Certificates & PKI Infrastructure 2.2 Managing Kubeconfig Files, Users, & Contexts 2.3 Installing Cluster Components with Helm & Kustomize 2.4 Role-Based Access Control (RBAC): Roles & RoleBindings 2.5 ClusterRoles & ClusterRoleBindings 2.6 Custom Resource Definitions (CRDs) & Operators 2.7 Pod Security Standards (PSS) & Admission Controllers
3 Chapter 3: Workloads, Lifecycle & Pod Scheduling
3.1 Pod Lifecycle, Multi-Container Patterns & Init Containers 3.2 Deployments: Rolling Updates, Rollouts & Rollbacks 3.3 DaemonSets & StatefulSets Architecture 3.4 Batch Workloads: Jobs & CronJobs 3.5 Managing ConfigMaps & Sensitive Data with Secrets 3.6 Resource Requests, Limits & Namespace ResourceQuotas 3.7 NodeSelectors, Node Affinity & Anti-Affinity 3.8 Node Taints & Pod Tolerations 3.9 Autoscaling: Horizontal Pod Autoscaler (HPA) & Custom Metrics
4 Chapter 4: Services, Networking & Ingress Architecture
4.1 Kubernetes IP-per-Pod Model & CNI Plugins (Flannel, Calico, Cilium) 4.2 Services Deep Dive: ClusterIP, NodePort, LoadBalancer & EndpointSlices 4.3 Kube-Proxy Service Dataplane: iptables, nftables, IPVS & eBPF 4.4 CoreDNS Configuration, Resolution & Custom Forwarding 4.5 NetworkPolicies: Ingress, Egress & Default-Deny Isolation 4.6 Ingress Architecture, Controllers & Path-Based Routing 4.7 Gateway API: GatewayClass, Gateway, HTTPRoute & Traffic Splitting 4.8 External Traffic Ingress: NodePort, Cloud LoadBalancers & MetalLB
5 Chapter 5: Storage Architecture & Persistent Volumes
5.1 Ephemeral Volumes, EmptyDir, HostPath & Config Volumes 5.2 PersistentVolumes (PV) & PersistentVolumeClaims (PVC) Lifecycle 5.3 StorageClasses, Dynamic Provisioning & VolumeBindingModes 5.4 Storage Access Modes, Reclaim Policies & Volume Expansion 5.5 Container Storage Interface (CSI) Architecture & Drivers 5.6 StatefulSet VolumeClaimTemplates & Persistent Storage Workflows
6 Chapter 6: Advanced Troubleshooting, Monitoring & Maintenance
6.1 Systematic Kubernetes Troubleshooting Methodology 6.2 Node Failure, Kubelet Diagnostics & Systemd Services 6.3 Control Plane Failures, Static Pods & Component Logs 6.4 etcd Troubleshooting, Quorum Loss & Database Defragmentation 6.5 Pod Startup Failures, CrashLoopBackOff & OOMKilled Diagnostics 6.6 Workload Scheduling Failures & Resource Constraint Resolution 6.7 Container & Node Logging Architecture, Journalctl & Fluentd 6.8 Metrics Server, Resource Utilization & Kubectl Top 6.9 Service, Endpoint & Ingress Connectivity Troubleshooting 6.10 Storage Failures: PVC Pending, Mount Failures & Multi-Attach Errors 6.11 NetworkPolicy Isolation & CoreDNS Resolution Diagnostics
2.3 Installing Cluster Components with Helm & Kustomize
Key Takeaways Explain This Topic AI
Helm installs a chart as a named release; values customize rendered manifests, while release history enables inspection, upgrades, and rollbacks.
Use helm template or helm install --dry-run to inspect rendered resources before changing a cluster, and remember that rendered output can contain Secrets.
Kustomize composes ordinary YAML through a kustomization.yaml file and is built into kubectl through kubectl kustomize and kubectl apply -k.
A Kustomize base holds shared resources, while overlays apply environment-specific namespace, image, label, replica, or patch changes without copying the base.
Troubleshoot installation failures by separating render errors, API validation errors, readiness failures, RBAC denials, and ownership conflicts.
Last updated: August 2026
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
- Term Meaning
- Chart Versioned package containing templates, default values, metadata, and optional CRDs
- Release One installed instance of a chart in a namespace
- Values Inputs merged into templates to customize the rendered resources
- Repository / OCI registry Distribution location from which charts are fetched
- Revision Release-history entry created by install, upgrade, or rollback
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
- Need Helm Kustomize
- Install a third-party packaged component Strong fit Possible if raw manifests are supplied
- Parameterized templates and chart dependencies Yes No template language
- Track release revisions and rollback Yes No
- Reuse plain YAML with environment overlays Possible, but not its main model Strong fit
- Preview final Kubernetes YAML helm template kubectl kustomize
Use a layered diagnostic sequence:
Render: Does Helm/Kustomize generate the intended YAML?
Validate: Does kubectl apply --dry-run=server accept it?
Apply: Are ownership, namespace, or RBAC errors reported?
Observe: Do Deployments, DaemonSets, Jobs, and CRDs become healthy?
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.