Engineering lab

Kubernetes application delivery with CI/CD and GitOps

A reference architecture for moving a containerised application through review, build, verification, and declarative deployment.

  • Kubernetes
  • Helm
  • Jenkins
  • Git
  • Argo CD
  • Docker
  • Linux

Technical objective

This reference architecture maps a controlled path from source change to a Kubernetes workload. It is an engineering lab, not a client deployment, and is intended to make the boundaries between build, verification, release configuration, and runtime state visible.

Architecture and approach

A change is reviewed in source control, built into an immutable image, checked by the delivery pipeline, and represented in a declarative deployment repository. A GitOps controller reconciles the reviewed desired state with the cluster. Helm values provide a small, explicit configuration surface.

Key implementation decisions

  • Keep application source and environment configuration as separate reviewable concerns.
  • Use immutable image references so the deployed artefact is unambiguous.
  • Prefer declarative reconciliation to ad-hoc cluster changes.
  • Make readiness, resource requests, and rollout behaviour part of the workload definition.

Operational and security considerations

The operating model requires observable rollout state, namespace boundaries, least-privilege automation credentials, and a documented rollback path. Image provenance and vulnerability review are treated as release inputs, not afterthoughts.

Engineering reasoning

The value of a delivery design is not the number of tools involved. It is the ability to understand what changed, why it changed, and how the running state relates to a reviewed decision.