CI/CD for Kubernetes
Getting code into a cluster is a pipeline: build and test the image, push it, update the manifests, and roll it out across environments. CI handles build-and-test; CD handles delivery — and where CD ends and GitOps begins is the design decision that defines the whole flow.
Kubernetes does not prescribe a CI/CD tool; it provides the API the pipeline targets. The patterns that matter are about safety: immutable images, the right deploy model, and progressive rollout.
CI: Build, Test, Scan, Push
Continuous integration produces a trustworthy image. A typical pipeline builds the container image, runs unit and integration tests, scans the image for vulnerabilities (Topic 37), and pushes it to a registry. The output of CI is an immutable, scanned, tagged-and-digested image — the artifact that delivery then deploys. Everything after this point references that exact image, not source code.
Tagging and Immutability
How you tag the image shapes how safe delivery is. Mutable tags like :latest or a reused branch tag mean the same reference can point at different bytes over time — fatal for rollback and reproducibility. The discipline is immutable tags (a build ID or semver) and, ideally, referencing by digest in the manifest so a deploy is pinned to the exact image CI produced and scanned.
Push-Based CD vs Pull-Based GitOps
Delivery comes in two shapes. Push-based CD has the pipeline itself apply manifests to the cluster — simple, but it requires giving CI cluster credentials and it only acts at deploy time. Pull-based GitOps has CI update manifests in Git and an in-cluster controller reconcile (Topic 43) — more secure and self-healing. A common, clean split is: CI builds and tests the image and opens a commit/PR updating the image tag in the Git repo; GitOps takes it from there.
| Stage | Owner | Output |
|---|---|---|
| Build, test, scan, push | CI | Immutable, scanned image |
| Update manifest (image tag) | CI commit/PR | Changed desired state in Git |
| Apply and reconcile | GitOps controller | Cluster matches Git |
Progressive Delivery and Promotion
Beyond a basic rolling update (Topic 06), progressive delivery shifts traffic gradually and watches metrics: canary (a small percentage first, then ramp), blue-green (switch all at once between two versions), with automated rollback if error rates rise. Tools like Argo Rollouts and Flagger add this on top of Kubernetes. Promotion across environments — dev to staging to prod — should be an explicit, auditable step (a Git change), not a manual re-deploy, so every environment's state is traceable to a commit.
Push-based CD — the pipeline applies to the cluster directly. Simple but needs cluster credentials in CI and acts only at deploy time.
Pull-based GitOps — CI updates Git; an in-cluster controller reconciles. More secure and self-healing (Topic 43).
- Deploying mutable tags like
:latest, breaking rollback and reproducibility. - Handing broad cluster credentials to CI for push-based deploys when GitOps would avoid it.
- Coupling build and deploy so tightly that you cannot redeploy a known-good image without rebuilding.
- Skipping image scanning as a gate before deploy.
- Promoting between environments by manual re-deploy instead of an auditable Git change.
- Make CI produce an immutable, scanned image referenced by digest.
- Prefer the split: CI builds and updates the manifest in Git; GitOps deploys.
- Gate the pipeline on tests and vulnerability scans before anything reaches a cluster.
- Use progressive delivery (canary/blue-green) with automated rollback for risky changes.
- Make environment promotion an explicit Git operation so every deploy traces to a commit.
Knowledge Check
What is the output of the CI stage that delivery then deploys?
- An immutable, scanned, tagged-and-digested container image
- A running Pod, already scheduled and started on a node
- A Helm release installed into the target namespace
- The unbuilt set of source files from the repository
What is a clean split between CI and GitOps?
- CI builds, tests, and pushes the image, then commits an image-tag bump to Git for the controller to reconcile
- CI applies the rendered manifests straight to the live cluster while the GitOps controller rebuilds the container image on every push
- GitOps runs the unit and integration test suites while CI is the component that deploys to the cluster
- They must always be implemented by one and the same single tool
What does progressive delivery (canary/blue-green) add over a basic rolling update?
- Gradual traffic shifting with metric-based automated rollback
- Faster image builds through layer caching in the pipeline
- Automatic encryption of all in-cluster deploy traffic
- Elimination of the need to define readiness probes
You got correct