TT Lab
Get started
Learn Learning paths Courses

KCNA — Kubernetes and Cloud Native Associate

Packaging the Same App Twice, with Helm and Kustomize

Continue in TT Lab

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

  1. Create the namespace kcna-pkg.
  2. With helm create, stamp out the skeleton of a webapp chart.
  3. Change replicaCount to 3 and save the helm template result to a file.
  4. Install the chart as the release web.
  5. Upgrade with --set replicaCount=5 to raise the revision and the replicas.
  6. Build the Kustomize base (the store Deployment) by hand and check the assembly with kubectl kustomize.
  7. Layer replicas 4 and the env=prod label over it with the prod overlay and apply it.
  8. Record the Helm and Kustomize results in /root/kcna-pkg/report.txt as a ledger.

Notes

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.