<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1556075798-4825dfaaf498?w=1200">GitOps is no longer a hot take — it’s the default deployment pattern for Kubernetes-native teams in 2026. But “GitOps” has grown to mean different things depending on who you ask. This post cuts through the noise: what GitOps actually delivers, where ArgoCD and Flux each shine, and which newer tools deserve attention.<hr><h2 id="what-gitops-actually-solves">What GitOps Actually Solves</h2>Before comparing tools, it’s worth being precise about the problem. GitOps is an operational pattern with a specific set of guarantees:<ol><li>Desired state in Git — the Git repository is the source of truth for what should be running</li><li>Automated reconciliation — an agent continuously reconciles the cluster state to match Git</li><li>Observable drift — you can see when cluster state diverges from Git state</li><li>Auditable history — every change has a Git commit, author, timestamp, and rollback path</li></ol>What it doesn’t solve: infrastructure provisioning (separate problem), secret management (use Vault/ESO), or multi-tenancy authorization (you still need RBAC).<img src="https://images.unsplash.com/photo-1618401471353-b98afee0b2eb?w=900" alt="Git workflow visualization"> Photo by Praveen Thirumurugan on Unsplash<hr><h2 id="argocd-the-ui-first-gitops-platform">ArgoCD: The UI-First GitOps Platform</h2>ArgoCD has won the enterprise GitOps market through one differentiating factor: its UI is genuinely excellent.<div><pre><code># ArgoCD Application manifest
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: payments-service
 namespace: argocd
spec:
 project: production
 source:
 repoURL: https://github.com/myorg/k8s-manifests
 targetRevision: main
 path: apps/payments/production
 destination:
 server: https://kubernetes.default.svc
 namespace: payments-prod
 syncPolicy:
 automated:
 prune: true # Delete resources removed from Git
 selfHeal: true # Revert manual changes
 allowEmpty: false # Never sync to empty state
 syncOptions:
 - CreateNamespace=true
 - PrunePropagationPolicy=foreground
 retry:
 limit: 3
 backoff:
 duration: 5s
 maxDuration: 3m
 factor: 2
</code></pre></div>ArgoCD’s UI shows you the resource tree, health status, sync status, and diff in one view. For teams where not everyone is comfortable with kubectl, this is a huge operational win. Developers can deploy themselves without learning Kubernetes internals.<h3 id="argocd-applicationsets">ArgoCD ApplicationSets</h3>ApplicationSets are the mechanism for managing applications at scale:<div><pre><code>apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
 name: cluster-addons
 namespace: argocd
spec:
 generators:
 - matrix:
 generators:
 - clusters: {} # Generates one entry per registered cluster
 - list:
 elements:
 - addon: cert-manager
 version: "1.14"
 - addon: external-secrets
 version: "0.9"
 - addon: metrics-server
 version: "0.7"
 template:
 metadata:
 name: '-'
 spec:
 project: cluster-addons
 source:
 repoURL: https://github.com/myorg/cluster-addons
 targetRevision: main
 path: '/'
 destination:
 server: ''
 namespace: ''
</code></pre></div>This generates an Application for every combination of cluster and addon — one ApplicationSet manages dozens of applications across dozens of clusters.<hr><h2 id="flux-the-kubernetes-native-operator-approach">Flux: The Kubernetes-Native Operator Approach</h2>Flux v2 takes a more Kubernetes-native approach: everything is a CRD, reconciled by focused controllers. There’s no central dashboard — Flux is designed to be composed with your existing observability stack.<div><pre><code># Flux GitRepository source
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
 name: k8s-manifests
 namespace: flux-system
spec:
 interval: 1m
 url: https://github.com/myorg/k8s-manifests
 ref:
 branch: main
 secretRef:
 name: github-credentials
---
# Flux Kustomization
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
 name: payments-production
 namespace: flux-system
