Kubernetes and Cloud Native Associate (KCNA) #7: Cloud Native Application Delivery (8%) — GitOps, CI/CD
#6 Cloud Native Observability covered how you look inside a running system. Now we shift our gaze one step earlier. The subject of this post is the path an application written by a developer travels to reach the cluster — and how it gets there safely.
Domain 5 Cloud Native Application Delivery is a small domain at 8%, but it gathers the core vocabulary of modern cloud native operations: CI/CD and GitOps. This post covers the flow from the moment code is committed to the moment it actually runs in the cluster, along with the principles that automate that flow and make it trustworthy.
The delivery problem #
There’s a long distance between a developer writing code and that code being served to users from the cluster. Every step that fills that gap — build, test, image creation, deployment, verification — is bundled together as Application Delivery. In the cloud native world, the unit of this delivery is always a container image.
The key point is that the delivery unit is the image, not the source code. Once built, an image is immutable, and the same image flows through development, staging, and production environments. This immutable image is the starting point that structurally eliminates the “it worked on my machine” problem.
CI/CD basics #
CI/CD is an expression that names two separate concepts as a single bundle. The exam frequently has questions that draw the line precisely between the two, so memorize them separately.
CI (Continuous Integration) #
CI is the stage that merges and verifies code. When a developer pushes a commit, the following work runs automatically.
- Build the source code
- Run unit tests and integration tests
- Static analysis and linting
- Build the container image and push it to a registry
The output of CI is a container image that has passed its tests. At this point, nothing has been deployed to the cluster yet.
CD (Continuous Delivery / Deployment) #
CD is the stage that deploys the image CI produced to a real environment. CD splits further into two.
- Continuous Delivery. Everything up to the production deployment is automated, but the production rollout is triggered by a human pressing an approval button.
- Continuous Deployment. The production rollout proceeds fully automatically with no human intervention.
The line between CI and CD is clear. Everything up to making the image is CI, and everything from running that image on the cluster is CD.
Pipeline #
The automated flow that stitches CI and CD together is the pipeline. A single commit chains automatically into build, test, image push, deployment, and verification. Tools like Jenkins, GitLab CI, GitHub Actions, and Tekton make up this pipeline. Among them, Tekton is a Kubernetes-native CI/CD framework and a CNCF project.
GitOps #
GitOps is an operating paradigm that implements CD. It’s the most frequently tested concept in cloud native delivery, so pin down its definition and principles precisely.
Definition #
GitOps is an approach that treats Git as the single source of truth, managing the system’s desired state as declarative manifests and automatically reconciling that state onto the cluster. In one sentence: “write the desired state into Git, and bring the cluster into line with that state.”
The four principles #
The four principles of GitOps laid out by the OpenGitOps project are an exam staple.
| Principle | Meaning |
|---|---|
| Declarative | The system’s desired state is described declaratively |
| Versioned and Immutable | The desired state is stored in Git for version control, with change history preserved immutably |
| Pulled Automatically | A software agent automatically pulls and applies the approved desired state |
| Continuously Reconciled | The agent continuously compares the actual state against the desired state and brings them into agreement |
Push-based and pull-based #
The key differentiator of GitOps is pull-based delivery. Questions that distinguish the two precisely come up often.
- Push-based. The CI pipeline pushes changes into the cluster from outside it, with commands like
kubectl apply. The external pipeline has to hold the cluster credentials. - Pull-based (GitOps). An agent residing inside the cluster periodically watches the Git repository, and when it detects a change, it pulls and applies it on its own. Credentials never leave the cluster.
GitOps fundamentally favors a pull-based approach, and this is what gives it its security and consistency advantages.
The advantages of GitOps #
| Advantage | Description |
|---|---|
| Auditability | Every change remains as a Git commit, so you can trace who changed what and when |
| Easy rollback | Reverting to a previous commit restores the cluster state to that point in time |
| Reproducibility | The same manifests can reconstruct an identical cluster at any time |
| Automatic drift correction | Even if someone touches the cluster directly, it’s reverted to the Git state |
GitOps tools #
KCNA asks you to recognize the role and position of two tools.
- ArgoCD. The most widely used GitOps tool. Its powerful web UI visually shows an application’s sync state and resource tree. It’s a CNCF Graduated project.
- Flux. A GitOps tool that works as a bundle of controllers. Designed to be Kubernetes-native, it composes well with other tools. It’s also a CNCF Graduated project.
Both tools work on the same principle. They continuously compare (diff) the desired state defined in Git against the cluster’s actual state, and when the two diverge, they detect it as drift and sync to match the desired state. This process of comparing and aligning the desired state with the cluster state is the essence of reconciliation.
The practical workflow is covered hands-on with ArgoCD and Flux in Practice track Advanced #6 GitOps.
Deployment strategies #
How you replace an existing version with a new one is the deployment strategy. KCNA asks about the concept and tradeoffs of each strategy.
| Strategy | Method | Tradeoff |
|---|---|---|
| Recreate | Tear down all existing Pods and bring up the new version | Simplest, but causes downtime during the swap |
| Rolling update | Gradually replace existing Pods with the new version a few at a time (Kubernetes default) | Gradual replacement with no downtime. Two versions briefly coexist |
| Blue-green | Stand up a new environment (green) identical to production (blue) and switch traffic all at once | Instant rollback possible. Requires double the resources |
| Canary | Send only a portion of traffic to the new version first to verify it, then gradually expand | Exposes risk in small doses. Requires traffic-split control |
The point that the default strategy of a Kubernetes Deployment is rolling update shows up often on the exam. Blue-green and canary hit limits with a Deployment alone, so they often rely on tools like a Service Mesh or Argo Rollouts.
Manifest management #
Here are two representative tools for managing manifests efficiently, without rewriting the per-environment settings over and over.
Helm #
Helm is the package manager for Kubernetes. Its core vocabulary is as follows.
- Chart. A package that bundles Kubernetes manifests
- Template. A manifest skeleton into which variables can be inserted
- values. The per-environment settings injected into a template
- Release. One instance of a chart installed on the cluster
Helm injects values into templates to stamp out per-environment manifests, and manages install, upgrade, and rollback at the release level. It’s a CNCF Graduated project.
Kustomize #
Kustomize is a tool that customizes manifests without templates. Its core vocabulary is base and overlay.
- base. The baseline of the common manifests
- overlay. A patch that layers only the per-environment differences (image tags, replica counts, and so on) on top of the base
Kustomize works by pure YAML merging rather than variable substitution, and it’s built into kubectl, so you can use it with kubectl apply -k without a separate install.
Helm vs Kustomize #
In one line: Helm is a package manager that packages with templates and values, while Kustomize is a YAML-merging tool that layers overlays onto a base without templates.
Supply chain security basics #
The more the delivery flow is automated, the more “which images can be trusted” matters. KCNA covers supply chain security only at the recognition level.
- Image provenance trust. Verifying that an image came from a trusted registry and that the build process wasn’t tampered with.
- Image signing (cosign). Signing images with cosign, from the Sigstore project, to guarantee provenance and integrity.
- SBOM (Software Bill of Materials). A specification that itemizes which components and dependencies an image was built from. It serves as the basis for vulnerability tracking.
For the KCNA level, just knowing that these three terms are bundled under the “supply chain security” vocabulary is enough.
Exam points #
- CI vs CD. Everything up to making the image is CI; everything from running that image on the cluster is CD. Continuous Delivery requires approval for the production rollout, and Continuous Deployment is fully automatic
- The four GitOps principles. Declarative, versioned and immutable, pulled automatically, continuously reconciled
- Pull-based. In GitOps an agent inside the cluster pulls from Git and applies. Credentials never leave the cluster
- Drift and reconciliation. Compare the desired state against the cluster state and revert on divergence
- Deployment strategies. The Deployment default is rolling update. Distinguish recreate (downtime), blue-green (instant switch, double resources), and canary (a portion of traffic first)
- Helm vs Kustomize. Helm is a template- and values-based package manager; Kustomize is a templateless base/overlay merge
- ArgoCD and Flux. Both are GitOps tools and CNCF Graduated projects
Building a practical pipeline is covered hands-on in Practice Track #4 CI/CD.
Wrap-up #
What this post locked in:
- The delivery unit is the container image. A single immutable image, built once, flows identically through every environment
- CI is build, test, and image creation; CD is deployment. Continuous Delivery is approval-triggered, Continuous Deployment is fully automatic
- GitOps is a pull-based CD paradigm that treats Git as the single source of truth. The four principles (declarative, versioned, pulled automatically, continuously reconciled) and drift correction
- The GitOps tools are ArgoCD and Flux. They compare the desired state against the cluster state and sync
- Deployment strategies. The tradeoffs of rolling update (default), recreate, blue-green, and canary
- Manifest management. Helm (package manager) and Kustomize (YAML merge)
- Supply chain security. Image provenance trust, cosign signing, SBOM (at the recognition level)
Next: Exam tips #
We’ve now gone a full lap through all five domains. Now comes the stage of turning that into points on exam day.
#8 Exam Tips and Commonly Missed Patterns covers the concept pairs that are easy to confuse domain by domain, the knack for reading multiple-choice questions, time allocation, and the multiple-response traps — the practical strategies for clearing the passing line.