Migrate to a GitOps Architecture for Kubernetes

GitOps is an operational approach where the desired state of infrastructure is described in Git, and an operator automates reconciliation with the cluster's actual state. For any Kubernetes system administrator with CKA certification, this GitOps migration represents a fundamental change in deployment management.

TL;DR

GitOps migration occurs in four phases: repository structuring, operator deployment (ArgoCD or Flux), progressive application migration, and legacy pipeline retirement. Plan for 2 to 4 months for a complete migration.

Professionals who want to go further follow the LFS458 Kubernetes Administration training.

According to the CNCF GitOps Survey 2025, 91% of cloud-native organizations have adopted GitOps. This CI/CD to GitOps transition has become an industry standard.

What is GitOps and why migrate? CKA-certified Kubernetes system administrator perspective

GitOps is an operational paradigm where Git becomes the single source of truth for the declarative state of infrastructure. An agent in the cluster continuously compares the desired state (Git) with the current state and applies necessary corrections.

Key differences from traditional CI/CD:

As Chris Aniszczyk, CNCF CTO emphasizes: "Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well." GitOps reinforces this foundation.

Key takeaway: GitOps inverts the control flow. The cluster becomes active (pull) instead of passive (push).

The Kubernetes deployment and production guide presents the fundamentals of this approach.

How to structure your Git repositories for GitOps?

Before migrating, define your repository structure. Two approaches dominate:

Monorepo (single repository):

├── apps/
│   ├── frontend/
│   │   ├── base/
│   │   └── overlays/
│   │       ├── dev/
│   │       ├── staging/
│   │       └── prod/
│   └── backend/
├── infrastructure/
│   ├── namespaces/
│   ├── rbac/
│   └── monitoring/
└── clusters/
├── dev-cluster/
└── prod-cluster/

Multi-repo (application/config separation):

# Repo 1: application-code
# Repo 2: application-config (Kubernetes manifests)
# Repo 3: cluster-config (shared infrastructure)

Key takeaway: Start with a monorepo if your team is small (<10 people). Switch to multi-repo when isolation needs increase.

The Kubernetes multi-environment management details these patterns.

Which GitOps platform to choose: ArgoCD or Flux?

According to the CNCF End User Survey 2025, ArgoCD holds 60% of the GitOps market versus 11% for Flux.

Compare both solutions:

Install ArgoCD:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Retrieve the initial password
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Or install Flux:

flux bootstrap github \
--owner=my-org \
--repository=fleet-infra \
--branch=main \
--path=clusters/prod-cluster \
--personal

The Kubernetes monitoring and troubleshooting covers observability for these tools.

How to progressively migrate your applications to GitOps?

Phase 1: Prepare infrastructure (weeks 1-2)

1. Deploy the chosen GitOps operator
2. Configure access to Git repositories
3. Define namespaces and RBAC

# argocd-project.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: production
namespace: argocd
spec:
description: Production applications
sourceRepos:
- 'https://github.com/my-org/*'
destinations:
- namespace: '*'
server: https://kubernetes.default.svc
clusterResourceWhitelist:
- group: '*'
kind: '*'

Phase 2: Migrate a pilot application (weeks 3-4)

Choose a non-critical application to validate the workflow.

# ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: pilot-app
namespace: argocd
spec:
project: production
source:
repoURL: https://github.com/my-org/k8s-config
targetRevision: main
path: apps/pilot-app/overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: pilot-app
syncPolicy:
automated:
prune: true
selfHeal: true

Key takeaway: Enable selfHeal: true so the operator automatically corrects manual drifts.

The Kubernetes system administrator fundamentals training covers these concepts.

How to manage the CI/CD to GitOps transition for CKA-certified Kubernetes system administrators?

Phase 3: Modify your CI pipelines (weeks 5-8)

Transform your push pipelines into image-tag pipelines:

Old pipeline (push):

# ❌ CI pushes directly to the cluster
deploy:
script:
- kubectl apply -f manifests/
- kubectl set image deployment/app app=my-registry/app:$CI_COMMIT_SHA

New pipeline (GitOps):

# ✅ CI updates the config repo
update-manifests:
script:
- git clone https://github.com/my-org/k8s-config
- cd k8s-config
- kustomize edit set image my-registry/app:$CI_COMMIT_SHA
- git commit -am "Update app to $CI_COMMIT_SHA"
- git push

The Kubernetes CI/CD pipeline details this transformation.

Phase 4: Migrate remaining applications (weeks 9-12)

Proceed by decreasing criticality waves:

1. Non-critical internal applications
2. Backend services
3. External APIs
4. Critical applications (with rollback plan)

For each application:

# 1. Create the ArgoCD Application
kubectl apply -f apps/my-app/argocd-application.yaml

# 2. Verify synchronization
argocd app sync my-app
argocd app wait my-app --health

# 3. Disable old CI deployment
# Remove kubectl steps from the pipeline

How to manage secrets in a GitOps architecture?

Secrets should never be committed in clear text in Git. Several solutions exist:

Example with Sealed Secrets:

# Install the controller
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets -n kube-system

# Encrypt a secret
kubectl create secret generic my-secret --dry-run=client --from-literal=password=s3cr3t -o yaml | \
kubeseal --format=yaml > sealed-secret.yaml

The sealed-secret can be safely committed:

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: my-secret
spec:
encryptedData:
password: AgBy3i4OJSWK+PiTySYZZA...

Key takeaway: Sealed Secrets' asymmetric encryption ensures only the cluster can decrypt secrets.

The Kubernetes production checklist includes secrets security.

How to validate and monitor your GitOps migration?

Success metrics:

# Prometheus query for drift
sum(argocd_app_info{sync_status="OutOfSync"})

# Synchronization time
histogram_quantile(0.95, sum(rate(argocd_app_sync_total[5m])) by (le))

Recommended dashboards:

1. Synchronization status by application
2. Deployment frequency
3. Average reconciliation time
4. Alerts on prolonged OutOfSync

# Prometheus alert
groups:
- name: gitops
rules:
- alert: ApplicationOutOfSync
expr: argocd_app_info{sync_status="OutOfSync"} == 1
for: 15m
labels:
severity: warning
annotations:
summary: "Application {{ $labels.name }} out of sync for 15min"

The guide Resolve Kubernetes deployment errors covers post-migration troubleshooting.

GitOps migration checklist

Before starting:

• [ ] Inventory of current applications
• [ ] ArgoCD vs Flux choice
• [ ] Repository structure defined
• [ ] Secrets management strategy

During migration:

• [ ] GitOps operator deployed and configured
• [ ] Pilot application migrated and validated
• [ ] CI pipelines modified (image-tag only)
• [ ] Teams trained on new workflow

After migration:

• [ ] GitOps monitoring in place
• [ ] Alerts configured
• [ ] Documentation updated
• [ ] Old pipelines disabled

See the Kubernetes deployment FAQ for common questions.

Take action: adopt GitOps for your enterprise Kubernetes

Migrating to GitOps transforms deployment management into an auditable, reproducible, and automated process. With 91% of cloud-native organizations having adopted this approach, it has become an industry standard.

To succeed in this transition:

• The LFS458 Kubernetes Administration training covers GitOps and deployment strategies over 4 days
• The LFD459 training for developers addresses CI/CD integration
• For an introduction, discover Kubernetes Fundamentals

Contact our advisors to plan your training path.