Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies

Every cloud native delivery workflow, whatever tools implement it, follows the same three-step shape. First, build: source code plus a Dockerfile (or a buildpack) produces a container image that conforms to the OCI image standard. Second, push: the image is uploaded to a container registry such as Docker Hub, or a private registry, under an immutable reference like registry.example.com/shop/web:1.4.2. Third, deploy: Kubernetes manifests that reference the new image tag are applied to the cluster, and controllers reconcile the running state to match them.

The deploy step is where Kubernetes differs from older platforms. You do not script a sequence of imperative server commands; you declare the desired state in YAML and hand it to the API server. The Deployment controller then works out the safe order of operations - creating a new ReplicaSet, scaling Pods up and down - on your behalf. Delivery tooling in the cloud native world is therefore mostly about two questions: who applies the manifests (a pipeline pushing, or a controller pulling) and how the manifests are produced (written by hand, templated by Helm, or patched by Kustomize).

Keep the vocabulary straight, because KCNA questions lean on it. The image lives in a registry. The manifest describes desired state. The cluster holds actual state. Delivery is the discipline of moving changes through those three layers repeatably, and everything else in this lesson - strategies, GitOps, Helm - is a refinement of that flow.

A Deployment has a strategy field with exactly two built-in options. RollingUpdate is the default: when you change the Pod template (most often the image tag), the Deployment creates a new ReplicaSet and shifts replicas over gradually, keeping the application available throughout. Two knobs bound the pace: maxSurge (how many extra Pods may exist above the desired count, default 25%) and maxUnavailable (how many Pods may be missing below it, default 25%). New Pods must pass their readiness probes before they count, so traffic only shifts to replicas that are actually ready.

Recreate is the blunt alternative: terminate every old Pod first, then start the new ones. That guarantees old and new versions never run at the same time - useful when two versions would corrupt shared state or fight over a lock - but it causes downtime for the whole gap. If a question mentions a brief outage during every deploy, Recreate is the strategy being described.

You observe and control a rollout with the kubectl rollout family:

kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web
kubectl rollout pause deployment/web
kubectl rollout resume deployment/web

status watches the rollout until it completes or stalls, history lists past revisions, and undo rolls back to the previous revision by re-instating the old Pod template. Rollback is fast because the old ReplicaSet still exists, scaled to zero, waiting to be scaled back up. Remember the pairing: rolling update is the default and preserves availability; recreate is opt-in and accepts downtime for simplicity.

Blue-green and canary are patterns, not values of the Deployment strategy field. You assemble them from Kubernetes primitives or use tooling that automates them.

In a blue-green deployment you run two complete environments: blue (the live version) and green (the new one). Green is deployed alongside blue, tested in place, and then traffic is switched all at once - in plain Kubernetes, typically by repointing a Service label selector from the blue Pods to the green Pods. Rollback is the same switch in reverse. The cost is capacity: you briefly run two full copies of the application.

A canary release sends a small slice of real traffic - say 5% - to the new version while the rest stays on the stable one. If error rates and latency stay healthy, the slice grows until the canary takes all traffic. Fine-grained percentage splits are beyond what a plain Service offers, so canaries usually rely on a service mesh such as Istio or Linkerd to shift traffic by weight, or on Argo Rollouts, a controller that automates progressive delivery with analysis steps that can abort a bad release automatically.

For the exam, match the description to the name: two environments and an instant switch is blue-green; a small percentage of users on the new version is a canary.

Continuous integration (CI) is the automated path from a code change to a tested artifact: every push to the repository triggers a pipeline that runs tests, builds the container image, scans it, and pushes it to the registry. Continuous delivery (CD) extends the pipeline to deploying that artifact - into a staging cluster automatically, and into production either automatically (continuous deployment) or after a manual approval.

In the classic push model, the pipeline itself performs the deployment: a job at the end of the pipeline holds credentials for the cluster and runs kubectl apply or helm upgrade against it. Familiar CI systems - Jenkins, GitHub Actions, GitLab CI - work this way, and the cloud native ecosystem includes Tekton (a Continuous Delivery Foundation project), a Kubernetes-native framework where pipeline steps themselves run as Pods.

