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, a cloud provider registry, or a self-hosted registry, under a reference like registry.example.com/shop/web:1.4.2. Third, deploy: Kubernetes manifests that reference that image are applied to the cluster, and controllers reconcile the running state to match them.

Who touches the image matters. The API server never downloads images - it only stores the Pod spec that names one. Once the scheduler places a Pod on a node, that node's kubelet asks the container runtime (containerd or CRI-O) to pull the image from the registry and start the containers. That is why a registry outage or a missing pull secret shows up as an image-pull error on the Pod, not as a rejected manifest.

Why image references must be immutable

A tag is a movable pointer, not a fixed build. If a Deployment uses shop/web:latest and someone pushes a new build under latest, any Pod that is rescheduled or scaled out later pulls whatever latest points to then - so two Pods of the same Deployment can silently run different code, and "roll back" has nothing distinct to roll back to. A per-environment tag such as prod or stable has exactly the same problem: it is as mutable as latest. The fix is to reference a unique, never-reused version tag (for example 1.4.2 or a Git commit SHA) or, strongest of all, an image digest (shop/web@sha256:…), which identifies one exact image content. Changing imagePullPolicy does not fix a moving tag - it only changes when the kubelet pulls (the default is Always for :latest or an untagged image and IfNotPresent otherwise), not which build the tag resolves to.

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 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. 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 (the default) and Recreate. When you change the Pod template (most often the image), a RollingUpdate creates a new ReplicaSet and shifts replicas over gradually, keeping the application available throughout. New Pods must pass their readiness probes before they count as available, so the old ReplicaSet only shrinks as replacements actually become ready.

maxSurge and maxUnavailable, worked through

Two settings bound the pace of a rolling update, each an absolute number or a percentage of the desired replicas (both default to 25%):

• maxSurge sets the ceiling: total Pods may reach replicas + maxSurge. A percentage rounds up to a whole Pod.
• maxUnavailable sets the floor: available Pods may not drop below replicas - maxUnavailable. A percentage rounds down.

With 10 replicas and the defaults, 25% gives a surge of 3 (2.5 rounded up) and an unavailability of 2 (2.5 rounded down), so the rollout runs with at most 13 Pods and at least 8 available. With 4 replicas, maxSurge: 1 and maxUnavailable: 0, the Deployment adds one new Pod, waits for it to be ready, removes one old Pod, and repeats - never fewer than 4 serving, never more than 5 in total.

A surge Pod is a real Pod: it needs a node with free CPU and memory for its requests. On a cluster with no headroom, surge Pods stay Pending and the rollout stalls, so maxSurge: 0 with a non-zero maxUnavailable is the way to update in place.

Recreate: the only no-overlap option

Recreate terminates every old Pod first, then starts the new ones. No RollingUpdate setting - not even maxSurge: 0 or maxUnavailable: 0 - guarantees that old and new Pods never overlap: one ReplicaSet scales down while the other scales up, and RollingUpdate does not wait for old Pods to finish terminating before starting new ones. So when two versions must never run at the same time (an incompatible schema migration, a single-writer lock, a licence limited to one instance), Recreate is the only built-in strategy that guarantees it. The price is downtime for the whole gap between the last old Pod stopping and the first new Pod becoming ready.

Observing and controlling a rollout

kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web
kubectl rollout undo deployment/web --to-revision=3
kubectl rollout pause deployment/web
kubectl rollout resume deployment/web

status blocks until the rollout finishes and exits zero; if the Deployment makes no progress within progressDeadlineSeconds (default 600), it reports the failure and exits non-zero. That makes it the natural gate in a pipeline step - unlike kubectl get deployments, which prints a one-off snapshot and succeeds whatever state it shows. history lists past revisions; undo re-instates the previous (or a named) Pod template, and is fast because the old ReplicaSet still exists, scaled to zero. pause lets you batch several template edits into a single rollout, and resume starts it.

Blue-green and canary are release 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 (live) and green (the new version). Green is deployed alongside blue, tested in place, and then traffic is switched all at once - in plain Kubernetes, typically two Deployments whose Pods carry version: blue or version: green, and a Service whose selector you change from one value to the other. Rollback is the same switch in reverse, which is why it is near-instant. The cost is capacity: you briefly run two full copies of the application.

One detail trips people up: a Service selector is a set of labels that a Pod must match all of (they are ANDed). A selector of app: web, version: green picks only green Pods. Adding a second version value is not possible - a map key appears once - and adding another label that no Pod carries simply matches nothing, leaving the Service with no endpoints. To switch, you replace the version value, not add to it.

A canary release sends a small slice of real traffic 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. In plain Kubernetes the only lever is Pod count: if one Service selects both the stable and canary Pods, kube-proxy spreads connections roughly evenly across ready endpoints, so the traffic share follows the Pod ratio - 1 canary Pod beside 4 stable Pods receives about 20%, and 1% would need 99 stable Pods. Precise percentage splits independent of replica counts need a service mesh such as Istio or Linkerd (or Gateway API weighted routes), and Argo Rollouts automates the whole progression, with analysis steps that can abort a bad release.

