Implementing GitOps Deployment for a Kubernetes CronJob with Argo CD
Goal
Understand the complete path from merging code to automatically deploying a new CronJob image, while keeping Git as the deployment source of truth.
Interactive dashboard
Use the hosted study dashboard to tick tasks directly in the browser and keep progress without editing these Markdown files.
Intended structure
app/ # Small program executed by the CronJob
Dockerfile # Container image definition
deploy/base/ # Base Kubernetes CronJob manifest
deploy/overlays/local/ # Local Kustomize image configuration
argocd/ # Argo CD Application manifest
.github/workflows/ # Image build and Git tag-update workflow
docs/ # Study plan and project documentationPhase 1 — Build the scheduled application
- Create a small application that prints its execution time and Git commit version.
- Containerize it and run the image manually.
- Verify its output before introducing Kubernetes.
Milestone: The container runs locally and prints the expected version.
Phase 2 — Run it as a Kubernetes CronJob
- Create a local Kind cluster.
- Write a
batch/v1CronJob manifest that initially runs every two minutes. - Learn
schedule,concurrencyPolicy, job history, retry behavior, andsuspend. - Trigger a manual Job from the CronJob and inspect its logs.
Milestone: Kubernetes creates Jobs on schedule and the logs are understandable.
Phase 3 — Deploy through Argo CD
- Install Argo CD in the local cluster.
- Create a Kustomize base and local overlay.
- Create an Argo CD
Applicationthat watchesdeploy/overlays/localonmain. - Enable automatic sync, pruning, self-healing, and namespace creation.
- Change the CronJob schedule in Git and observe Argo CD synchronize it.
Milestone: A Git commit changes the cluster without deploying through kubectl or CI.
Phase 4 — Build an image after every merge
- Add a GitHub Actions workflow triggered by application changes merged into
main. - Test and build the container.
- Tag it as
sha-<full-commit-sha>and push it to GHCR. - Use immutable tags instead of
latest.
Milestone: Every application merge produces a traceable GHCR image.
Phase 5 — Update the desired image tag in Git
- Let CI update only the Kustomize
newTagvalue after publishing the image. - Commit and push that configuration change back to this repository.
- Restrict workflow paths so the automated configuration commit does not start another image build.
- Let Argo CD discover and deploy the new desired state.
Milestone: CI hands deployment responsibility to Git, and Argo CD performs the deployment.
Phase 6 — Verify the complete GitOps loop
For one merged pull request, verify:
- GitHub Actions succeeds.
- GHCR contains the merge commit's image tag.
- Kustomize contains that exact tag.
- Argo CD reports the application as synced.
- The next scheduled Job prints the new version.
Phase 7 — Practice failures and rollback
- Diagnose an invalid image tag and
ImagePullBackOff. - Diagnose an application that exits unsuccessfully.
- Test
concurrencyPolicy: Forbidwith a long-running Job. - Test Argo CD self-healing after a manual cluster change.
- Revert an image-tag commit and verify that the following Job uses the previous image.
Milestone: Failures are diagnosed from evidence, and rollback is performed through Git.
Optional Phase 8 — Compare Argo CD Image Updater
- Replace the CI tag-edit step with the CRD-based Argo CD Image Updater.
- Track SHA tags with the
newest-buildstrategy and Git write-back. - Compare asynchronous registry reconciliation with the deterministic CI-driven update used above.
Definition of done
- A merge builds one immutable image tied to its commit SHA.
- Git records the exact image selected for deployment.
- Argo CD automatically synchronizes the cluster from Git.
- The next CronJob execution uses the selected image.
- A Git revert performs a successful rollback.