spec:
 interval: 5m
 path: ./apps/payments/production
 prune: true
 sourceRef:
 kind: GitRepository
 name: k8s-manifests
 healthChecks:
 - apiVersion: apps/v1
 kind: Deployment
 name: payments-api
 namespace: payments-prod
 postBuild:
 substitute:
 cluster_region: ap-northeast-2
</code></pre></div><h3 id="fluxs-image-automation">Flux’s Image Automation</h3>Flux’s image automation controllers are a killer feature for teams that want to automate image tag updates:<div><pre><code># Watch for new image tags and commit them to Git automatically
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata:
 name: payments-api
 namespace: flux-system
spec:
 image: 123456789.dkr.ecr.ap-northeast-2.amazonaws.com/payments-api
 interval: 1m
---
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
 name: payments-api
 namespace: flux-system
spec:
 imageRepositoryRef:
 name: payments-api
 policy:
 semver:
 range: "&gt;=1.0.0-0 &lt;2.0.0" # Only 1.x releases
---
# Automatically commit tag updates to Git
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
 name: flux-system
 namespace: flux-system
spec:
 interval: 5m
 sourceRef:
 kind: GitRepository
 name: k8s-manifests
 git:
 checkout:
 ref:
 branch: main
 commit:
 author:
 email: fluxbot@myorg.com
 name: Flux Image Updater
 messageTemplate: "chore: update "
 push:
 branch: main
</code></pre></div>CI pushes a new image tag → Flux detects it → commits the updated tag to Git → reconciles the cluster. Full GitOps loop without manual YAML edits.<hr><h2 id="crossplane-gitops-for-infrastructure">Crossplane: GitOps for Infrastructure</h2>Crossplane has matured significantly and represents a compelling extension of GitOps principles beyond Kubernetes workloads to cloud infrastructure:<div><pre><code># Provision an RDS instance via GitOps
apiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance
metadata:
 name: payments-db-prod
spec:
 forProvider:
 region: ap-northeast-2
 dbInstanceClass: db.r6g.xlarge
 engine: postgres
 engineVersion: "15"
 multiAZ: true
 storageEncrypted: true
 allocatedStorage: 100
 backupRetentionPeriod: 7
 providerConfigRef:
 name: aws-production
 writeConnectionSecretToRef:
 namespace: payments-prod
 name: payments-db-credentials
</code></pre></div>The mental model: your Git repository contains not just Kubernetes manifests but your entire infrastructure definition. Crossplane reconciles AWS/GCP/Azure resources the same way Kubernetes reconciles pods. Combined with ArgoCD or Flux, you get full GitOps from “create an RDS instance” to “deploy the app that uses it.”<hr><h2 id="choosing-in-2026">Choosing in 2026</h2>Choose ArgoCD if:<ul><li>Your team needs a UI to operate effectively</li><li>You have non-Kubernetes-experts managing deployments</li><li>You want application-centric views across multiple clusters</li><li>You need Progressive Delivery (Argo Rollouts integrates tightly)</li></ul>Choose Flux if:<ul><li>You want GitOps-as-a-library: composable, no opinions</li><li>You need image automation (Flux’s is more mature)</li><li>You’re building a platform where multiple teams manage their own GitOps configs</li><li>You prefer CLI-first + your own Grafana dashboards over a built-in UI</li></ul>Use both: Many large organizations use Flux for cluster configuration and ArgoCD for application deployment. They coexist fine.Add Crossplane if:<ul><li>You want to GitOps your cloud infrastructure alongside your Kubernetes workloads</li><li>You’re building an Internal Developer Platform where devs can self-serve databases, queues, and buckets</li></ul><hr><h2 id="the-platform-engineering-angle">The Platform Engineering Angle</h2>In 2026, GitOps is increasingly just a layer in a larger Platform Engineering stack. Tools like Backstage, Port, and Cortex sit above ArgoCD/Flux and provide the developer-facing abstraction:<ul><li>Developer submits a service request via the portal</li><li>Platform generates the GitOps manifests</li><li>ArgoCD/Flux reconciles the cluster</li><li>Developer never touches a YAML file</li></ul>The GitOps tool becomes an implementation detail. The platform team owns it; application developers interact with it indirectly. This is the trajectory for mature platform engineering organizations.<hr>GitOps is table stakes for production Kubernetes. The interesting design decisions are now about how you structure your GitOps repositories, who gets to commit to them, and what layer of abstraction sits above them for your developers.<hr>References: <a href="https://argo-cd.readthedocs.io/">ArgoCD Documentation</a>, <a href="https://fluxcd.io/docs/">Flux Documentation</a>, <a href="https://docs.crossplane.io/">Crossplane Documentation</a>, <a href="https://github.com/cncf/tag-app-delivery/tree/main/gitops-wg">CNCF GitOps Working Group</a> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

