标签：#argocd

This project started with a simple goal: run Kubernetes without keeping an EKS cluster online every day. In I Wanted Kubernetes Without an Always-On EKS Bill , I built an always-on k3s lab on my home server and proved that I could deploy, update, and roll back an application. The rollback worked, but it exposed the next problem. Kubernetes restored Version 2 while the saved YAML still declared Version 3. I corrected the file manually, but the recovery depended on repairing the running cluster and its saved instructions separately. In The Rollback Worked. My Next Deploy Could Break It Again , I designed a safer path. The automated build process would test and publish an exact image, then stop at a Git pull request. Git would record the reviewed version. Argo CD, running inside Kubernetes, would make the cluster follow that record. Now I needed to prove that the design worked outside a diagram. I followed one release from source code to running Pods. Then I tested two opposite failures: The cluster was wrong while Git was correct. Git contained a bad setting while the cluster followed it correctly. Those experiments showed both the value and the limit of GitOps. Automation can make the cluster match Git, but it cannot decide whether the human-approved version in Git is a good one. CI Built the Release but Did Not Deploy It The GitHub Actions workflow—my continuous integration, or CI, worker—ran the application tests and checked the Kubernetes package before building anything. Its job was to prove and publish a release, not to change the cluster. After validation, Buildx created a Linux AMD64 image with the full source commit baked into /version : docker buildx build \ --platform linux/amd64 \ --build-arg "APP_VERSION= $GITHUB_SHA " \ --tag " $image_name : $GITHUB_SHA " \ --provenance = mode = max \ --sbom = true \ --push \ application After publishing the image, CI read its registry digest. A digest is the image's content fingerprint: if the image changes, the digest