Match the description to the name: two environments and an instant switch is blue-green; a small share of users on the new version, grown gradually, 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) keeps every change in a deployable state and automates the release up to production, where a human approval usually gates the last step. Continuous deployment removes that gate: every change that passes the pipeline goes to production automatically.

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, often followed by kubectl rollout status so the job fails if the rollout does not complete. 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 CI/CD framework whose pipeline steps run as Pods. Tekton builds and runs pipelines; it is not a GitOps reconciler.

The push model is simple and universal, but it has structural weaknesses. 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 digging through pipeline logs rather than reading a single declarative source.

Those weaknesses are what the GitOps pull model, covered next, removes. The distinguishing feature of push is a pipeline outside the cluster that holds credentials and applies changes; the distinguishing feature of 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. The OpenGitOps project, started by the CNCF GitOps Working Group, defines four principles. Each one is easiest to remember by what breaks it:

How CI and GitOps fit together

GitOps does not replace CI - it replaces the deploy step at the end of it. CI still tests, builds and pushes the image; instead of applying it to the cluster, CI (or a person, or an image-automation controller) opens a pull request that bumps the image tag in the configuration repository. Review and merge of that pull request is the approval, and the Git history is the audit record of who changed what and when. A controller running inside the cluster notices the new commit and applies it. Deploying is a merge; rolling back is git revert followed by the same reconciliation. Cluster credentials never leave the cluster.

Drift: what gets reverted, and when

Drift is any difference between the live cluster and Git - typically a hand edit with kubectl edit or kubectl scale. Whether drift is corrected automatically depends on how the controller is configured:

• Argo CD always detects drift and marks the application OutOfSync. It only reverts live edits on its own when the application uses automated sync with selfHeal enabled; otherwise someone must trigger a sync.
• Flux: the kustomize-controller re-applies the desired state from Git on every reconciliation interval, so manual changes to the objects a Kustomization manages are overwritten at the next run. For objects rendered by a HelmRelease, in-cluster drift correction is opt-in: the helm-controller only detects or reverts manual edits when the release's driftDetection mode is enabled.

A consequence that surprises people: an imperative rollback on a GitOps-managed object - kubectl rollout undo, or helm rollback on a release the controller owns - is itself drift. Git still declares the new version, so a self-healing controller puts it straight back. The durable rollback is to revert the commit in Git.

Argo CD and Flux

Both are graduated CNCF projects and both pull from Git and reconcile, rendering plain YAML, Kustomize or Helm. They differ in shape:

Helm, a graduated CNCF project, is the package manager for Kubernetes. 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 vocabulary maps onto that problem, and each noun is a different thing:

Templates use Go templating: placeholders such as {{ .Values.replicaCount }} or {{ .Release.Name }} are filled in when the chart is rendered, so one chart serves dev, staging and production with different values files. Because of those placeholders, a template file is not valid Kubernetes YAML until Helm renders it - helm template renders the manifests locally without installing anything, which is how you inspect or lint the real output.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack -f prod-values.yaml
helm list
helm upgrade monitoring prometheus-community/kube-prometheus-stack -f prod-values.yaml --set grafana.enabled=false
helm history monitoring
helm rollback monitoring 2
helm uninstall monitoring

install creates a release (revision 1); upgrade moves it to a new chart version or new values (revision 2, 3, …). helm history lists each revision with its status and chart version, which is how you find the last good one. helm rollback NAME REVISION re-deploys that revision's configuration - and records the rollback as a new revision rather than deleting later ones, so the history stays complete (rolling back to revision 2 from revision 4 produces revision 5). helm uninstall removes every resource the release owns. Public charts are shared through chart repositories and OCI registries and discovered on 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. 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 plain YAML: a kustomization.yaml file that references the base and declares the differences.

Your team runs the same web app in staging and production. The base holds the Deployment and Service; the production overlay raises replicas and pins an image version:

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

Three kubectl commands work with that directory:

• kubectl kustomize overlays/production renders base plus patches and prints the result - nothing is sent to the cluster.
• kubectl diff -k overlays/production previews what applying would change in the live cluster.
• kubectl apply -k overlays/production renders and applies.

Because no file ever contains a placeholder, every layer of a Kustomize setup is valid YAML that standard YAML linters and policy tools can check as it sits in the repository. Helm templates cannot be checked that way until they are rendered. That trade - less templating power, but always-valid YAML - is the core of the choice:

• 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, or when policy requires every committed file to be plain YAML.
• They also combine: Argo CD and Flux can render either, and Kustomize can post-process Helm output.

The image and registry landscape

Delivery tooling also covers how images are built and stored, and these projects do different jobs:

Recognition is the goal here: know what each tool is for and which stage of build, store, define, deliver it belongs to.