GitOps is no longer a hot take — it’s the default deployment pattern for Kubernetes-native teams in 2026. But “GitOps” has grown to mean different things depending on who you ask. This post cuts through the noise: what GitOps actually delivers, where ArgoCD and Flux each shine, and which newer tools deserve attention.
What GitOps Actually Solves
Before comparing tools, it’s worth being precise about the problem. GitOps is an operational pattern with a specific set of guarantees:
Desired state in Git — the Git repository is the source of truth for what should be running
Automated reconciliation — an agent continuously reconciles the cluster state to match Git
Observable drift — you can see when cluster state diverges from Git state
Auditable history — every change has a Git commit, author, timestamp, and rollback path
What it doesn’t solve: infrastructure provisioning (separate problem), secret management (use Vault/ESO), or multi-tenancy authorization (you still need RBAC).
Photo by Praveen Thirumurugan on Unsplash
ArgoCD: The UI-First GitOps Platform
ArgoCD has won the enterprise GitOps market through one differentiating factor: its UI is genuinely excellent.
# ArgoCD Application manifest
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: payments-service
 namespace: argocd
spec:
 project: production
 source:
 repoURL: https://github.com/myorg/k8s-manifests
 targetRevision: main
 path: apps/payments/production
 destination:
 server: https://kubernetes.default.svc
 namespace: payments-prod
 syncPolicy:
 automated:
 prune: true # Delete resources removed from Git
 selfHeal: true # Revert manual changes
 allowEmpty: false # Never sync to empty state
 syncOptions:
 - CreateNamespace=true
 - PrunePropagationPolicy=foreground
 retry:
 limit: 3
 backoff:
 duration: 5s
 maxDuration: 3m
 factor: 2
ArgoCD’s UI shows you the resource tree, health status, sync status, and diff in one view. For teams where not everyone is comfortable with kubectl, this is a huge operational win. Developers can deploy themselves without learning Kubernetes internals.
ArgoCD ApplicationSets
ApplicationSets are the mechanism for managing applications at scale:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
 name: cluster-addons
 namespace: argocd
spec:
 generators:
 - matrix:
 generators:
 - clusters: {} # Generates one entry per registered cluster
 - list:
 elements:
 - addon: cert-manager
 version: "1.14"
 - addon: external-secrets
 version: "0.9"
 - addon: metrics-server
 version: "0.7"
 template:
 metadata:
 name: '-'
 spec:
 project: cluster-addons
 source:
 repoURL: https://github.com/myorg/cluster-addons
 targetRevision: main
 path: '/'
 destination:
 server: ''
 namespace: ''
This generates an Application for every combination of cluster and addon — one ApplicationSet manages dozens of applications across dozens of clusters.
Flux: The Kubernetes-Native Operator Approach
Flux v2 takes a more Kubernetes-native approach: everything is a CRD, reconciled by focused controllers. There’s no central dashboard — Flux is designed to be composed with your existing observability stack.
# Flux GitRepository source
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
 name: k8s-manifests
 namespace: flux-system
spec:
 interval: 1m
 url: https://github.com/myorg/k8s-manifests
 ref:
 branch: main
 secretRef:
 name: github-credentials
---
# Flux Kustomization
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
 name: payments-production
 namespace: flux-system
