KCNA — Kubernetes and Cloud Native Associate
Packaging the Same App Twice, with Helm and Kustomize
Goal
You package the same Deployment with two delivery tools. With Helm you create a chart, change the values, and template, install, and upgrade it, and with Kustomize you build a base and then layer replicas and labels over it with a prod overlay. You check "which manifest was actually applied to the cluster" from both the Helm release and the Kustomize output.
Why it matters
A Kubernetes manifest does not end with one hand-written YAML. Replicas, images, and labels change per environment, and how you manage those differences is the core of app "delivery." Helm solves the same problem with templates into which values are inserted, and Kustomize solves it by layering overlays on a base. The two think differently, but the output is the same: a manifest that goes to the API server.
If you get your hands on the fact that helm install and helm upgrade leave a change history in the unit called a release, and that Kustomize expresses differences only through overlays without touching the original, you develop a feel for tracing "what is applied right now" in a deployment pipeline by the release revision and the assembly result.
Steps
- Create the namespace
kcna-pkg. - With
helm create, stamp out the skeleton of awebappchart. - Change
replicaCountto 3 and save thehelm templateresult to a file. - Install the chart as the release
web. - Upgrade with
--set replicaCount=5to raise the revision and the replicas. - Build the Kustomize base (the
storeDeployment) by hand and check the assembly withkubectl kustomize. - Layer replicas 4 and the
env=prodlabel over it with the prod overlay and apply it. - Record the Helm and Kustomize results in
/root/kcna-pkg/report.txtas a ledger.
Notes
- See the release status and revisions with
helm list -n kcna-pkg -o jsonandhelm history web -n kcna-pkg. kubectl kustomize <디렉터리>shows only the assembly result without touching the cluster, so it is good for checking before you apply.- Official docs: Helm Charts · Kustomize reference.
Open the packaging workshop namespace
Create the namespace kcna-pkg. From here on, both the Helm release and the Kustomize output are deployed to this namespace.
You can create a namespace with kubectl create namespace. To make it safe to run several times, use the --dry-run=client -o yaml | kubectl apply -f - pattern.
Helm stamps out a chart skeleton
Create a new default Helm chart at /root/kcna-pkg/webapp (chart name webapp). Chart.yaml and templates/deployment.yaml must be generated.
helm create <경로> makes a standard chart skeleton with values.yaml, Chart.yaml, and templates/. The last name in the path becomes the chart name.
Change the values and template it to 3
In /root/kcna-pkg/webapp/values.yaml, change replicaCount to 3, then save the result of helm template web /root/kcna-pkg/webapp to /root/kcna-pkg/rendered.yaml. replicas: 3 must appear in the rendered Deployment.
helm template inserts the values without touching the cluster and prints the final manifest as a string. The default chart passes the replicaCount value through to the Deployment's replicas. You can edit the value with sed or yq.
Install the chart into the cluster
Install the chart with the release name web into the namespace kcna-pkg (helm install web /root/kcna-pkg/webapp -n kcna-pkg). web must appear in the Helm release list in the deployed state, and the Deployment that release creates must actually exist.
helm install <릴리스> <차트> -n <네임스페이스> applies the rendered manifest to the cluster and records the release. You can check the status with helm list -n <ns> -o json. Objects Helm creates carry the meta.helm.sh/release-name annotation.
Grow it to 5 with an upgrade
Upgrade the release web with --set replicaCount=5 (helm upgrade web /root/kcna-pkg/webapp -n kcna-pkg --set replicaCount=5). After the upgrade, the release revision must be 2 or higher, and the spec.replicas of the corresponding Deployment must be 5.
helm upgrade creates a new revision of the same release. --set overrides only a specific value without editing the values file. You can check whether the revision went up with helm history <릴리스> -n <ns>.
Build a Kustomize base by hand
In /root/kcna-pkg/kustomize/base, create kustomization.yaml and deployment.yaml. The Deployment name is store, the image is nginx:1.27-alpine, replicas is 1, and the selector and labels are set to app: store. The kustomization's resources is [deployment.yaml]. kubectl kustomize /root/kcna-pkg/kustomize/base must succeed and the result must show the Deployment store.
A Kustomize base consists of the original manifest and a kustomization.yaml that points to it. List the file names under resources:. You can preview the assembly result with kubectl kustomize <디렉터리>. The Deployment's selector.matchLabels and the template labels must match each other.
Layer 4 replicas and env=prod with the prod overlay
In /root/kcna-pkg/kustomize/overlays/prod, create an overlay. Reference ../../base as resources, and add a patch that raises replicas to 4 and the common label env=prod. Then apply it with kubectl apply -k /root/kcna-pkg/kustomize/overlays/prod -n kcna-pkg. As a result, in the namespace kcna-pkg, the Deployment store must have spec.replicas 4 and the label env=prod.
An overlay pulls in the base with resources: [../../base] and layers changes over it. Change replicas with a patch containing a Deployment of the same name (patches:), and attach the common label all at once with commonLabels:. kubectl apply -k assembles the overlay and applies it right away.
Leave a ledger of what was packaged and how
In /root/kcna-pkg/report.txt, write exactly four lines: helm-release=web, helm-replicas=5, kustomize-replicas=4, and kustomize-label=env=prod. The values must match the actual cluster state.
The grader checks these four lines against the actual state. Confirm the current replicas of the Deployment the Helm release created, and the replicas and env label of the store deployed with Kustomize, and copy them over. Do not guess; write the values you read with kubectl get deploy -n kcna-pkg.