The push model is simple and universal, but it has structural weaknesses worth recognizing. Cluster credentials must live in the CI system, widening the attack surface. The pipeline only knows the cluster state at the moment it pushes; if someone later edits a Deployment by hand with kubectl edit, nothing notices or corrects the drift. And reconstructing what is deployed means archaeology through pipeline logs rather than reading a single declarative source.

Those weaknesses are exactly what the GitOps pull model, covered next, is designed to remove. On the exam, the trigger word for the push model is a pipeline that has cluster credentials and applies changes from outside; the trigger for GitOps is an agent inside the cluster that pulls from Git.

GitOps manages infrastructure and applications by keeping the entire desired state in a Git repository and letting software agents continuously reconcile the live system to match it. Four principles define it: the desired state is declarative; it is versioned and immutable in Git; agents pull it automatically rather than having it pushed in; and agents continuously reconcile, correcting any divergence between the repository and the cluster.

Operationally that means a controller runs inside the cluster, watches a repository of manifests (plain YAML, Helm charts, or Kustomize overlays), and applies whatever changes land there. To ship a new version you do not run kubectl at all - you open a pull request that bumps the image tag, and once it merges, the controller notices and rolls it out. Rollback is git revert. The Git history becomes a complete, reviewable audit log of every change to the environment, and because the agent keeps reconciling, drift - someone hand-editing a live object - is detected and can be automatically reverted to match Git.

The two tools to know are Argo CD and Flux, both graduated CNCF projects. Argo CD adds a web UI that visualizes sync status per application; Flux is a set of controllers configured entirely through Kubernetes custom resources. For KCNA you only need to recognize both as GitOps tools.

Helm, a graduated CNCF project, is the de facto package manager for Kubernetes. It answers a practical problem: a real application is a bundle of many manifests - Deployment, Service, ConfigMap, Ingress - that you want to install, upgrade, and remove as one unit, with environment-specific settings injected. Helm's three core nouns map directly to that problem. A chart is the package: a directory containing Chart.yaml (name and version metadata), values.yaml (default configuration), and a templates/ directory of manifest templates. Values are the user-supplied configuration that fills in those templates. A release is one installed instance of a chart in a cluster - the same chart can be installed many times as separate releases under different names.

Templates use Go templating: placeholders such as {{ .Values.replicaCount }} or {{ .Release.Name }} are substituted at install time, so one chart serves dev, staging, and production with different values files. The everyday workflow:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-db bitnami/postgresql --values prod-values.yaml
helm list
helm upgrade my-db bitnami/postgresql --set auth.database=orders
helm rollback my-db 1
helm uninstall my-db

install creates a release, upgrade moves it to a new chart version or new values, and each of those actions records a numbered revision, which is what helm rollback returns to. Because Helm tracks every resource a release owns, helm uninstall removes the whole application cleanly. Public charts are shared through chart repositories and hubs such as Artifact Hub, which is how you install third-party software - databases, ingress controllers, monitoring stacks - without writing their manifests yourself.

Kustomize is the template-free alternative for customizing manifests, and it is built into kubectl - kubectl apply -k processes a Kustomize directory directly. Instead of templates with placeholders, you keep a base of complete, valid YAML manifests and write overlays that patch the base for each environment. An overlay is itself just YAML: a kustomization.yaml file that references the base and declares the differences.

A concrete scenario shows the shape. Your team runs the same web app in staging and production. The base holds the Deployment and Service. The production overlay bumps replicas and pins a new image:

resources:
- ../../base
replicas:
- name: web
  count: 5
images:
- name: shop/web
  newTag: 1.4.2

Running kubectl apply -k overlays/production renders base plus patches and applies the result. Nothing in the base ever contains a placeholder, so every layer remains readable, valid YAML - the property Kustomize trades templating power for.

Choosing between the two is a standard exam contrast:

• Choose Helm when you need packaging and distribution: versioned charts, install and rollback of releases, shipping software to other teams, or consuming third-party charts.
• Choose Kustomize when you own plain manifests and only need per-environment variation without a templating language.
• They also combine: GitOps controllers such as Argo CD and Flux can render either, and Kustomize can post-process Helm output.

Rounding out the landscape, the delivery ecosystem also standardizes image building itself: Cloud Native Buildpacks, a CNCF project, turns source code into OCI images without a Dockerfile. For KCNA, recognition is enough - know what each tool is for, not how to operate it.