spec:
 interval: 5m
 path: ./apps/payments/production
 prune: true
 sourceRef:
 kind: GitRepository
 name: k8s-manifests
 healthChecks:
 - apiVersion: apps/v1
 kind: Deployment
 name: payments-api
 namespace: payments-prod
 postBuild:
 substitute:
 cluster_region: ap-northeast-2
Flux’s Image Automation
Flux’s image automation controllers are a killer feature for teams that want to automate image tag updates:
# Watch for new image tags and commit them to Git automatically
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata:
 name: payments-api
 namespace: flux-system
spec:
 image: 123456789.dkr.ecr.ap-northeast-2.amazonaws.com/payments-api
 interval: 1m
---
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
 name: payments-api
 namespace: flux-system
spec:
 imageRepositoryRef:
 name: payments-api
 policy:
 semver:
 range: ">=1.0.0-0 <2.0.0" # Only 1.x releases
---
# Automatically commit tag updates to Git
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
 name: flux-system
 namespace: flux-system
spec:
 interval: 5m
 sourceRef:
 kind: GitRepository
 name: k8s-manifests
 git:
 checkout:
 ref:
 branch: main
 commit:
 author:
 email: fluxbot@myorg.com
 name: Flux Image Updater
 messageTemplate: "chore: update "
 push:
 branch: main
CI pushes a new image tag → Flux detects it → commits the updated tag to Git → reconciles the cluster. Full GitOps loop without manual YAML edits.
Crossplane: GitOps for Infrastructure
Crossplane has matured significantly and represents a compelling extension of GitOps principles beyond Kubernetes workloads to cloud infrastructure:
# Provision an RDS instance via GitOps
apiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance
metadata:
 name: payments-db-prod
spec:
 forProvider:
 region: ap-northeast-2
 dbInstanceClass: db.r6g.xlarge
 engine: postgres
 engineVersion: "15"
 multiAZ: true
 storageEncrypted: true
 allocatedStorage: 100
 backupRetentionPeriod: 7
 providerConfigRef:
 name: aws-production
 writeConnectionSecretToRef:
 namespace: payments-prod
 name: payments-db-credentials
The mental model: your Git repository contains not just Kubernetes manifests but your entire infrastructure definition. Crossplane reconciles AWS/GCP/Azure resources the same way Kubernetes reconciles pods. Combined with ArgoCD or Flux, you get full GitOps from “create an RDS instance” to “deploy the app that uses it.”
Choosing in 2026
Choose ArgoCD if:
Your team needs a UI to operate effectively
You have non-Kubernetes-experts managing deployments
You want application-centric views across multiple clusters
You need Progressive Delivery (Argo Rollouts integrates tightly)
Choose Flux if:
You want GitOps-as-a-library: composable, no opinions
You need image automation (Flux’s is more mature)
You’re building a platform where multiple teams manage their own GitOps configs
You prefer CLI-first + your own Grafana dashboards over a built-in UI
Use both: Many large organizations use Flux for cluster configuration and ArgoCD for application deployment. They coexist fine.
Add Crossplane if:
You want to GitOps your cloud infrastructure alongside your Kubernetes workloads
You’re building an Internal Developer Platform where devs can self-serve databases, queues, and buckets
The Platform Engineering Angle
In 2026, GitOps is increasingly just a layer in a larger Platform Engineering stack. Tools like Backstage, Port, and Cortex sit above ArgoCD/Flux and provide the developer-facing abstraction:
Developer submits a service request via the portal
Platform generates the GitOps manifests
ArgoCD/Flux reconciles the cluster
Developer never touches a YAML file
The GitOps tool becomes an implementation detail. The platform team owns it; application developers interact with it indirectly. This is the trajectory for mature platform engineering organizations.
GitOps is table stakes for production Kubernetes. The interesting design decisions are now about how you structure your GitOps repositories, who gets to commit to them, and what layer of abstraction sits above them for your developers.
References: ArgoCD Documentation, Flux Documentation, Crossplane Documentation, CNCF GitOps Working Group

GitOps in 2026: Flux vs ArgoCD vs the New Challengers

댓글