Project challenges / verified progress
Beacon: ship it without fear

The engineering notebook

Let the cluster pull

Why does GitOps keep cluster credentials out of CI?

Loading statusStage 5 of 9

  • Workspace not ready
  • Agent not ready
Focus25:00
A small focus ritual

0 focus sessions completed. Every fourth session offers a longer break. Start each phase when you are ready.

Study time never unlocks verified lesson progress.

Loading...

Loading verified progress...

Loading GitHub account...
Let Git drive the cluster

Step 01 of 06

Learn the concept

Push-based deployment hands CI the keys to the cluster and hopes every workflow author is careful forever. GitOps reverses the direction: the cluster watches Git, compares desired state with live state, and reconciles the difference.

GITOPS CONTROL LOOP01Gitdesired state02Observelive cluster03Comparediff found04Syncapply change05Repeatdrift watched
The loop belongs in the cluster. CI proposes or commits desired state; Argo CD observes the cluster and decides whether reality still matches Git.
Step 01

The ideas this is made of

Pull-based CD removes cluster credentials from CI

In push CD, GitHub Actions needs a kubeconfig or cloud role able to mutate the cluster. In GitOps, CI writes or proposes Git changes. Argo CD, already inside the cluster, pulls approved desired state and applies it.

Reconciliation is the recurring control-loop pattern

Kubernetes controllers compare desired objects with actual objects. Terraform compares configuration with provider state. Argo CD compares Git with the cluster. The pattern is stable: observe, diff, act, repeat.

Drift detection turns manual fixes into visible debt

Someone can still run kubectl edit deployment beacon. Argo CD will notice that live state differs from Git. Depending on policy it can self-heal or report OutOfSync. Either way, the emergency tweak becomes visible.

App and config repositories have different blast radii

The app repository builds Beacon. The config repository says which digest runs in which cluster. Keeping them separate lets many engineers contribute code without gaining direct production deployment rights.

A thermostat with a written setpoint
desired: 21 C in the logbook
observed: 18 C in the room
diff: heat needed
action: turn heater on
repeat: measure again

The thermostat does not need a remote operator holding the heater switch. It reads desired state, observes reality and acts until they match.

Push CD and pull GitOps

QuestionPush from CIPull with GitOps

Who has cluster creds?

CI runner

In-cluster controller

Source of truth

Pipeline run

Git config repo

Drift handling

Often invisible

Reported or self-healed

Audit trail

CI logs

Git commit plus sync history

What these are called on the job

  • Desired state — The resources and versions Git says should exist in the cluster.

  • Drift — A difference between live Kubernetes objects and the Git-declared version.

  • Self-heal — Automatic correction of live drift back to the declared Git state.

  • Sync wave — An Argo CD annotation that orders resources during a sync.